Draft: draft-ietf-mops-streaming-opcons

Commentary: This is in existing text , but I 'd put a paragraph break after " Some receive - side ABR algorithms such as { { ELASTIC } } are designed to try to avoid this effect . " and before " Another way to mitigate this effect is by the help of two simultaneous TCP connections , as explained in { { MMSys11 } } for Microsoft Smooth Streaming . In some cases , the system - level TCP slow - start restart can also be disabled , for example as described in { { OReilly - HPBN } } . " 
 Works for me . Updated ... 
 The editors are 2:1 in favor of dropping ECN .  is graciously in the rough . We should be talking more broadly about what happens when you lose any packets , If ECN belongs in the draft , it belongs somewhere else . " Coming improvements in transport behaviors " more broadly - we 're talking about BBR and about end - to - end transport encryption now . Maybe we should talk about things like edge computing , etc ... but will talk to the working group about this before we start a major refactor . 
 The point of these sections ( 4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking ) was to explain how and why your bandwidth measurements can go wrong when you 're trying to do ABR things with your bandwidth measurements . By name this seems like perhaps a better fit in the 4.4 Measurement Collection section , there might be a reason to merge some of the discussion there or reorganize the 2 sections together . 
 We maybe should also add a section along these lines on the wide variability in bitrates as things move , both for wi - fi and LTE and 5 g. ( or paths in general , with those as examples ? ) 
 Note also : " Refactor " here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it .
Paragraph (version A):
This kind of bandwidth-measurement system can experience trouble in
several ways that can be affected by networking design choices.
Because adaptive application-level response strategies are typically
using application-level protocols, these mechanisms are affected by
transport-level protocol behaviors, and the application-level
feedback loop is interacting with a transport-level feedback loop, as
described in idle-time and hol-blocking.
Paragraph (version B):
This kind of bandwidth-measurement system can experience trouble in
several ways that are affected by networking issues.  Because
adaptive application-level response strategies are often using rates
as observed by the application layer, there are sometimes inscrutable
transport-level protocol behaviors that can produce surprising
measurement values when the application-level feedback loop is
interacting with a transport-level feedback loop.
Paragraph (version B):
A few specific examples of surprising phenomena that affect bitrate
detection measurements are described in the following subsections.
As these examples will demonstrate, it's common to encounter cases
that can deliver application level measurements that are too low, too
high, and (possibly) correct but varying more quickly than a lab-
tested selection algorithm might expect.
Paragraph (version B):
These effects and others that cause transport behavior to diverge
from lab modeling can sometimes have a significant impact on ABR
bitrate selection and on user quality of experience, especially where
players use naive measurement strategies and selection algorithms
that don't account for the likelihood of bandwidth measurements that
diverge from the true path capacity.
Paragraph (version A):
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):
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.  This in
turn can prevent 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 A):
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-HPBN.
Paragraph (version B):
Some receiver-side ABR algorithms such as ELASTIC are designed to try
to avoid this effect.
Paragraph (version B):
Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in MMSys11 for Microsoft
Smooth Streaming.  In some cases, the system-level TCP slow-start
restart can also be disabled, for example as described in OReilly-
HPBN.
Paragraph (version A):
To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the
goodput measurement.
Paragraph (version B):
To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the
goodput measurement.  This can appear as a stall of some time,
followed by a sudden leap that can far exceed the actual capacity of
the transport path from the server when the hole in the received data
is filled by a later retransmission.
Paragraph (version B):
As many end devices have moved to wireless connectivity for the final
hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
emerged from radio interference and signal strength effects.
Paragraph (version B):
Each of these technologies can experience sudden changes in capacity
as the end user device moves from place to place and encounters new
sources of interference.  Microwave ovens, for example, can cause a
throughput degradation of more than a factor of 2 while active Micro.
5G and LTE likewise can easily see rate variation by a factor of 2 or
more over a span of seconds as users move around.
Paragraph (version B):
These swings in actual transport capacity can result in user
experience issues that can be exacerbated by insufficiently
responsive ABR algorithms.