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: 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? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section