Change:
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. Spencer 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 NAME 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 5g. (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.

Discussion:
some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). <ins> 4.4. </ins> This kind of bandwidth-measurement system can experience trouble in <del> 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. </del> <ins> 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. 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. 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. </ins> <del> 4.3.1. </del> <ins> 4.4.1. </ins> When the bitrate selection is chosen substantially below the available capacity of the network path, the response to a segment

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 <del> 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. </del> <ins> 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. </ins> Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a

would be achievable with a steadier transmission in the same network. <del> 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. </del> <ins> Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. </ins> <del> 4.3.2. </del> <ins> 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. 4.4.2. </ins> In the event of a lost packet on a TCP connection with SACK support (a common case for segmented delivery in practice), loss of a packet

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 <del> goodput measurement. </del> <ins> 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. </ins> It's worth noting that more modern transport protocols such as QUIC have mitigation of head-of-line blocking as a protocol design goal. See quic-behavior for more details. <del> 4.4. </del> <ins> 4.4.3. 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. 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. These swings in actual transport capacity can result in user experience issues that can be exacerbated by insufficiently responsive ABR algorithms. 4.5. </ins> In addition to measurements media players use to guide their segment- by-segment adaptive streaming requests, streaming media providers may

Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. <del> 4.4.1. </del> <ins> 4.5.1. </ins> CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for

defining a common terminology as well as how each metric should be computed for consistent reporting. <del> 4.4.2. </del> <ins> 4.5.2. </ins> Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.

standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. <del> 4.5. </del> <ins> 4.6. </ins> In contrast to segmented delivery, several applications use unreliable UDP or SCTP with its "partial reliability" extension