Original text:
1. <del> This document examines networking issues as they relate to quality of experience in Internet media delivery, especially focusing on capturing characteristics of streaming video delivery that have surprised network designers or transport experts who lack specific video expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of video delivery issues encountered when streaming media over those existing networks. </del>  This document specifically focuses on streaming applications and defines streaming as follows: communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary <del> from one application to another.  For example, videoconferencing demands an end-to-end (one-way) latency of a few hundreds of milliseconds whereas live streaming can tolerate latencies of several seconds. </del>  In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video loaded, offer lower total bandwidth, or simply cover more distance. <del> Recognizing that a path carrying streaming media is "not behaving the way it normally does" is fundamental.  Analytics that aid in that recognition can be more or less sophisticated, and can be as simple as noticing that the apparent round trip times for media traffic carried over TCP transport on some paths are suddenly and </del>  significantly longer than usual.  Passive monitors can detect changes in the elapsed time between the acknowledgements for specific TCP segments from a TCP receiver, since TCP octet sequence numbers and adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. <del> Many server-player systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </del>  <del> The choice of bitrate occurs within the context of optimizing for some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </del>  5.4. 5.5. This kind of bandwidth-measurement system can experience trouble in <del> several ways that are affected by networking issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </del>  A few specific examples of surprising phenomena that affect bitrate detection measurements are described in the following subsections.

Reviewer comments:
From NAME Same comment as for section 1, "networking issues" actually means something broader than the plain layer-3. Suggest introducing the shortcut in the terminology part of section 1, e.g., "this document uses the wording networking issues to represent the conjunction of IP and transport layers" ?
Hi, NAME I thought this might be a quick addition of an umbrella definition of "networking" to include transport protocols, but a significant chunk of the text was distinguishing between network and transport protocols, so I added "and transport protocols" to the few occurrences of "networking" that were intended to include both.
Thank you, NAME , this is more work for the authors but less ambiguous for the readers.
From NAME Unsure whether "server-player systems" is well understood by the readers. Nit: "some metric monitored by the client" should the plural form be used ?
I dont think we made the exercise of going thru all the mixed-up terms like clients vs. players in the text. One simple solution is to do the following: (streaming) client: the part of the (media) player that deals with the transmission/reception and buffer related matters. (media) player: on top of the streaming client, this includes the media decoders, UI, user controls, DRM, authentication modules, etc.
"many systems" -
From NAME " Know Your Network Traffic" what is "your" in this section ? My network used by other parties (server and consumer) to transfer streaming video ? My network as the servers, layer-3, and consumers are all in my administrative domain? Suggest removing the 'your'
Knowing expected traffic and traffic growth baselines before something goes wrong.
From NAME While I am not an expert, I am surprised by the acceptable latency numbers, I would have written 100 msec for videoconference and "couple of seconds" for streaming live events. Video streaming (netflix like) is indeed several seconds. But, I am trusting the authors on their statement. Section 4.2 explains a little more those numbers so a forward reference to section 4 would be beneficial.
On-list discussion so far concluded that we are best off leaving it alone, with no dissent yet: URL
I've raised this issue a few times, but suspect that the right answer is to Don't change any of the numbers in this document, Recognize that latency goals are falling year by year, and Wait until we better understand the thinking in MOQ discussions about the latency requirements for live media streaming and other forms of media handling to revisit this The likely improvements from continued discussions about latency categories aren't worth holding up this document.
Up to the authors, really, but suggest to add some text about those numbers are in flux ?
Yeah, that sounds like a good idea. Some clarifying context in the section 4 header where these numbers appear might help avoid some confusion.
NAME - that sounds like a win to me. My goal was to NOT say something like "these numbers are old and inaccurate, so good luck!"
We agree with the suggestion for forward reference to Section 4.
LGTM Hi, Jake, Holland, Jake wrote: specifically about the 1 second for videoconferencing, which is clearly wrong, because we've known that people accidentally talk over other people when latencies are more than 200 ms for decades, but it's probably not wrong enough to be worth talking about changing it. Honestly, if this document is about Operational Considerations for Streaming Media, anyone reading it for guidance about videoconferencing probably has bigger problems than the latency categories. I think we're through discussing that part, at least for now. Best, Spencer

Revised text:
1.  <ins> This document examines networking and transport protocol issues as they relate to quality of experience in Internet media delivery, especially focusing on capturing characteristics of streaming video delivery that have surprised network designers or transport experts who lack specific video expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of video delivery issues encountered when streaming media over those existing networks. </ins> This document specifically focuses on streaming applications and defines streaming as follows: communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary  <ins> from one application to another.  For additional discussion of latency requirements, see latency-cons. </ins> In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video loaded, offer lower total bandwidth, or simply cover more distance.  <ins> In order to recognize that a path carrying streaming media is "not behaving the way it normally does", having an expected baseline that describes "the way it normally does" is fundamental.  Analytics that aid in that recognition can be more or less sophisticated, and can be as simple as noticing that the apparent round trip times for media traffic carried over TCP transport on some paths are suddenly and </ins> significantly longer than usual.  Passive monitors can detect changes in the elapsed time between the acknowledgements for specific TCP segments from a TCP receiver, since TCP octet sequence numbers and adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  <ins> Many systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </ins>  <ins> The choice of bitrate occurs within the context of optimizing for one or more metrics monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </ins> 5.4. 5.5. This kind of bandwidth-measurement system can experience trouble in  <ins> several ways that are affected by networking and transport protocol issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </ins> A few specific examples of surprising phenomena that affect bitrate detection measurements are described in the following subsections.