Change:
5. <ins> This section describes one of the best known ways to provide a good user experience over a given network path, but one thing to keep in mind is that application-level mechanisms cannot provide a better experience than the underlying network path can support. </ins> 5.1. A simple model of video playback can be described as a video stream

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