Code change:
6.3. <del> The past success of the largely TCP-based Internet is evidence that the mechanisms TCP 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 provides 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 prevent TCP senders from detecting quickly when a network path 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. 6.4. </del> The QUIC protocol, developed from a proprietary protocol into an IETF standards-track protocol RFC9000, turns many of the statements made <del> in udp-behavior and tcp-behavior on their heads. </del> <ins> in reliable-behavior and unreliable-behavior on their heads. </ins> Although QUIC provides an alternative to the TCP and UDP transport protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in

Related discussion:
text: Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers?