Change:
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

Discussion:
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.