Original text:
networking practices and observations of media delivery issues encountered when streaming media over those existing networks. <del> This document defines "high-bitrate streaming media" as follows: </del>  "High-bitrate" is a context-sensitive term broadly intended to capture rates that can be sustained over some but not all of the "Media" refers to any type of media and associated streams such as video, audio, metadata, etc. <del> 1.1. </del>  A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover of reference for future solution proposals to describe how new technologies address or avoid existing problems. <del> generalized network performance techniques; while things like datacenter design and transit network design can be crucial dependencies for a performant streaming media service, these are considered independent topics better addressed by other documents. </del>  transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media. <del> 1.2. </del>  Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far. <del> 1.2.1. </del>  This document is in the GitHub repository at: services. Implementation of a low-latency live video service can be achieved <del> with the use of low-latency extensions of HLS (called LL-HLS) I- D.draft-pantos-hls-rfc8216bis and DASH (called LL-DASH) LL-DASH. These extensions use the Common Media Application Format (CMAF) standard MPEG-CMAF that allows the media to be packaged into and transmitted in units smaller than segments, which are called chunks in CMAF language.  This way, the latency can be decoupled from the duration of the media segments.  Without a CMAF-like packaging, lower latencies can only be achieved by using very short segment durations. However, using shorter segments means using more frequent intra-coded frames and that is detrimental to video encoding quality.  CMAF allows us to still use longer segments (improving encoding quality) without penalizing latency. </del>  While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature seconds. This level of latency is the historically common case for segmented <del> video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of latency is often considered adequate for content like news or pre- recorded content.  This level of latency is also sometimes achieved as a fallback state when some part of the delivery system or the client-side players do not have the necessary support for the features necessary to support low-latency live streaming. </del>  This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery, and in some cases, the consumer, a buffer, and a transport mechanism that fills the buffer. The consumption rate is fairly static and is represented by the content bitrate.  The size of the buffer is also commonly a fixed <del> size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </del>  The challenges in filling the buffer in a timely way fall into two broad categories: 5.3. <del> ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. </del>  Many systems will do an initial probe or a very simple throughput speed test at the start of video playback.  This is done to get a

Reviewer comments:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.

Revised text:
networking practices and observations of media delivery issues encountered when streaming media over those existing networks.  <ins> 1.1. This document defines "high-bitrate streaming media over the Internet" as follows: </ins> "High-bitrate" is a context-sensitive term broadly intended to capture rates that can be sustained over some but not all of the "Media" refers to any type of media and associated streams such as video, audio, metadata, etc.  <ins> "Over the Internet" means that a single operator does not have control of the entire path between media servers and media clients, so not a "walled garden". 1.2. </ins> A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover of reference for future solution proposals to describe how new technologies address or avoid existing problems.  <ins> generalized network performance techniques; while considerations such as datacenter design, transit network design, and "walled garden" optimizations can be crucial components of a performant streaming media service, these are considered independent topics better addressed by other documents. </ins> transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media.  <ins> 1.3. </ins> Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far.  <ins> 1.3.1. </ins> This document is in the GitHub repository at: services. Implementation of a low-latency live video service can be achieved  <ins> with the use of "HTTP Live Streaming (HLS)" RFC8216 by using its low- latency extension (called LL-HLS) I-D.draft-pantos-hls-rfc8216bis or with "Dynamic Adaptive Streaming over HTTP (DASH)" MPEG-DASH by using its low-latency extension (called LL-DASH) LL-DASH.  These extensions use the Common Media Application Format (CMAF) standard MPEG-CMAF that allows the media to be packaged into and transmitted in units smaller than segments, which are called chunks in CMAF language. This way, the latency can be decoupled from the duration of the media segments.  Without a CMAF-like packaging, lower latencies can only be achieved by using very short segment durations.  However, using shorter segments means using more frequent intra-coded frames and that is detrimental to video encoding quality.  CMAF allows us to still use longer segments (improving encoding quality) without penalizing latency. </ins> While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature seconds. This level of latency is the historically common case for segmented  <ins> video delivery using HLS and DASH.  This level of latency is often considered adequate for content like news or pre-recorded content. This level of latency is also sometimes achieved as a fallback state when some part of the delivery system or the client-side players do not have the necessary support for the features necessary to support low-latency live streaming. </ins> This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery, and in some cases, the consumer, a buffer, and a transport mechanism that fills the buffer. The consumption rate is fairly static and is represented by the content bitrate.  The size of the buffer is also commonly a fixed  <ins> size.  The buffer fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </ins> The challenges in filling the buffer in a timely way fall into two broad categories: 5.3.  <ins> Adaptive Segmented Delivery attempts to optimize its own use of the path between a media server and a media client.  ABR playback is commonly implemented by streaming clients using HLS RFC8216 or DASH MPEG-DASH to perform a reliable segmented delivery of media over HTTP.  Different implementations use different strategies ABRSurvey, often relying on proprietary algorithms (called rate 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 video playback.  This is done to get a