idnits 2.17.1 draft-jholland-mops-taxonomy-00.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 (July 07, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC2309' is defined on line 319, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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 July 07, 2019 5 Expires: January 8, 2020 7 Taxonomy of Issues in Internet Media 8 draft-jholland-mops-taxonomy-00 10 Abstract 12 This document provides a taxonomy of networking issues that pertain 13 to quality of experience in delivery of video or other high-bitrate 14 media over the internet. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 8, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 3 52 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 3 53 2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 3 54 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 3 55 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 4 57 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 4 58 3. Adaptive Bit Rate . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Idle Time Between Segments . . . . . . . . . . . . . 5 62 3.2.2. Head of Line Blocking . . . . . . . . . . . . . . . . 6 63 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 As the internet has grown, an increasingly large share of the traffic 74 delivered to end users has become video. Estimates put the total 75 share of internet video traffic at 75% in 2019, expected to grow to 76 82% by 2022. What's more, this estimate projects the gross volume of 77 video traffic will more than double during this time, based on a 78 compound annual growth rate continuing at 34% (from Appendix D of 79 [CVNI]). 81 In many contexts, video traffic can be handled transparently as 82 generic application-level traffic. However, as the volume of video 83 traffic continues to grow, it's becoming increasingly important to 84 consider the effects of network design decisions on application-level 85 performance, with considerations for the impact on video delivery. 87 This document aims to provide a taxonomy of networking issues as they 88 relate to quality of experience in internet video delivery. The 89 focus is on capturing characteristics of video delivery that have 90 surprised network designers or transport experts without specific 91 video expertise, since these highlight key differences between common 92 assumptions in existing networking documents and observations of 93 video delivery issues in practice. 95 Making specific recommendations for mitigating these issues is out of 96 scope (though some existing mitigations might be mentioned in 97 passing). The intent is to provide a point of reference for future 98 solution proposals to use in describing how new technologies address 99 or avoid these existing observed problems. 101 2. Bandwidth Provisioning 103 2.1. Scaling Requirements for Media Delivery 105 2.1.1. Video Bitrates 107 Video bit-rate selection depends on many variables. Different 108 providers give different guidelines, but an equation that 109 approximately matches the bandwidth requirement estimates from 110 several video providers is given in [MSOD]: 112 Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (7 * 1024) 114 Height and width are in pixels, and frame rate in frames per second. 115 The actual bit-rate required for a specific video will also depend on 116 the codec used and some other characteristics of the video itself, 117 such as the frequency of high-detail motion, which may influence the 118 compressability of the content, but this equation provides a rough 119 estimate. 121 Here are a few common resolutions used for video content, with their 122 minimum per-user bandwidth requirements according to this formula: 124 +------------+----------------+--------------------------------+ 125 | Name | Width x Height | Approximate Bit-rate for 60fps | 126 +------------+----------------+--------------------------------+ 127 | DVD | 720 x 480 | 3 Mbps | 128 | | | | 129 | 720p | 1280 x 720 | 8 Mbps | 130 | | | | 131 | 1080p | 1920 x 1080 | 18 Mbps | 132 | | | | 133 | 2160p (4k) | 3840 x 2160 | 70 Mbps | 134 +------------+----------------+--------------------------------+ 136 2.1.2. Virtual Reality Bitrates 138 TBD: Reference and/or adapt content from expired work-in-progress 139 [I-D.han-iccrg-arvr-transport-problem]. 141 The punchline is that it starts at a bare minimum of 22 Mbps mean 142 with a 130 Mbps peak rate, up to 3.3 Gbps mean with 38 Gbps peak for 143 high-end technology. 145 2.2. Path Requirements 147 The bit-rate requirements in Section 2.1 are per end-user actively 148 consuming a media feed, so in the worst case, the bit-rate demands 149 can be multiplied by the number of simultaneous users to find the 150 bandwidth requirements for a router on the delivery path with that 151 number of users downstream. For example, at a node with 10,000 152 downstream users simultaneously consuming video streams, 153 approximately up to 180 Gbps would be necessary in order for all of 154 them to get 1080p resolution at 60 fps. 156 However, when there is some overlap in the feeds being consumed by 157 end users, it is sometimes possible to reduce the bandwidth 158 provisioning requirements for the network by performing some kind of 159 replication within the network. This can be achieved via object 160 caching with delivery of replicated objects over individual 161 connections, and/or by packet-level replication using multicast. 163 To the extent that replication of popular content can be performed, 164 bandwidth requirements at peering or ingest points can sometimes be 165 reduced to a per-feed requirement instead of a per-user requirement. 167 2.3. Caching Systems 169 TBD: pros and cons of caching decisions at different locations within 170 the network? 172 Peak vs. average provisioning, and effects on peering point 173 congestion under peak load? 175 Provisioning issues for caching systems? 177 2.4. Predictable Usage Profiles 179 TBD: insert charts showing historical relative data usage patterns 180 with error bars by time of day in consumer networks? 182 Cross-ref vs. video quality by time of day in practice for some case 183 study? Not sure if there's a good way to capture a generalized 184 insight here, but it seems worth making the point that demand 185 projections can be used to help with e.g. power consumption with 186 routing architectures that provide for modular scalability. 188 3. Adaptive Bit Rate 190 3.1. Overview 192 Adaptive Bit-Rate (ABR) is a sort of application-level congestion 193 response strategy in which the receiving media player attempts to 194 detect the available bandwidth of the network path by experiment or 195 by observing the successful application-layer download speed, then 196 chooses a video bitrate that fits within that bandwidth, typically 197 adjusting as changes in available bandwidth occur in the network. 199 The choice of bit-rate occurs within the context of optimizing for 200 some metric monitored by the video player, such as highest achievable 201 video quality, or lowest rate of expected rebuffering events. 203 3.2. Segmented Delivery 205 ABR strategies are commonly implemented by video players using HLS 206 [RFC8216] or DASH [DASH] to perform a reliable segment delivery of 207 video data over HTTP. Different player implementations and receiving 208 devices use different strategies, often proprietary algorithms, to 209 perform the bit-rate selection and available bandwidth estimation. 211 This kind of bandwidth-detection system can experience trouble in 212 several ways that can be affected by networking design choices. 214 3.2.1. Idle Time Between Segments 216 When the bit-rate selection is successfully chosen below the 217 available capacity of the network path, the response to a segment 218 request will complete in less absolute time than the video bit-rate 219 speed. 221 The resulting idle time within the connection carrying the segments 222 has a few surprising consequences: 224 o Mobile flow-bandwidth spectrum and timing mapping. 226 o TCP Slow-start when restarting after idle requires multiple RTTs 227 to re-establish a throughput at the network's available capacity. 228 On high-RTT paths or with small enough segments, this can produce 229 a falsely low application-visible measurement of the available 230 network capacity. 232 3.2.2. Head of Line Blocking 234 In the event of a lost packet on a TCP connection with SACK support 235 (a common case for segmented delivery in practice), loss of a packet 236 can provide a confusing bandwidth signal to the receiving 237 application. Because of the sliding window in TCP, many packets may 238 be accepted by the receiver without being available to the 239 application until the missing packet arrives. Upon arrival of the 240 one missing packet after retransmit, the receiver will suddenly get 241 access to a lot of data at the same time. 243 To a receiver measuring bytes received per unit time at the 244 application layer, and interpreting it as an estimate of the 245 available network bandwidth, this appears as a high jitter in the 246 goodput measurement. 248 Active Queue Management (AQM) systems such as PIE [RFC8033] or 249 variants of RED [RFC2309]} that induce early random loss under 250 congestion can mitigate this by using ECN [RFC3168] where available. 251 ECN provides a congestion signal and induce a similar backoff in 252 flows that use Explicit Congestion Notification-capable transport, 253 but by avoiding loss avoids inducing head-of-line blocking effects in 254 TCP connections. 256 3.3. Unreliable Transport 258 In contrast to segmented delivery, several applications use UDP or 259 unreliable SCTP to deliver RTP or raw TS-formatted video. 261 Under congestion and loss, this approach generally experiences more 262 video artifacts with fewer delay or head of line blocking effects. 263 Often one of the key goals is to reduce latency, to better support 264 applications like video conferencing, or for other live-action video 265 with interactive components, such as some sporting events. 267 Congestion avoidance strategies for this kind of deployment vary 268 widely in practice, ranging from some streams that are entirely 269 unresponsive to using feedback signaling to change encoder settings 270 (as in [RFC5762]), or to use fewer enhancement layers (as in 271 [RFC6190]), to proprietary methods for detecting quality of 272 experience issues and cutting off video. 274 4. IANA Considerations 276 This document requires no actions from IANA. 278 5. Security Considerations 280 This document introduces no new security issues. 282 6. References 284 6.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 292 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 293 May 2017, . 295 6.2. Informative References 297 [CVNI] Cisco Systems, Inc., "Cisco Visual Networking Index: 298 Forecast and Trends, 2017-2022 White Paper", February 299 2019, . 303 [DASH] "Information technology -- Dynamic adaptive streaming over 304 HTTP (DASH) -- Part 1: Media presentation description and 305 segment formats", ISO/IEC 23009-1:2014, n.d.. 307 [I-D.han-iccrg-arvr-transport-problem] 308 Han, L. and K. Smith, "Problem Statement: Transport 309 Support for Augmented and Virtual Reality Applications", 310 draft-han-iccrg-arvr-transport-problem-01 (work in 311 progress), March 2017. 313 [MSOD] Akamai Technologies, Inc., "Media Services On Demand: 314 Encoder Best Practices", n.d., . 319 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 320 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 321 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 322 S., Wroclawski, J., and L. Zhang, "Recommendations on 323 Queue Management and Congestion Avoidance in the 324 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 325 . 327 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 328 of Explicit Congestion Notification (ECN) to IP", 329 RFC 3168, DOI 10.17487/RFC3168, September 2001, 330 . 332 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 333 Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 334 2010, . 336 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 337 "RTP Payload Format for Scalable Video Coding", RFC 6190, 338 DOI 10.17487/RFC6190, May 2011, 339 . 341 [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, 342 "Proportional Integral Controller Enhanced (PIE): A 343 Lightweight Control Scheme to Address the Bufferbloat 344 Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, 345 . 347 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 348 RFC 8216, DOI 10.17487/RFC8216, August 2017, 349 . 351 Author's Address 353 Jake Holland 354 Akamai Technologies, Inc. 355 150 Broadway 356 Cambridge, MA 02144 357 United States of America 359 Email: jakeholland.net@gmail.com