Code change:
3.6. <del> Although TCP/IP has been used with a number of widely used applications that have symmetric bandwidth requirements (similar bandwidth requirements in each direction between endpoints), many widely-used Internet applications operate in client-server roles, with asymmetric bandwidth requirements.  A common example might be an HTTP GET operation, where a client sends a relatively small HTTP GET request for a resource to an HTTP server and often receives a significantly larger response carrying the requested resource.  When HTTP is commonly used to stream movie-length videos, the ratio between response size and request size can become arbitrarily large. For this reason, operators may pay more attention to downstream bandwidth utilization when planning and managing capacity.  In addition, operators have been able to deploy access networks for end users using underlying technologies that are inherently asymmetric, favoring downstream bandwidth (e.g., ADSL, cellular technologies, most IEEE 802.11 variants), assuming that users will need less upstream bandwidth than downstream bandwidth.  This strategy usually works, except when it fails because application bandwidth usage patterns have changed in ways that were not predicted. One example of this type of change was when peer-to-peer file-sharing applications gained popularity in the early 2000s.  To take one well- documented case (RFC5594), the BitTorrent application created "swarms" of hosts, uploading and downloading files to each other, rather than communicating with a server.  BitTorrent favored peers who uploaded as much as they downloaded, so new BitTorrent users had an incentive to significantly increase their upstream bandwidth utilization. The combination of the large volume of "torrents" and the peer-to- peer characteristic of swarm transfers meant that end user hosts were suddenly uploading higher volumes of traffic to more destinations than was the case before BitTorrent.  This caused at least one large Internet service provider (ISP) to attempt to "throttle" these transfers to mitigate the load these hosts placed on their network. These efforts were met by increased use of encryption in BitTorrent, and complaints to regulators calling for regulatory action. The BitTorrent case study is just one example.  However, the example is included here to make it clear that unpredicted and unpredictable massive traffic spikes may not be the result of natural disasters, but they can still have significant impacts. Especially as end users increasingly use video-based social networking applications, it will be helpful for access network providers to watch for increasing numbers of end users uploading significant amounts of content. 3.7. The causes of unpredictable usage described in sec-unpredict were more or less the result of human choices.  However, we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the COVID-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19)}. We note that other operators saw similar spikes during this period. Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) Subsequently, the Internet Architecture Board (IAB) held a COVID-19 Network Impacts Workshop IABcovid in November 2020.  Given a larger number of reports and more time to reflect, the following observations from the draft workshop report are worth considering. </del> <ins> It is also possible for usage profiles to change significantly and suddenly.  These changes are more difficult to plan for, but at a minimum, recognizing that sudden changes are happening is critical. Two examples are instructive. 3.6.1. In the first example, described in "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008" (RFC5594), when the BitTorrent filesharing application came into widespread use in 2005, sudden and unexpected growth in peer-to-peer traffic led to complaints from ISP customers about the performance of delay- sensitive traffic (VoIP and gaming).  These performance issues resulted from at least two causes: Many access networks for end users used underlying technologies that are inherently asymmetric, favoring downstream bandwidth (e.g.  ADSL, cellular technologies, most IEEE 802.11 variants), assuming that most users will need more downstream bandwidth than upstream bandwidth.  This is a good assumption for client-server applications such as streaming video or software downloads, but BitTorrent rewarded peers that uploaded as much as they downloaded, so BitTorrent users had much more symmetric usage profiles which interacted badly with these assymetric access network technologies. BitTorrent also used distributed hash tables to organize peers into a ring topology, where each peer knew its "next peer" and "previous peer".  There was no connection between the application- level ring topology and the lower-level network topology, so a peer's "next peer" might be anywhere on the reachable Internet. Traffic models that expected most communication to take place with a relatively small number of servers were unable to cope with peer-to-peer traffic that was much less predictable. Especially as end users increase use of video-based social networking applications, it will be helpful for access network providers to watch for increasing numbers of end users uploading significant amounts of content. 3.6.2. Early in 2020, the CoViD-19 pandemic and resulting quarantines and shutdowns led to significant changes in traffic patterns, due to a large number of people who suddenly started working and attending school remotely and using more interactive applications (video conferencing, in addition to streaming media).  Subsequently, the Internet Architecture Board (IAB) held a COVID-19 Network Impacts Workshop IABcovid in November 2020.  The following observations from the workshop report are worth considering. </ins> Participants describing different types of networks reported different kinds of impacts, but all types of networks saw impacts.

Related discussion:
text: 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. 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.