Change:
4.3.1. <del> When the bitrate selection is successfully chosen below the available capacity of the network path, the response to a segment request will typically complete in less absolute time than the duration of the requested segment.  The resulting idle time within the connection carrying the segments has a few surprising consequences: Mobile flow-bandwidth spectrum and timing mapping. TCP slow-start when restarting after some idle time requires multiple RTTs to re-establish a throughput at the network's available capacity.  On high-RTT paths or with small enough segments, this can produce a falsely low application-visible measurement of the available network capacity. How TCP slow-start restart can be avoided by the help of two simultaneous TCP connections is exemplified for Microsoft Smooth Streaming in MMSys11.  For some use cases, the system-level TCP slow- start restart flag can be disabled oreilly-tcpblocks. </del> <ins> When the bitrate selection is chosen substantially below the available capacity of the network path, the response to a segment request will typically complete in much less absolute time than the duration of the requested segment, leaving significant idle time between segment downloads.  This can have a few surprising consequences: TCP slow-start when restarting after idle requires multiple RTTs to re-establish a throughput at the network's available capacity. When the active transmission time for segments is substantially shorter than the time between segments leaving an idle gap between segments that triggers a restart of TCP slow-start, the estimate of the successful download speed coming from the application- visible receive rate on the socket can thus end up much lower than the actual available network capacity, preventing a shift to the most appropriate bitrate.  RFC7661 provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. Some receive-side ABR algorithms such as ELASTIC are designed to try to avoid this effect.  Another way to mitigate this effect is by the help of two simultaneous TCP connections is explained in MMSys11 for Microsoft Smooth Streaming.  In some cases, the system-level TCP slow-start restart can be disabled oreilly-tcpblocks. </ins> 4.3.2.

Discussion:
I'm looking at "{{RFC7661}} provides some mitigations for this effect at the TCP transport layer, for senders who anticipate a high incidence of this problem", and noticing that RFC 7661 is Experimental. Our draft is targeting Informational, so downrefs aren't a problem, but do we have fair confidence that people have implemented this? Maybe the right thing to do in an OPS draft is to say that understanding what the TCP implementations you're using support, in mitigating this effect, and realizing that the answers might be "RFC 7661", "something else", "both", or "nothing".
I have seen servers deliberately disabling SSR flag so TCP does not restart after an idle period.
We could add these examples: $> sysctl net.ipv4.tcpslowstartafteridle $> sysctl -w net.ipv4.tcpslowstartafteridle=0 And we'll split out the mitigations ...
This is a more formal reference: URL
It says: TCP Slow-start when restarting after idle requires multiple RTTs to re-establish a throughput at the network's available capacity. On high-RTT paths or with small enough segments, this can produce a falsely low application-visible measurement of the available network capacity. Well, TCP slow-start restart happens when TCP stays idle long enough. "Long enough" is a factor for RTT, so I don't think slow-start restart is more likely when RTT is higher. When the segments are small, it is not more likely, either. I think what we are looking for is when the "on" duration is substantially longer than the "off" duration in the HTTP transaction. And that means, when the segment download time is substantially shorter than the inter-request time (typically the segment duration), which implies download speed is far greater than the segment's encoding bitrate. In that case, SSR will likely happen.
Yes, good point, thanks, the main thing is the amount of idle time. Maybe a reference to RFC 7661 is also in order, as a mitigation for senders who expect this. Not sure if the default behavior for common server systems should get a mention here as well (and also maybe stuff like linux's net.ipv4.tcpslowstartafteridle).
7661 could be mentioned as a note. I have seen some servers disabling SSR while others leaving it on by default.

Linked to (which is already addressed adequately IMO, so we can close this issue).
Fixed in .
Fixed the reference.