Draft: draft-ietf-mops-streaming-opcons

Commentary: 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 are n'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 : 
 It says :   - 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 do n'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  '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 . 
  to ( which is already addressed adequately IMO , so we can close this issue ) . 
 Fixed in . 
 Fixed the reference .
Paragraph (version A):
Mobile flow-bandwidth spectrum and timing mapping.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.