Code change:
6. <del> Because networking resources are shared between users, a good place to start our discussion is how contention between users, and mechanisms to resolve that contention in ways that are "fair" between users, impact streaming media users.  These topics are closely tied to transport protocol behaviors. As noted in sec-abr, ABR response strategies such as HLS RFC8216 or DASH MPEG-DASH are attempting to respond to changing path characteristics, and underlying transport protocols are also attempting to respond to changing path characteristics. For most of the history of the Internet, these transport protocols, described in udp-behavior and tcp-behavior, have had relatively consistent behaviors that have changed slowly, if at all, over time. Newly standardized transport protocols like QUIC RFC9000 can behave differently from existing transport protocols, and these behaviors may evolve over time more rapidly than currently-used transport protocols. For this reason, we have included a description of how the path characteristics that streaming media providers may see are likely to evolve over time. 6.1. Within sec-trans, the term "Media Transport Protocol" is used to describe to describe the protocol of interest.  This is easier to understand if the reader assumes a protocol stack that looks something like this: </del> <ins> Within this document, the term "Media Transport Protocol" is used to describe any protocol that carries media metadata and media in its payload, and the term "Transport Protocol" describes any protocol that carries a Media Transport Protocol, or another Transport Protocol, in its payload.  This is easier to understand if the reader assumes a protocol stack that looks something like this: </ins> where <ins> "Media" would be something like the output of a codec, or other media source such as closed-captioning, </ins> "Media Format" would be something like an RTP payload format <del> RFC2736 or ISOBMFF ISOBMFF, </del> <ins> RFC2736 or an ISOBMFF ISOBMFF profile, </ins> <del> "Media Transport Protocol" would be something like RTP or HTTP, and </del> <ins> "Media Transport Protocol" would be something like RTP or DASH MPEG-DASH, and </ins> <del> "Transport Protocol" would be something like TCP or UDP. </del> <ins> "Transport Protocol" would be a protocol that provides appropriate transport services, as described in Section 5 of RFC8095. </ins> Not all possible streaming media applications follow this model, but <del> for the ones that do, it seems useful to have names for the protocol layers between Media Format and Transport Layer </del> <ins> for the ones that do, it seems useful to distinguish between the protocol layer that is aware it is transporting media, and underlying protocol layers that are not aware. As described in the RFC8095 Abstract, the IETF has standardized a number of protocols that provide transport services.  Although these protocols, taken in total, provide a wide variety of transport services, sec-trans will distinguish between two extremes: Transport protocols used to provide reliable, in-order media delivery to an endpoint, typically providing flow control and congestion control (reliable-behavior) and Transport protocols used to provide unreliable, unordered media delivery to an endpoint, without flow control or congestion control (unreliable-behavior). Because newly standardized transport protocols such as QUIC RFC9000 can evolve their transport behavior more rapidly than currently-used transport protocols, we have included a description of how the path characteristics that streaming media providers may see are likely to evolve in quic-behavior. </ins> <del> It is worth noting explicitly that the Media Transport Protocol and Transport Protocol layers might each include more than one protocol. For example, a Media Transport Protocol might run over HTTP, or over WebTransport, which in turn runs over HTTP. </del> <ins> It is worth noting explicitly that the Transport Protocol layer might include more than one protocol.  For example, a specific Media Transport Protocol might run over HTTP, or over WebTransport, which in turn runs over HTTP. </ins> It is worth noting explicitly that more complex network protocol <del> stacks are certainly possible - for instance, packets with this protocol stack may be carried in a tunnel, or in a VPN.  If these </del> <ins> stacks are certainly possible - for instance, when packets with this protocol stack are carried in a tunnel or in a VPN, the entire packet would likely appear in the payload of other protocols.  If these </ins> environments are present, streaming media operators may need to analyze their effects on applications as well. <ins> 6.1. The HLS RFC8216 and DASH MPEG-DASH media transport protocols are typically carried over HTTP, and HTTP has used TCP as its only standardized transport protocol until HTTP/3 RFC9114.  These media transport protocols use ABR response strategies as described in sec- abr to respond to changing path characteristics, and underlying transport protocols are also attempting to respond to changing path characteristics. The past success of the largely TCP-based Internet is evidence that the various flow control and congestion control mechanisms TCP has used to achieve equilibrium quickly, at a point where TCP senders do not interfere with other TCP senders for sustained periods of time (RFC5681), have been largely successful.  The Internet has continued to work even when the specific TCP mechanisms used to reach equilibrium changed over time (RFC7414).  Because TCP provided a common tool to avoid contention, even when significant TCP-based applications like FTP were largely replaced by other significant TCP- based applications like HTTP, the transport behavior remained safe for the Internet. Modern TCP implementations (I-D.ietf-tcpm-rfc793bis) continue to probe for available bandwidth, and "back off" when a network path is saturated, but may also work to avoid growing queues along network paths, which can prevent older TCP senders from detecting quickly when a network path is becoming saturated.  Congestion control mechanisms such as COPA COPA18 and BBR I-D.cardwell-iccrg-bbr- congestion-control make these decisions based on measured path delays, assuming that if the measured path delay is increasing, the sender is injecting packets onto the network path faster than the network can forward them (or the receiver can accept them) so the sender should adjust its sending rate accordingly. Although common TCP behavior has changed significantly since the days of Jacobson-Karels and RFC2001, even adding new congestion controllers such as CUBIC RFC8312, the common practice of implementing TCP as part of an operating system kernel has acted to limit how quickly TCP behavior can change.  Even with the widespread use of automated operating system update installation on many end- user systems, streaming media providers could have a reasonable expectation that they could understand TCP transport protocol behaviors, and that those behaviors would remain relatively stable in the short term. </ins> 6.2. Because UDP does not provide any feedback mechanism to senders to

Related discussion:
text: Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming.