Change:
workflows are introduced. The challenges in filling the buffer in a timely way fall into two <del> broad categories: 1. content selection and 2. content variation. Content selection comprises all of the steps needed to determine which content variation to offer the client.  Content variation is the number of content options that exist at any given selection point.  A common example, easily visualized, is Adaptive BitRate (ABR), described in more detail below.  The mechanism used to select the bitrate is part of the content selection, and the content variation are all of the different bitrate renditions. ABR is a sort of application-level response strategy in which the </del> <ins> broad categories: Content selection comprises all of the steps needed to determine which content variation to offer the client. Content variation is the number of content options that exist at any given selection point. The mechanism used to select the bitrate is part of the content selection, and the content variation are all of the different bitrate renditions. Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a commonly used technique for dynamically adjusting the compression level and video quality of a stream to match bandwidth availability. When this goal is achieved, the media server will tend to send enough media that the media player does not "stall", without sending so much media that the media player cannot accept it without exhausting all available receive buffers. ABR uses an application-level response strategy in which the </ins> streaming client attempts to detect the available bandwidth of the <del> 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.). </del> <ins> network path by first observing the successful application-layer download speed, and then, given the available bandwidth, the client chooses a bitrate for each of the video, audio, subtitles and metadata (among a limited number of available options for each type of media) 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> 5.2.

Discussion:
and provide context.
This seems out of place here to me, but I can see why it's hard to find a spot for the AQM reference since we don't have anything else that talks about network latency. Hmm, how badly do we think we need this?
We like part of one sentence in this PR, that we think does belong in the document, but we aren't sure it belongs where it is in the document.
NAME and NAME - I note that in , NAME asked about mentioning active testing in Section 5. Although the lightning talk NAME gave was describing an active testing system Comcast had deployed to monitor their access networks, and we've agreed that the underlying network was a "black box" from the perspective of media providers, ISTM that over-the-top media providers could perform active testing as well, between their origin servers and the first downstream media receivers (whether that is a CDN or endpoint media players), in order to detect significant changes in performance for a known workflow. I plan to add a mention of active testing in Section 5 as part of this PR, referencing Jason's lightning talk, rather than trying to use the lightning talk in two parallel PRs.
I agree this is possible in theory, but I'm not aware of any operational experience that's been collected on these techniques. NAME I don't suppose you have a reference to work that describes using active measurements to improve media streaming delivery?
was this added?.. NAME what you wrote here is inline with my thinking. However, this document is also supposed to provide information for network administrators. Hence, I believe it would be good to cover the active testing , i.e. a summery of what you wrote would be necessary. I will also note that, there are system designed to provide QoE/QoS information to a network node from the application (URL). This is to help the network operators to fine tune their part of delivery of the e2e chain. This is not active testing, however, this puts network operators on the perspective of media quality. what is the view regarding this?
Jason Livingood's presentation is at URL - mention experience with DOCSIS 3.1 AQM?
Not sure this fits in the document, but someone should be looking at this who is awake (and we were not awake by TSVAREA at the last IETF 111 meeting slot).

Jake anecdote about WebEx conversation where speech was noticeably buffered and then suddenly released in a burst. Might be worth adding a comment in passing that there are many sources of jitter and buffering - can't get lower latency than the network can give you.
This is on my list ...
NAME I couldn't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators. Sure, active measurements can be the right thing to do, for operators providing access networks, etc. - that's what NAME was talking about in his lightning talk. But I did take an opportunity to clean up the abr introduction, so there's that ...
lgtm