Code change:
5.5.3. <del> As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have emerged from radio interference and signal strength effects. </del> <ins> As many end devices have moved to wireless connections for the final hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth detection have emerged. </ins> <del> 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. </del> <ins> In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference. Microwave ovens, for example, can cause a throughput degradation in Wi-Fi 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. </ins> These swings in actual transport capacity can result in user <del> experience issues that can be exacerbated by insufficiently responsive ABR algorithms. </del> <ins> experience issues when interacting with ABR algorithms that aren't tuned to handle the capacity variation gracefully. </ins> 5.6.

Related discussion:
text: This tries to address both of:
Discussion from editor's conference call: Can we provide a reference for useful properties? Network analytics, application analytics, or both? Currently application analytics, which is OK. Is that clear enough? Who is supposed to notice changes from an expected baseline? Is mentioning QLOG helpful? Have we said clearly enough that baselines themselves can fluctuate, before the kinds of path characteristic changes we're talking about kick in?
I think just "baseline" is clear enough to me, in context with this section listing some relevant stats. I guess "baseline pattern of some relevant statistics" is maybe more precise, but I'm not sure "baseline pattern" really gets there.
from NAME 's review (URL) Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "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." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder.
This comment helpfully points out the changing network architecture (a LOT of wireless), and we should be clearer about what we're talking about in Section 3.2 (our mental was mostly wired) and in 5.5.3 (where we focused on wireless). This material should go in Section 3.2, and should be referenced in 5.5.3..
Related to
From NAME (URL) Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful.
Related to
This works for me. I'll merge it.