idnits 2.17.1 draft-ietf-mops-streaming-opcons-01.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 (9 March 2020) is 1502 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: 10 September 2020 Networked Media 6 S. Dawkins 7 Tencent America LLC 8 9 March 2020 10 Operational Considerations for Streaming Media 11 draft-ietf-mops-streaming-opcons-01 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 10 September 2020. 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. Venues for Contribution and Discussion . . . . . . . . . 3 54 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 3 55 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 3 56 2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 3 57 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 4 58 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 5 61 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 5 62 3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Idle Time between Segments . . . . . . . . . . . . . 7 66 3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 7 67 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 8 68 4. Doc History and Side Notes . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Informative References . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 As the internet has grown, an increasingly large share of the traffic 78 delivered to end users has become video. Estimates put the total 79 share of internet video traffic at 75% in 2019, expected to grow to 80 82% by 2022. What's more, this estimate projects the gross volume of 81 video traffic will more than double during this time, based on a 82 compound annual growth rate continuing at 34% (from Appendix D of 83 [CVNI]). 85 In many contexts, video traffic can be handled transparently as 86 generic application-level traffic. However, as the volume of video 87 traffic continues to grow, it's becoming increasingly important to 88 consider the effects of network design decisions on application-level 89 performance, with considerations for the impact on video delivery. 91 This document aims to provide a taxonomy of networking issues as they 92 relate to quality of experience in internet video delivery. The 93 focus is on capturing characteristics of video delivery that have 94 surprised network designers or transport experts without specific 95 video expertise, since these highlight key differences between common 96 assumptions in existing networking documents and observations of 97 video delivery issues in practice. 99 Making specific recommendations for mitigating these issues is out of 100 scope, though some existing mitigations are mentioned in passing. 101 The intent is to provide a point of reference for future solution 102 proposals to use in describing how new technologies address or avoid 103 these existing observed problems. 105 1.1. Venues for Contribution and Discussion 107 Note to RFC Editor: Please remove this section before publication 109 (To the editor: check this repository URL after the draft is adopted. 110 The working group may create its own repository) 112 This document is in the Github repository at 113 https://github.com/GrumpyOldTroll/ietf-mops-drafts. Readers are 114 welcome to open issues and send pull requests for this document. 116 Substantial discussion of this document should take place on the MOPS 117 working group mailing list (mops@ietf.org). 119 2. Bandwidth Provisioning 121 2.1. Scaling Requirements for Media Delivery 123 2.1.1. Video Bitrates 125 Video bitrate selection depends on many variables. Different 126 providers give different guidelines, but an equation that 127 approximately matches the bandwidth requirement estimates from 128 several video providers is given in [MSOD]: 130 Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (15 * 1024) 132 Height and width are in pixels, and frame rate is in frames per 133 second. The actual bitrate required for a specific video will also 134 depend on the codec used, fidelity desired and some other 135 characteristics of the video itself, such as the amount and frequency 136 of high-detail motion, which may influence the compressability of the 137 content, but this equation provides a rough estimate. 139 Here are a few common resolutions used for video content, with their 140 typical per-user bandwidth requirements according to this formula: 142 +------------+----------------+-------------------------------+ 143 | Name | Width x Height | Approximate Bitrate for 60fps | 144 +============+================+===============================+ 145 | DVD | 720 x 480 | 1.3 Mbps | 146 +------------+----------------+-------------------------------+ 147 | 720p (1K) | 1280 x 720 | 3.6 Mbps | 148 +------------+----------------+-------------------------------+ 149 | 1080p (2K) | 1920 x 1080 | 8.1 Mbps | 150 +------------+----------------+-------------------------------+ 151 | 2160p (4k) | 3840 x 2160 | 32 Mbps | 152 +------------+----------------+-------------------------------+ 154 Table 1 156 2.1.2. Virtual Reality Bitrates 158 Even the basic virtual reality (360-degree) videos (that allow users 159 to look around freely, referred to as three degrees of freedom - 160 3DoF) require substantially larger bitrates when they are captured 161 and encoded as such videos require multiple fields of view of the 162 scene. The typical multiplication factor is 8 to 10. Yet, due to 163 smart delivery methods such as viewport-based or tiled-based 164 streaming, we do not need to send the whole scene to the user. 165 Instead, the user needs only the portion corresponding to its 166 viewpoint at any given time. 168 In more immersive applications, where basic user movement (3DoF+) or 169 full user movement (6DoF) is allowed, the required bitrate grows even 170 further. In this case, the immersive content is typically referred 171 to as volumetric media. One way to represent the volumetric media is 172 to use point clouds, where streaming a single object may easily 173 require a bitrate of 30 Mbps or higher. Refer to [PCC] for more 174 details. 176 2.2. Path Requirements 178 The bitrate requirements in Section 2.1 are per end-user actively 179 consuming a media feed, so in the worst case, the bitrate demands can 180 be multiplied by the number of simultaneous users to find the 181 bandwidth requirements for a router on the delivery path with that 182 number of users downstream. For example, at a node with 10,000 183 downstream users simultaneously consuming video streams, 184 approximately up to 80 Gbps would be necessary in order for all of 185 them to get 1080p resolution at 60 fps. 187 However, when there is some overlap in the feeds being consumed by 188 end users, it is sometimes possible to reduce the bandwidth 189 provisioning requirements for the network by performing some kind of 190 replication within the network. This can be achieved via object 191 caching with delivery of replicated objects over individual 192 connections, and/or by packet-level replication using multicast. 194 To the extent that replication of popular content can be performed, 195 bandwidth requirements at peering or ingest points can be reduced to 196 as low as a per-feed requirement instead of a per-user requirement. 198 2.3. Caching Systems 200 TBD: pros, cons, tradeoffs of caching designs at different locations 201 within the network? 203 Peak vs. average provisioning, and effects on peering point 204 congestion under peak load? 206 Provisioning issues for caching systems? 208 2.4. Predictable Usage Profiles 210 Historical data shows that users consume more video and videos at 211 higher bitrates than they did in the past on their connected devices. 212 Improvements in the codecs that help with reducing the encoding 213 bitrates with better compression algorithms could not have offset the 214 increase in the demand for the higher quality video (higher 215 resolution, higher frame rate, better color gamut, better dynamic 216 range, etc.). In particular, mobile data usage has shown a large 217 jump over the years due to increased consumption of entertainement as 218 well as conversational video. 220 TBD: insert charts showing historical relative data usage patterns 221 with error bars by time of day in consumer networks? 223 Cross-ref vs. video quality by time of day in practice for some case 224 study? Not sure if there's a good way to capture a generalized 225 insight here, but it seems worth making the point that demand 226 projections can be used to help with e.g. power consumption with 227 routing architectures that provide for modular scalability. 229 2.5. Unpredictable Usage Profiles 231 Although TCP/IP has been used with a number of widely used 232 applications that have symmetric bandwidth requirements (similar 233 bandwidth requirements in each direction between endpoints), many 234 widely-used Internet applications operate in client-server roles, 235 with asymmetric bandwidth requirements. A common example might be an 236 HTTP GET operation, where a client sends a relatively small HTTP GET 237 request for a resource to an HTTP server, and often receives a 238 significantly larger response carrying the requested resource. When 239 HTTP is commonly used to stream movie-length video, the ratio between 240 response size and request size can become quite large. 242 For this reason, operators may pay more attention to downstream 243 bandwidth utilization when planning and managing capacity. In 244 addition, operators have been able to deploy access networks for end 245 users using underlying technologies that are inherently asymetric, 246 favoring downstream bandwidth (e.g. ADSL, cellular technologies, 247 most IEEE 802.11 variants), assuming that users will need less 248 upstream bandwidth than downstream bandwidth. This strategy usually 249 works, except when it does not, because application bandwidth usage 250 patterns have changed. 252 One example of this type of change was when peer-to-peer file sharing 253 applications gained popularity in the early 2000s. To take one well- 254 documented case ([RFC5594]), the Bittorrent application created 255 "swarms" of hosts, uploading and downloading files to each other, 256 rather than communicating with a server. Bittorrent favored peers 257 who uploaded as much as they downloaded, so that new Bittorrent users 258 had an incentive to significantly increase their upstream bandwidth 259 utilization. 261 The combination of the large volume of "torrents" and the peer-to- 262 peer characteristic of swarm transfers meant that end user hosts were 263 suddenly uploading higher volumes of traffic to more destinations 264 than was the case before Bittorrent. This caused at least one large 265 ISP to attempt to "throttle" these transfers, to mitigate the load 266 that these hosts placed on their network. These efforts were met by 267 increased use of encryption in Bittorrent, similar to an arms race, 268 and set off discussions about "Net Neutrality" and calls for 269 regulatory action. 271 Especially as end users increase use of video-based social networking 272 applications, it will be helpful for access network providers to 273 watch for increasing numbers of end users uploading significant 274 amounts of content. 276 3. Adaptive Bitrate 278 3.1. Overview 280 Adaptive BitRate (ABR) is a sort of application-level response 281 strategy in which the receiving media player attempts to detect the 282 available bandwidth of the network path by experiment or by observing 283 the successful application-layer download speed, then chooses a video 284 bitrate (among the limited number of available options) that fits 285 within that bandwidth, typically adjusting as changes in available 286 bandwidth occur in the network or changes in capabilities occur in 287 the player (such as available memory, CPU, display size, etc.). 289 The choice of bitrate occurs within the context of optimizing for 290 some metric monitored by the video player, such as highest achievable 291 video quality, or lowest rate of expected rebuffering events. 293 3.2. Segmented Delivery 295 ABR playback is commonly implemented by video players using HLS 296 [RFC8216] or DASH [DASH] to perform a reliable segmented delivery of 297 video data over HTTP. Different player implementations and receiving 298 devices use different strategies, often proprietary algorithms 299 (called rate adaptation or bitrate selection algorithms), to perform 300 available bandwidth estimation/prediction and the bitrate selection. 301 Most players only use passive observations, i.e., they do not 302 generate probe traffic to measure the available bandwidth. 304 This kind of bandwidth-measurement systems can experience trouble in 305 several ways that can be affected by networking design choices. 307 3.2.1. Idle Time between Segments 309 When the bitrate selection is successfully chosen below the available 310 capacity of the network path, the response to a segment request will 311 typically complete in less absolute time than the duration of the 312 requested segment. The resulting idle time within the connection 313 carrying the segments has a few surprising consequences: 315 * Mobile flow-bandwidth spectrum and timing mapping. 317 * TCP slow-start when restarting after idle requires multiple RTTs 318 to re-establish a throughput at the network's available capacity. 319 On high-RTT paths or with small enough segments, this can produce 320 a falsely low application-visible measurement of the available 321 network capacity. 323 A detailed investigation of this phenomenon is available in 324 [NOSSDAV12]. 326 3.2.2. Head-of-Line Blocking 328 In the event of a lost packet on a TCP connection with SACK support 329 (a common case for segmented delivery in practice), loss of a packet 330 can provide a confusing bandwidth signal to the receiving 331 application. Because of the sliding window in TCP, many packets may 332 be accepted by the receiver without being available to the 333 application until the missing packet arrives. Upon arrival of the 334 one missing packet after retransmit, the receiver will suddenly get 335 access to a lot of data at the same time. 337 To a receiver measuring bytes received per unit time at the 338 application layer, and interpreting it as an estimate of the 339 available network bandwidth, this appears as a high jitter in the 340 goodput measurement. 342 Active Queue Management (AQM) systems such as PIE [RFC8033] or 343 variants of RED [RFC2309] that induce early random loss under 344 congestion can mitigate this by using ECN [RFC3168] where available. 345 ECN provides a congestion signal and induce a similar backoff in 346 flows that use Explicit Congestion Notification-capable transport, 347 but by avoiding loss avoids inducing head-of-line blocking effects in 348 TCP connections. 350 3.3. Unreliable Transport 352 In contrast to segmented delivery, several applications use UDP or 353 unreliable SCTP to deliver RTP or raw TS-formatted video. 355 Under congestion and loss, this approach generally experiences more 356 video artifacts with fewer delay or head-of-line blocking effects. 357 Often one of the key goals is to reduce latency, to better support 358 applications like videoconferencing, or for other live-action video 359 with interactive components, such as some sporting events. 361 Congestion avoidance strategies for this kind of deployment vary 362 widely in practice, ranging from some streams that are entirely 363 unresponsive to using feedback signaling to change encoder settings 364 (as in [RFC5762]), or to use fewer enhancement layers (as in 365 [RFC6190]), to proprietary methods for detecting quality of 366 experience issues and cutting off video. 368 4. Doc History and Side Notes 370 Note to RFC Editor: Please remove this section before publication 372 TBD: suggestion from mic at IETF 106 (Mark Nottingham): dive into the 373 different constraints coming from different parts of the network or 374 distribution channels. (regarding questions about how to describe the 375 disconnect between demand vs. capacity, while keeping good archival 376 value.) https://www.youtube.com/watch?v=4_k340xT2jM&t=13m 378 TBD: suggestion from mic at IETF 106 (Dave Oran + Glenn Deen 379 responding): pre-placement for many use cases is useful-distinguish 380 between live vs. cacheable. "People assume high-demand == live, but 381 not always true" with popular netflix example. 383 (Glenn): something about latency requirements for cached vs. 384 streaming on live vs. pre-recorded content, and breaking 385 requirements into 2 separate charts. also: "Standardized ladder" for 386 adaptive bit rate rates suggested, declined as out of scope. 387 https://www.youtube.com/watch?v=4_k340xT2jM&t=14m15s 389 TBD: suggestion at the mic from IETF 106 (Aaron Falk): include 390 industry standard metrics from citations, some standard scoping 391 metrics may be already defined. https://www.youtube.com/ 392 watch?v=4_k340xT2jM&t=19m15s 394 5. IANA Considerations 396 This document requires no actions from IANA. 398 6. Security Considerations 400 This document introduces no new security issues. 402 7. Acknowledgements 404 Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle 405 Rose, and Leslie Daigle for their very helpful reviews and comments. 407 8. Informative References 409 [CVNI] Cisco Systems, Inc., "Cisco Visual Networking Index: 410 Forecast and Trends, 2017-2022 White Paper", 27 February 411 2019, . 415 [DASH] "Information technology -- Dynamic adaptive streaming over 416 HTTP (DASH) -- Part 1: Media presentation description and 417 segment formats", ISO/IEC 23009-1:2019, 2019. 419 [MSOD] Akamai Technologies, Inc., "Media Services On Demand: 420 Encoder Best Practices", 2019, . 425 [NOSSDAV12] 426 al., S.A.e., "What Happens When HTTP Adaptive Streaming 427 Players Compete for Bandwidth?", June 2012, 428 . 430 [PCC] al., S.S.e., "Emerging MPEG Standards for Point Cloud 431 Compression", March 2019, 432 . 434 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 435 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 436 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 437 S., Wroclawski, J., and L. Zhang, "Recommendations on 438 Queue Management and Congestion Avoidance in the 439 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 440 . 442 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 443 of Explicit Congestion Notification (ECN) to IP", 444 RFC 3168, DOI 10.17487/RFC3168, September 2001, 445 . 447 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 448 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 449 RFC 5594, DOI 10.17487/RFC5594, July 2009, 450 . 452 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 453 Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 454 2010, . 456 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 457 Eleftheriadis, "RTP Payload Format for Scalable Video 458 Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, 459 . 461 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 462 "Proportional Integral Controller Enhanced (PIE): A 463 Lightweight Control Scheme to Address the Bufferbloat 464 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 465 . 467 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 468 RFC 8216, DOI 10.17487/RFC8216, August 2017, 469 . 471 Authors' Addresses 473 Jake Holland 474 Akamai Technologies, Inc. 475 150 Broadway 476 Cambridge, MA 02144, 477 United States of America 479 Email: jakeholland.net@gmail.com 481 Ali Begen 482 Networked Media 483 Turkey 485 Email: ali.begen@networked.media 487 Spencer Dawkins 488 Tencent America LLC 489 United States of America 491 Email: spencerdawkins.ietf@gmail.com