Change:
3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur in the player (such as available memory, CPU, display size, etc.). </del> <ins> strategy in which the streaming client attempts to detect the available bandwidth of the network path by observing the successful application-layer download speed, then chooses a bitrate for each of the video, audio, subtitles and metadata (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur during the playback (such as available memory, CPU, display size, etc.). </ins> The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del> <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2. <del> ABR playback is commonly implemented by video players using HLS </del> <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del> <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.

Discussion:
NAME - is this roughly what you were expecting to see, on Issue 22? Please advise :-)
I'm having a conversation with NAME about URL, but the short summary here is that I need to tighten up some of the language about what we are saying about strangely HTTPish UDP traffic, from an observer's perspective, and to do so without starting to say things that either duplicate (bad) or contradict (worse) the QUIC manageability draft on this point. You'll note that the QUIC issue is still under discussion, so probably need to revisit this after they close their Issue. Fortunately, I bet NAME will make sure I behave ... and I appreciate that.
Is it worth also saying about the expectations networks allows streaming traffic over TCP and QUIC to flow freely? I think this could just be a short paragraph that highlights that when other variables are isolated, fairness/contention between TCP and QUIC is most likely a function of the congestion controllers at play.
I THINK the current text in this draft (as of 10 May) is consistent with the QUIC manageability draft, but it will be GREAT for us to do a final check after QUIC finishes working on their draft.
NAME - thank you for this suggestion. See what you think of the current text.
And, like magic, this just popped up on the QUIC mailing list 15 minutes ago. I swear, I could write this script! "The SNI extraction and Appendix A sections of manageability provide guidance that won't work with Chrome. I opened issues 357 and 358 about this. They should be easy to resolve. I apologize for the late notice (I haven't been keeping track of these documents closely) but I do think these do need to be addressed before publication."
The text LGTM. I'll leave it to you editors to decide and battle out where/if to land it.
NAME I'm going to do a commit that moves this text to an actual reasonable place in the draft (I'll be looking at your suggestion to put it near ABR, and I'll try to Do The Right Thing). Probably best not to merge this PR until I commit that, OK?
NAME and NAME I think this PR is ready to merge. Do either of you agree?
Since the intro says relate to quality of experience in internet video delivery.

I'm a little surprised to not see anything about the effects on video QoE caused by contention in the network, or the role that fairness between other flows and/or protocols plays on video and other applications. Finally, its been interesting to see how large content providers have reduced streaming bitrates in response to large-scale contention during the COVID pandemic, whether voluntarily or via external pressures. This is especially curious when content is distributed via ABR technologies which should accommodate switching to lower bitrates. (I've heard anecdotal reasoning that the detection of contention is too slow, but unsure if that is really true).
One of the more logical explanations of the situation I have I read: URL EU asking Netflix to drop the bitrates was a total BS IMO.
It is worth noting that some protocols rely on the transport layer bwe/cc (the ones that are TCP based) while others have to implement their own mechanisms (udp based like QUIC or RTP). In that regard, I would differentiate the loss based bwe/cc algorithms (TCP, new Reno, bbr) vs the delay based ones (copa).
I'm planning to focus a PR for this issue on fairness and contention, but defer to the "Extremely Unpredictable Usage Profiles" section, which we've recently merged into Master, for anything about CoViD-19-related impacts on network performance for streaming media. Please let me know if that's not a good plan.
OK, I'm about 10 commits (it seemed like more) into the PR for this issue, and am now thinking that I should divide what is now the "Evolution of Transport Protocols and Transport Protocol Behaviors" section into a UDP/TCP section that comes before the ABR section, because those are the protocols that people use with ABR today, and a QUIC section (that is actually "evolution") that remains after the ABR section. NAME and NAME do you have any thoughts about that? I'm pretty sure it would allow us to tighten up the discussion of interaction between ABR and transport protocol behavior in the ABR section.
Sounds reasonable to me, I think.
I'll make that split (and see if I can do that without conflicts - I think I'm only moving text in , so should be easy.
The content here is pretty good, but I think maybe goes a little out of scope for what I thought this doc should do.

I'd be in favor of more depth on the effects of congestion on video QoE. I'm agnostic on whether to drop some of the depth here on congestion control in general (it's good stuff, but reading it I feel like this is for an iccrg informational topic instead of a mops one.) Also the section location seems to be the first one after the intro. Should this move into the ABR section, maybe with a note about congestion response being the primary driver for ABR bitrate selection?