idnits 2.17.1 draft-ietf-mops-streaming-opcons-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 November 2020) is 1266 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOPS J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Informational A. Begen 5 Expires: 5 May 2021 Networked Media 6 S. Dawkins 7 Tencent America LLC 8 1 November 2020 10 Operational Considerations for Streaming Media 11 draft-ietf-mops-streaming-opcons-03 13 Abstract 15 This document provides an overview of operational networking issues 16 that pertain to quality of experience in delivery of video and other 17 high-bitrate media over the internet. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 5 May 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 3 54 1.1.1. Venues for Contribution and Discussion . . . . . . . 3 55 1.1.2. Template for Contributions . . . . . . . . . . . . . 3 56 1.1.3. History of Public Discussion . . . . . . . . . . . . 4 57 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 5 58 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 5 59 2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 5 60 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6 61 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8 64 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 8 65 2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 9 66 3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 10 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 10 69 3.2.1. Idle Time between Segments . . . . . . . . . . . . . 11 70 3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 11 71 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 7. Informative References . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 As the internet has grown, an increasingly large share of the traffic 81 delivered to end users has become video. Estimates put the total 82 share of internet video traffic at 75% in 2019, expected to grow to 83 82% by 2022. What's more, this estimate projects the gross volume of 84 video traffic will more than double during this time, based on a 85 compound annual growth rate continuing at 34% (from Appendix D of 86 [CVNI]). 88 In many contexts, video traffic can be handled transparently as 89 generic application-level traffic. However, as the volume of video 90 traffic continues to grow, it's becoming increasingly important to 91 consider the effects of network design decisions on application-level 92 performance, with considerations for the impact on video delivery. 94 This document aims to provide a taxonomy of networking issues as they 95 relate to quality of experience in internet video delivery. The 96 focus is on capturing characteristics of video delivery that have 97 surprised network designers or transport experts without specific 98 video expertise, since these highlight key differences between common 99 assumptions in existing networking documents and observations of 100 video delivery issues in practice. 102 Making specific recommendations for mitigating these issues is out of 103 scope, though some existing mitigations are mentioned in passing. 104 The intent is to provide a point of reference for future solution 105 proposals to use in describing how new technologies address or avoid 106 these existing observed problems. 108 1.1. Notes for Contributors and Reviewers 110 Note to RFC Editor: Please remove this section and its subsections 111 before publication. 113 This section is to provide references to make it easier to review the 114 development and discussion on the draft so far. 116 1.1.1. Venues for Contribution and Discussion 118 This document is in the Github repository at: 120 https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons 122 Readers are welcome to open issues and send pull requests for this 123 document. 125 Substantial discussion of this document should take place on the MOPS 126 working group mailing list (mops@ietf.org). 128 * Join: https://www.ietf.org/mailman/listinfo/mops 130 * Search: https://mailarchive.ietf.org/arch/browse/mops/ 132 1.1.2. Template for Contributions 134 Contributions are solicited regarding issues and considerations that 135 have an impact on media streaming operations. 137 Please note that contributions may be merged and substantially 138 edited, and as a reminder, please carefully consider the Note Well 139 before contributing: https://datatracker.ietf.org/submit/note-well/ 141 Contributions can be emailed to mops@ietf.org, submitted as issues to 142 the issue tracker of the repository in Section 1.1.1, or emailed to 143 the document authors at draft-ietf-mops-streaming-opcons@ietf.org. 145 Contributors describing an issue not yet addressed in the draft are 146 requested to provide the following information, where applicable: 148 * a suggested title or name for the issue 150 * a long-term pointer to the best reference describing the issue 152 * a short description of the nature of the issue and its impact on 153 media quality of service, including: 155 - where in the network this issue has root causes 157 - who can detect this issue when it occurs 159 * an overview of the issue's known prevalence in practice. pointers 160 to write-ups of high-profile incidents are a plus. 162 * a list of known mitigation techniques, with (for each known 163 mitigation): 165 - a name for the mitigation technique 167 - a long-term pointer to the best reference describing it 169 - a short description of the technique: 171 o what it does 173 o where in the network it operates 175 o an overview of the tradeoffs involved-how and why it's 176 helpful, what it costs. 178 - supplemental information about the technique's deployment 179 prevalence and status 181 1.1.3. History of Public Discussion 183 Presentations: 185 * IETF 105 BOF: 187 https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s 189 * IETF 106 meeting: 191 https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s 193 * MOPS Interim Meeting 2020-04-15: 195 https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s 197 * IETF 108 meeting: 199 https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s 201 2. Bandwidth Provisioning 203 2.1. Scaling Requirements for Media Delivery 205 2.1.1. Video Bitrates 207 Video bitrate selection depends on many variables. Different 208 providers give different guidelines, but an equation that 209 approximately matches the bandwidth requirement estimates from 210 several video providers is given in [MSOD]: 212 Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (MOTION_FACTOR * 1024) 214 Height and width are in pixels, frame rate is in frames per second, 215 and the motion factor is a value that ranges from 20 for a low-motion 216 talking heads video to 7 for sports, and content with a lot of screen 217 changes. 219 The motion factor captures the variability in bitrate due to the 220 amount and frequency of high-detail motion, which generally 221 influences the compressability of the content. 223 The exact bitrate required for a particular video also depends on a 224 number of specifics about the codec used and how the codec-specific 225 tuning parameters are matched to the content, but this equation 226 provides a rough estimate that approximates the usual bitrate 227 characteristics using the most common codecs and settings for 228 production traffic. 230 Here are a few common resolutions used for video content, with their 231 typical and peak per-user bandwidth requirements for 60 frames per 232 second (FPS): 234 +============+================+==========+=========+ 235 | Name | Width x Height | Typical | Peak | 236 +============+================+==========+=========+ 237 | DVD | 720 x 480 | 1.3 Mbps | 3 Mbps | 238 +------------+----------------+----------+---------+ 239 | 720p (1K) | 1280 x 720 | 3.6 Mbps | 5 Mbps | 240 +------------+----------------+----------+---------+ 241 | 1080p (2K) | 1920 x 1080 | 8.1 Mbps | 18 Mbps | 242 +------------+----------------+----------+---------+ 243 | 2160p (4k) | 3840 x 2160 | 32 Mbps | 70 Mbps | 244 +------------+----------------+----------+---------+ 246 Table 1 248 2.1.2. Virtual Reality Bitrates 250 Even the basic virtual reality (360-degree) videos (that allow users 251 to look around freely, referred to as three degrees of freedom - 252 3DoF) require substantially larger bitrates when they are captured 253 and encoded as such videos require multiple fields of view of the 254 scene. The typical multiplication factor is 8 to 10. Yet, due to 255 smart delivery methods such as viewport-based or tiled-based 256 streaming, we do not need to send the whole scene to the user. 257 Instead, the user needs only the portion corresponding to its 258 viewpoint at any given time. 260 In more immersive applications, where basic user movement (3DoF+) or 261 full user movement (6DoF) is allowed, the required bitrate grows even 262 further. In this case, the immersive content is typically referred 263 to as volumetric media. One way to represent the volumetric media is 264 to use point clouds, where streaming a single object may easily 265 require a bitrate of 30 Mbps or higher. Refer to [PCC] for more 266 details. 268 2.2. Path Requirements 270 The bitrate requirements in Section 2.1 are per end-user actively 271 consuming a media feed, so in the worst case, the bitrate demands can 272 be multiplied by the number of simultaneous users to find the 273 bandwidth requirements for a router on the delivery path with that 274 number of users downstream. For example, at a node with 10,000 275 downstream users simultaneously consuming video streams, 276 approximately 80 Gbps would be necessary in order for all of them to 277 get typical content at 1080p resolution at 60 fps, or up to 180 Gbps 278 to get sustained high-motion content such as sports, while 279 maintaining the same resolution. 281 However, when there is some overlap in the feeds being consumed by 282 end users, it is sometimes possible to reduce the bandwidth 283 provisioning requirements for the network by performing some kind of 284 replication within the network. This can be achieved via object 285 caching with delivery of replicated objects over individual 286 connections, and/or by packet-level replication using multicast. 288 To the extent that replication of popular content can be performed, 289 bandwidth requirements at peering or ingest points can be reduced to 290 as low as a per-feed requirement instead of a per-user requirement. 292 2.3. Caching Systems 294 When demand for content is relatively predictable, and especially 295 when that content is relatively static, caching content close to 296 requesters, and pre-loading caches to respond quickly to initial 297 requests, is often useful (for example, HTTP/1.1 caching is described 298 in [RFC7234]). This is subject to the usual considerations for 299 caching - for example, how much data must be cached to make a 300 significant difference to the requester, and how the benefits of 301 caching and pre-loading caches balances against the costs of tracking 302 "stale" content in caches and refreshing that content. 304 It is worth noting that not all high-demand content is also "live" 305 content. One popular example is when popular streaming content can 306 be staged close to a significant number of requesters, as can happen 307 when a new episode of a popular show is released. This content may 308 be largely stable, so low-cost to maintain in multiple places 309 throughout the Internet. This can reduce demands for high end-to-end 310 bandwidth without having to use mechanisms like multicast. 312 Caching and pre-loading can also reduce exposure to peering point 313 congestion, since less traffic crosses the peering point exchanges if 314 the caches are placed in peer networks, and could be pre-loaded 315 during off-peak hours, using "Lower-Effort Per-Hop Behavior (LE PHB) 316 for Differentiated Services" [RFC8622], "Low Extra Delay Background 317 Transport (LEDBAT)" [RFC6817], or similar mechanisms. 319 All of this depends, of course, on the ability of a content provider 320 to predict usage and provision bandwidth, caching, and other 321 mechanisms to meet the needs of users. In some cases (Section 2.4), 322 this is relatively routine, but in other cases, it is more difficult 323 (Section 2.5, Section 2.6). 325 2.4. Predictable Usage Profiles 327 Historical data shows that users consume more video and videos at 328 higher bitrates than they did in the past on their connected devices. 329 Improvements in the codecs that help with reducing the encoding 330 bitrates with better compression algorithms could not have offset the 331 increase in the demand for the higher quality video (higher 332 resolution, higher frame rate, better color gamut, better dynamic 333 range, etc.). In particular, mobile data usage has shown a large 334 jump over the years due to increased consumption of entertainement as 335 well as conversational video. 337 TBD: insert charts showing historical relative data usage patterns 338 with error bars by time of day in consumer networks? 340 Cross-ref vs. video quality by time of day in practice for some case 341 study? Not sure if there's a good way to capture a generalized 342 insight here, but it seems worth making the point that demand 343 projections can be used to help with e.g. power consumption with 344 routing architectures that provide for modular scalability. 346 2.5. Unpredictable Usage Profiles 348 Although TCP/IP has been used with a number of widely used 349 applications that have symmetric bandwidth requirements (similar 350 bandwidth requirements in each direction between endpoints), many 351 widely-used Internet applications operate in client-server roles, 352 with asymmetric bandwidth requirements. A common example might be an 353 HTTP GET operation, where a client sends a relatively small HTTP GET 354 request for a resource to an HTTP server, and often receives a 355 significantly larger response carrying the requested resource. When 356 HTTP is commonly used to stream movie-length video, the ratio between 357 response size and request size can become quite large. 359 For this reason, operators may pay more attention to downstream 360 bandwidth utilization when planning and managing capacity. In 361 addition, operators have been able to deploy access networks for end 362 users using underlying technologies that are inherently asymetric, 363 favoring downstream bandwidth (e.g. ADSL, cellular technologies, 364 most IEEE 802.11 variants), assuming that users will need less 365 upstream bandwidth than downstream bandwidth. This strategy usually 366 works, except when it does not, because application bandwidth usage 367 patterns have changed. 369 One example of this type of change was when peer-to-peer file sharing 370 applications gained popularity in the early 2000s. To take one well- 371 documented case ([RFC5594]), the Bittorrent application created 372 "swarms" of hosts, uploading and downloading files to each other, 373 rather than communicating with a server. Bittorrent favored peers 374 who uploaded as much as they downloaded, so that new Bittorrent users 375 had an incentive to significantly increase their upstream bandwidth 376 utilization. 378 The combination of the large volume of "torrents" and the peer-to- 379 peer characteristic of swarm transfers meant that end user hosts were 380 suddenly uploading higher volumes of traffic to more destinations 381 than was the case before Bittorrent. This caused at least one large 382 ISP to attempt to "throttle" these transfers, to mitigate the load 383 that these hosts placed on their network. These efforts were met by 384 increased use of encryption in Bittorrent, similar to an arms race, 385 and set off discussions about "Net Neutrality" and calls for 386 regulatory action. 388 Especially as end users increase use of video-based social networking 389 applications, it will be helpful for access network providers to 390 watch for increasing numbers of end users uploading significant 391 amounts of content. 393 2.6. Extremely Unpredictable Usage Profiles 395 The causes of unpredictable usage described in Section 2.5 were more 396 or less the result of human choices, but we were reminded during a 397 post-IETF 107 meeting that humans are not always in control, and 398 forces of nature can cause enormous fluctuations in traffic patterns. 400 In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19 401 pandemic broke out in early 2020, 403 * Comcast's streaming and web video consumption rose by 38%, with 404 their reported peak traffic up 32% overall between March 1 to 405 March 30 [Comcast], 407 * AT&T reported a 28% jump in core network traffic (single day in 408 April, as compared to pre stay-at-home daily average traffic), 409 with video accounting for nearly half of all mobile network 410 traffic, while social networking and web browsing remained the 411 highest percentage (almost a quarter each) of overall mobility 412 traffic [ATT], and 414 * Verizon reported similar trends with video traffic up 36% over an 415 average day (pre COVID-19) [Verizon]. 417 We note that other operators saw similar spikes during this time 418 period. Craig Labowitz [Labovitz] reported 419 * Weekday peak traffic increases over 45%-50% from pre-lockdown 420 levels, 422 * A 30% increase in upstream traffic over their pre-pandemic levels, 423 and 425 * A steady increase in the overall volume of DDoS traffic, with 426 amounts exceeding the pre-pandemic levels by 40%. (He attributed 427 this increase to the significant rise in gaming-related DDoS 428 attacks ([LabovitzDDoS]), as gaming usage also increased.) 430 3. Adaptive Bitrate 432 3.1. Overview 434 Adaptive BitRate (ABR) is a sort of application-level response 435 strategy in which the receiving media player attempts to detect the 436 available bandwidth of the network path by experiment or by observing 437 the successful application-layer download speed, then chooses a video 438 bitrate (among the limited number of available options) that fits 439 within that bandwidth, typically adjusting as changes in available 440 bandwidth occur in the network or changes in capabilities occur in 441 the player (such as available memory, CPU, display size, etc.). 443 The choice of bitrate occurs within the context of optimizing for 444 some metric monitored by the video player, such as highest achievable 445 video quality, or lowest rate of expected rebuffering events. 447 3.2. Segmented Delivery 449 ABR playback is commonly implemented by video players using HLS 450 [RFC8216] or DASH [DASH] to perform a reliable segmented delivery of 451 video data over HTTP. Different player implementations and receiving 452 devices use different strategies, often proprietary algorithms 453 (called rate adaptation or bitrate selection algorithms), to perform 454 available bandwidth estimation/prediction and the bitrate selection. 455 Most players only use passive observations, i.e., they do not 456 generate probe traffic to measure the available bandwidth. 458 This kind of bandwidth-measurement systems can experience trouble in 459 several ways that can be affected by networking design choices. 461 3.2.1. Idle Time between Segments 463 When the bitrate selection is successfully chosen below the available 464 capacity of the network path, the response to a segment request will 465 typically complete in less absolute time than the duration of the 466 requested segment. The resulting idle time within the connection 467 carrying the segments has a few surprising consequences: 469 * Mobile flow-bandwidth spectrum and timing mapping. 471 * TCP slow-start when restarting after idle requires multiple RTTs 472 to re-establish a throughput at the network's available capacity. 473 On high-RTT paths or with small enough segments, this can produce 474 a falsely low application-visible measurement of the available 475 network capacity. 477 A detailed investigation of this phenomenon is available in 478 [NOSSDAV12]. 480 3.2.2. Head-of-Line Blocking 482 In the event of a lost packet on a TCP connection with SACK support 483 (a common case for segmented delivery in practice), loss of a packet 484 can provide a confusing bandwidth signal to the receiving 485 application. Because of the sliding window in TCP, many packets may 486 be accepted by the receiver without being available to the 487 application until the missing packet arrives. Upon arrival of the 488 one missing packet after retransmit, the receiver will suddenly get 489 access to a lot of data at the same time. 491 To a receiver measuring bytes received per unit time at the 492 application layer, and interpreting it as an estimate of the 493 available network bandwidth, this appears as a high jitter in the 494 goodput measurement. 496 Active Queue Management (AQM) systems such as PIE [RFC8033] or 497 variants of RED [RFC2309] that induce early random loss under 498 congestion can mitigate this by using ECN [RFC3168] where available. 499 ECN provides a congestion signal and induce a similar backoff in 500 flows that use Explicit Congestion Notification-capable transport, 501 but by avoiding loss avoids inducing head-of-line blocking effects in 502 TCP connections. 504 3.3. Unreliable Transport 506 In contrast to segmented delivery, several applications use UDP or 507 unreliable SCTP to deliver RTP or raw TS-formatted video. 509 Under congestion and loss, this approach generally experiences more 510 video artifacts with fewer delay or head-of-line blocking effects. 511 Often one of the key goals is to reduce latency, to better support 512 applications like videoconferencing, or for other live-action video 513 with interactive components, such as some sporting events. 515 Congestion avoidance strategies for this kind of deployment vary 516 widely in practice, ranging from some streams that are entirely 517 unresponsive to using feedback signaling to change encoder settings 518 (as in [RFC5762]), or to use fewer enhancement layers (as in 519 [RFC6190]), to proprietary methods for detecting quality of 520 experience issues and cutting off video. 522 4. IANA Considerations 524 This document requires no actions from IANA. 526 5. Security Considerations 528 This document introduces no new security issues. 530 6. Acknowledgements 532 Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle 533 Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, 534 and Mike English for their very helpful reviews and comments. 536 7. Informative References 538 [ATT] AT&T, "Tuesday (March 24, 2020) Network Insights", March 539 2020, . 541 [Comcast] CNBC, "Comcast sees network traffic surge amid coronavirus 542 outbreak", March 2020, 543 . 546 [CVNI] Cisco Systems, Inc., "Cisco Visual Networking Index: 547 Forecast and Trends, 2017-2022 White Paper", 27 February 548 2019, . 552 [DASH] "Information technology -- Dynamic adaptive streaming over 553 HTTP (DASH) -- Part 1: Media presentation description and 554 segment formats", ISO/IEC 23009-1:2019, 2019. 556 [Labovitz] Labovitz, C. and Nokia Deepfield, "Network traffic 557 insights in the time of COVID-19: April 9 update", April 558 2020, . 561 [LabovitzDDoS] 562 Takahashi, D. and Venture Beat, "Why the game industry is 563 still vulnerable to DDoS attacks", May 2018, 564 . 568 [Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video 569 Alliance", 2020, . 574 [MSOD] Akamai Technologies, Inc., "Media Services On Demand: 575 Encoder Best Practices", 2019, . 580 [NOSSDAV12] 581 al., S.A.e., "What Happens When HTTP Adaptive Streaming 582 Players Compete for Bandwidth?", June 2012, 583 . 585 [PCC] al., S.S.e., "Emerging MPEG Standards for Point Cloud 586 Compression", March 2019, 587 . 589 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 590 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 591 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 592 S., Wroclawski, J., and L. Zhang, "Recommendations on 593 Queue Management and Congestion Avoidance in the 594 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 595 . 597 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 598 of Explicit Congestion Notification (ECN) to IP", 599 RFC 3168, DOI 10.17487/RFC3168, September 2001, 600 . 602 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 603 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 604 RFC 5594, DOI 10.17487/RFC5594, July 2009, 605 . 607 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 608 Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 609 2010, . 611 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 612 Eleftheriadis, "RTP Payload Format for Scalable Video 613 Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, 614 . 616 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 617 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 618 DOI 10.17487/RFC6817, December 2012, 619 . 621 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 622 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 623 RFC 7234, DOI 10.17487/RFC7234, June 2014, 624 . 626 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 627 "Proportional Integral Controller Enhanced (PIE): A 628 Lightweight Control Scheme to Address the Bufferbloat 629 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 630 . 632 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 633 RFC 8216, DOI 10.17487/RFC8216, August 2017, 634 . 636 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 637 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 638 June 2019, . 640 [Verizon] Rorbuck, M. and Fierce Telecom, "Verizon: U.S. network 641 usage starts to normalize as subscribers settle into new 642 routines", April 2020, 643 . 647 Authors' Addresses 648 Jake Holland 649 Akamai Technologies, Inc. 650 150 Broadway 651 Cambridge, MA 02144, 652 United States of America 654 Email: jakeholland.net@gmail.com 656 Ali Begen 657 Networked Media 658 Turkey 660 Email: ali.begen@networked.media 662 Spencer Dawkins 663 Tencent America LLC 664 United States of America 666 Email: spencerdawkins.ietf@gmail.com