idnits 2.17.00 (12 Aug 2021) /tmp/idnits59188/draft-ietf-mops-streaming-opcons-08.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (11 January 2022) is 129 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-01 == Outdated reference: A later version (-11) exists of draft-pantos-hls-rfc8216bis-10 == Outdated reference: draft-ietf-quic-datagram has been published as RFC 9221 == Outdated reference: A later version (-16) exists of draft-ietf-quic-manageability-13 == Outdated reference: A later version (-01) exists of draft-ietf-quic-qlog-h3-events-00 == Outdated reference: A later version (-02) exists of draft-ietf-quic-qlog-main-schema-01 == Outdated reference: A later version (-01) exists of draft-ietf-quic-qlog-quic-events-00 == Outdated reference: draft-iab-covid19-workshop has been published as RFC 9075 -- Obsolete informational reference (is this intentional?): RFC 2001 (Obsoleted by RFC 2581) Summary: 0 errors (**), 0 flaws (~~), 9 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 A. Begen 5 Expires: 15 July 2022 Networked Media 6 S. Dawkins 7 Tencent America LLC 8 11 January 2022 10 Operational Considerations for Streaming Media 11 draft-ietf-mops-streaming-opcons-08 13 Abstract 15 This document provides an overview of operational networking issues 16 that pertain to quality of experience when streaming 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 15 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 4 54 1.1.1. Venues for Contribution and Discussion . . . . . . . 5 55 2. Our Focus on Streaming Video . . . . . . . . . . . . . . . . 5 56 3. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6 57 3.1. Scaling Requirements for Media Delivery . . . . . . . . . 6 58 3.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6 59 3.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 7 60 3.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7 61 3.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8 62 3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 10 64 3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11 65 3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11 66 3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12 67 4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14 68 4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14 69 4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15 70 4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16 71 4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5. Adaptive Encoding, Adaptive Delivery, and Measurement 73 Collection . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18 76 5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18 77 5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18 78 5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20 79 5.5.1. Idle Time between Segments . . . . . . . . . . . . . 20 80 5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21 81 5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22 82 5.6. Measurement Collection . . . . . . . . . . . . . . . . . 22 83 5.6.1. CTA-2066: Streaming Quality of Experience Events, 84 Properties and Metrics . . . . . . . . . . . . . . . 22 85 5.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23 86 5.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 23 87 6. Evolution of Transport Protocols and Transport Protocol 88 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24 89 6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24 90 6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25 91 6.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 26 92 7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28 93 7.1. General Considerations for Media Encryption . . . . . . . 29 94 7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30 95 7.3. Considerations for "End-to-End" Media Encryption . . . . 31 96 8. Further Reading and References . . . . . . . . . . . . . . . 32 97 8.1. Industry Terminology . . . . . . . . . . . . . . . . . . 32 98 8.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 32 99 8.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 32 100 8.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33 101 8.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 33 102 8.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 33 103 8.2.5. Low-Latency Live Adaptive Streaming . . . . . . . . . 34 104 8.2.6. Server/Client/Network Collaboration . . . . . . . . . 34 105 8.2.7. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35 106 8.2.8. Point Clouds and Immersive Media . . . . . . . . . . 35 107 8.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36 108 8.4. Technical Events . . . . . . . . . . . . . . . . . . . . 36 109 8.5. List of Organizations Working on Streaming Media . . . . 37 110 8.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38 111 8.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38 112 8.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 38 113 8.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 39 114 8.6.4. Synchronized Encoding and Packaging . . . . . . . . . 39 115 8.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 39 116 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 117 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 118 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 119 12. Informative References . . . . . . . . . . . . . . . . . . . 40 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 122 1. Introduction 124 This document examines networking issues as they relate to quality of 125 experience in Internet media delivery, especially focusing on 126 capturing characteristics of streaming video delivery that have 127 surprised network designers or transport experts who lack specific 128 video expertise, since streaming media highlights key differences 129 between common assumptions in existing networking practices and 130 observations of video delivery issues encountered when streaming 131 media over those existing networks. 133 This document specifically focuses on streaming applications and 134 defines streaming as follows: 136 * Streaming is transmission of a continuous media from a server to a 137 client and its simultaneous consumption by the client. 139 * Here, "continuous media" refers to media and associated streams 140 such as video, audio, metadata, etc. In this definition, the 141 critical term is "simultaneous", as it is not considered streaming 142 if one downloads a video file and plays it after the download is 143 completed, which would be called download-and-play. 145 This has two implications. 147 * First, the server's transmission rate must (loosely or tightly) 148 match to client's consumption rate in order to provide 149 uninterrupted playback. That is, the client must not run out of 150 data (buffer underrun) or accept more data than it can buffer 151 before playback (buffer overrun) as any excess media that cannot 152 be buffered is simply discarded. 154 * Second, the client's consumption rate is limited not only by 155 bandwidth availability,but also media availability. The client 156 cannot fetch media that is not available from a server yet. 158 This document contains 160 * A short description of streaming video characteristics in 161 Section 2, to set the stage for the rest of the document, 163 * General guidance on bandwidth provisioning (Section 3) and latency 164 considerations (Section 4) for streaming video delivery, 166 * A description of adaptive encoding and adaptive delivery 167 techniques in common use for streaming video, along with a 168 description of the challenges media senders face in detecting the 169 bitrate available between the media sender and media receiver, and 170 collection of measurements by a third party for use in analytics 171 (Section 5), 173 * A description of existing transport protocols used for video 174 streaming, and the issues encountered when using those protocols, 175 along with a description of the QUIC transport protocol [RFC9000] 176 that we expect to be used for streaming media (Section 6), 178 * A description of implications when streaming encrypted media 179 (Section 7), and 181 * A number of useful pointers for further reading on this rapidly 182 changing subject (Section 8). 184 Making specific recommendations on operational practices aimed at 185 mitigating the issues described in this document is out of scope, 186 though some existing mitigations are mentioned in passing. The 187 intent is to provide a point of reference for future solution 188 proposals to use in describing how new technologies address or avoid 189 existing observed problems. 191 1.1. Notes for Contributors and Reviewers 193 Note to RFC Editor: Please remove this section and its subsections 194 before publication. 196 This section is to provide references to make it easier to review the 197 development and discussion on the draft so far. 199 1.1.1. Venues for Contribution and Discussion 201 This document is in the Github repository at: 203 https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons 204 (https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons) 206 Readers are welcome to open issues and send pull requests for this 207 document. 209 Substantial discussion of this document should take place on the MOPS 210 working group mailing list (mops@ietf.org). 212 * Join: https://www.ietf.org/mailman/listinfo/mops 213 (https://www.ietf.org/mailman/listinfo/mops) 215 * Search: https://mailarchive.ietf.org/arch/browse/mops/ 216 (https://mailarchive.ietf.org/arch/browse/mops/) 218 2. Our Focus on Streaming Video 220 As the internet has grown, an increasingly large share of the traffic 221 delivered to end users has become video. Estimates put the total 222 share of internet video traffic at 75% in 2019, expected to grow to 223 82% by 2022. This estimate projects the gross volume of video 224 traffic will more than double during this time, based on a compound 225 annual growth rate continuing at 34% (from Appendix D of [CVNI]). 227 A substantial part of this growth is due to increased use of 228 streaming video, although the amount of video traffic in real-time 229 communications (for example, online videoconferencing) has also grown 230 significantly. While both streaming video and videoconferencing have 231 real-time delivery and latency requirements, these requirements vary 232 from one application to another. For example, videoconferencing 233 demands an end-to-end (one-way) latency of a few hundreds of 234 milliseconds whereas live streaming can tolerate latencies of several 235 seconds. 237 In many contexts, video traffic can be handled transparently as 238 generic application-level traffic. However, as the volume of video 239 traffic continues to grow, it's becoming increasingly important to 240 consider the effects of network design decisions on application-level 241 performance, with considerations for the impact on video delivery. 243 Much of the focus of this document is on reliable media using HTTP 244 over TCP. which is widely used because support for HTTP is widely 245 available in a wide range of operating systems, is also used in a 246 wide variety of other applications, has been demonstrated to provide 247 acceptable performance over the open Internet, includes state of the 248 art standardized security mechanisms, and can make use of already- 249 deployed caching infrastructure. 251 Some mentions of unreliable media delivery using RTP and other UDP- 252 based protocols appear in Section 4.1, Section 5.7, Section 6.1, and 253 Section 7.2, but it's difficult to give general guidance for these 254 applications. For instance, when loss occurs, the most appropriate 255 response may depend on the type of codec being used. 257 3. Bandwidth Provisioning 259 3.1. Scaling Requirements for Media Delivery 261 3.1.1. Video Bitrates 263 Video bitrate selection depends on many variables including the 264 resolution (height and width), frame rate, color depth, codec, 265 encoding parameters, scene complexity and amount of motion. 266 Generally speaking, as the resolution, frame rate, color depth, scene 267 complexity and amount of motion increase, the encoding bitrate 268 increases. As newer codecs with better compression tools are used, 269 the encoding bitrate decreases. Similarly, a multi-pass encoding 270 generally produces better quality output compared to single-pass 271 encoding at the same bitrate, or delivers the same quality at a lower 272 bitrate. 274 Here are a few common resolutions used for video content, with 275 typical ranges of bitrates for the two most popular video codecs 276 [Encodings]. 278 +============+================+============+============+ 279 | Name | Width x Height | H.264 | H.265 | 280 +============+================+============+============+ 281 | DVD | 720 x 480 | 1.0 Mbps | 0.5 Mbps | 282 +------------+----------------+------------+------------+ 283 | 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps | 284 +------------+----------------+------------+------------+ 285 | 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps | 286 +------------+----------------+------------+------------+ 287 | 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps | 288 +------------+----------------+------------+------------+ 290 Table 1 292 3.1.2. Virtual Reality Bitrates 294 The bitrates given in Section 3.1.1 describe video streams that 295 provide the user with a single, fixed, point of view - so, the user 296 has no "degrees of freedom", and the user sees all of the video image 297 that is available. 299 Even basic virtual reality (360-degree) videos that allow users to 300 look around freely (referred to as "three degrees of freedom", or 301 3DoF) require substantially larger bitrates when they are captured 302 and encoded as such videos require multiple fields of view of the 303 scene. Yet, due to smart delivery methods such as viewport-based or 304 tiled-based streaming, we do not need to send the whole scene to the 305 user. Instead, the user needs only the portion corresponding to its 306 viewpoint at any given time ([Survey360o]). 308 In more immersive applications, where limited user movement ("three 309 degrees of freedom plus", or 3DoF+) or full user movement ("six 310 degrees of freedom", or 6DoF) is allowed, the required bitrate grows 311 even further. In this case, immersive content is typically referred 312 to as volumetric media. One way to represent the volumetric media is 313 to use point clouds, where streaming a single object may easily 314 require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC] 315 for more details. 317 3.2. Path Bandwidth Constraints 319 Even when the bandwidth requirements for video streams along a path 320 are well understood, additional analysis is required to understand 321 the contraints on bandwidth at various points in the network. This 322 analysis is necessary because media servers may react to bandwith 323 constraints using two independent feedback loops: 325 * Media servers often respond to application-level feedback from the 326 media player that indicates a bottleneck link somewhere along the 327 path, by adjusting the amount of media that the media server will 328 send to the media player in a given timeframe. This is described 329 in greater detail in Section 5. 331 * Media servers also typically implement transport protocols with 332 capacity-seeking congestion controllers that probe for bandwidth, 333 and adjust the sending rate based on transport mechanisms. This 334 is described in greater detail in Section 6. 336 The result is that these two (potentially competing) "helpful" 337 mechanisms each respond to the same bottleneck with no coordination 338 between themselves, so that each is unaware of actions taken by the 339 other, and this can result in a quality of experience for users that 340 is significantly lower than what could have been achieved. 342 In one example, if a media server overestimates the available 343 bandwidth to the media player, 345 * the transport protocol detects loss due to congestion, and reduces 346 its sending window size per round trip, 348 * the media server adapts to application-level feedback from the 349 media player, and reduces its own sending rate, 351 * the transport protocol sends media at the new, lower rate, and 352 confirms that this new, lower rate is "safe", because no 353 transport-level loss is occuring, but 355 * because the media server continues to send at the new, lower rate, 356 the transport protocol's maximum sending rate is now limited by 357 the amount of information the media server queues for 358 transmission, so 360 * the transport protocol can't probe for available path bandwidth by 361 sending at a higher rate. 363 In order to avoid these types of situations, which can potentially 364 affect all the users whose streaming media traverses a bottleneck 365 link, there are several possible mitigations that streaming operators 366 can use, but the first step toward mitigating a problem is knowing 367 when that problem occurs. 369 3.2.1. Know Your Network Traffic 371 There are many reasons why path characteristics might change 372 suddenly, for example, 374 * "cross traffic" that traverses part of the path, especially if 375 this traffic is "inelastic", and does not, itself, respond to 376 indications of path congestion. 378 * routing changes, which can happen in normal operation, especially 379 if the new path now includes path segments that are more heavily 380 loaded, offer lower total bandwidth, or simply cover more 381 distance. 383 Recognizing that a path carrying streaming media is "not behaving the 384 way it normally does" is fundamental. Analytics that aid in that 385 recognition can be more or less sophisticated, and can be as simple 386 as noticing that the apparent round trip times for media traffic 387 carried over TCP transport on some paths are suddenly and 388 significantly longer than usual. Passive monitors can detect changes 389 in the elapsed time between the acknowledgements for specific TCP 390 segments from a TCP receiver, since TCP octet sequence numbers and 391 acknowledgements for those sequence numbers are "carried in the 392 clear", even if the TCP payload itself is encrypted. See Section 6.2 393 for more information. 395 As transport protocols evolve to encrypt their transport header 396 fields, one side effect of increasing encryption is that the kind of 397 passive monitoring, or even "performance enhancement" ([RFC3135]) 398 that was possible with the older transport protocols (UDP, described 399 in Section 6.1 and TCP, described in Section 6.2) is no longer 400 possible with newer transport protocols such as QUIC (described in 401 Section 6.3). The IETF has specified a "latency spin bit" mechanism 402 in Section 17.4 of [RFC9000] to allow passive latency monitoring from 403 observation points on the network path throughout the duration of a 404 connection, but currently chartered work in the IETF is focusing on 405 end-point monitoring and reporting, rather than on passive 406 monitoring. 408 One example is the "qlog" mechanism [I-D.ietf-quic-qlog-main-schema], 409 a protocol-agnostic mechanism used to provide better visibility for 410 encrypted protocols such as QUIC ([I-D.ietf-quic-qlog-quic-events]) 411 and for HTTP/3 ([I-D.ietf-quic-qlog-h3-events]). 413 3.3. Path Requirements 415 The bitrate requirements in Section 3.1 are per end-user actively 416 consuming a media feed, so in the worst case, the bitrate demands can 417 be multiplied by the number of simultaneous users to find the 418 bandwidth requirements for a router on the delivery path with that 419 number of users downstream. For example, at a node with 10,000 420 downstream users simultaneously consuming video streams, 421 approximately 80 Gbps might be necessary in order for all of them to 422 get typical content at 1080p resolution. 424 However, when there is some overlap in the feeds being consumed by 425 end users, it is sometimes possible to reduce the bandwidth 426 provisioning requirements for the network by performing some kind of 427 replication within the network. This can be achieved via object 428 caching with delivery of replicated objects over individual 429 connections, and/or by packet-level replication using multicast. 431 To the extent that replication of popular content can be performed, 432 bandwidth requirements at peering or ingest points can be reduced to 433 as low as a per-feed requirement instead of a per-user requirement. 435 3.4. Caching Systems 437 When demand for content is relatively predictable, and especially 438 when that content is relatively static, caching content close to 439 requesters, and pre-loading caches to respond quickly to initial 440 requests is often useful (for example, HTTP/1.1 caching is described 441 in [I-D.ietf-httpbis-cache]). This is subject to the usual 442 considerations for caching - for example, how much data must be 443 cached to make a significant difference to the requester, and how the 444 benefits of caching and pre-loading caches balances against the costs 445 of tracking "stale" content in caches and refreshing that content. 447 It is worth noting that not all high-demand content is "live" 448 content. One popular example is when popular streaming content can 449 be staged close to a significant number of requesters, as can happen 450 when a new episode of a popular show is released. This content may 451 be largely stable, so low-cost to maintain in multiple places 452 throughout the Internet. This can reduce demands for high end-to-end 453 bandwidth without having to use mechanisms like multicast. 455 Caching and pre-loading can also reduce exposure to peering point 456 congestion, since less traffic crosses the peering point exchanges if 457 the caches are placed in peer networks, especially when the content 458 can be pre-loaded during off-peak hours, and especially if the 459 transfer can make use of "Lower-Effort Per-Hop Behavior (LE PHB) for 460 Differentiated Services" [RFC8622], "Low Extra Delay Background 461 Transport (LEDBAT)" [RFC6817], or similar mechanisms. 463 All of this depends, of course, on the ability of a content provider 464 to predict usage and provision bandwidth, caching, and other 465 mechanisms to meet the needs of users. In some cases (Section 3.5), 466 this is relatively routine, but in other cases, it is more difficult 467 (Section 3.6, Section 3.7). 469 And as with other parts of the ecosystem, new technology brings new 470 challenges. For example, with the emergence of ultra-low-latency 471 streaming, responses have to start streaming to the end user while 472 still being transmitted to the cache, and while the cache does not 473 yet know the size of the object. Some of the popular caching systems 474 were designed around cache footprint and had deeply ingrained 475 assumptions about knowing the size of objects that are being stored, 476 so the change in design requirements in long-established systems 477 caused some errors in production. Incidents occurred where a 478 transmission error in the connection from the upstream source to the 479 cache could result in the cache holding a truncated segment and 480 transmitting it to the end user's device. In this case, players 481 rendering the stream often had the video freeze until the player was 482 reset. In some cases the truncated object was even cached that way 483 and served later to other players as well, causing continued stalls 484 at the same spot in the video for all players playing the segment 485 delivered from that cache node. 487 3.5. Predictable Usage Profiles 489 Historical data shows that users consume more video and videos at 490 higher bitrates than they did in the past on their connected devices. 491 Improvements in the codecs that help with reducing the encoding 492 bitrates with better compression algorithms could not have offset the 493 increase in the demand for the higher quality video (higher 494 resolution, higher frame rate, better color gamut, better dynamic 495 range, etc.). In particular, mobile data usage has shown a large 496 jump over the years due to increased consumption of entertainment as 497 well as conversational video. 499 3.6. Unpredictable Usage Profiles 501 Although TCP/IP has been used with a number of widely used 502 applications that have symmetric bandwidth requirements (similar 503 bandwidth requirements in each direction between endpoints), many 504 widely-used Internet applications operate in client-server roles, 505 with asymmetric bandwidth requirements. A common example might be an 506 HTTP GET operation, where a client sends a relatively small HTTP GET 507 request for a resource to an HTTP server, and often receives a 508 significantly larger response carrying the requested resource. When 509 HTTP is commonly used to stream movie-length video, the ratio between 510 response size and request size can become arbitrarily large. 512 For this reason, operators may pay more attention to downstream 513 bandwidth utilization when planning and managing capacity. In 514 addition, operators have been able to deploy access networks for end 515 users using underlying technologies that are inherently asymmetric, 516 favoring downstream bandwidth (e.g. ADSL, cellular technologies, 517 most IEEE 802.11 variants), assuming that users will need less 518 upstream bandwidth than downstream bandwidth. This strategy usually 519 works, except when it fails because application bandwidth usage 520 patterns have changed in ways that were not predicted. 522 One example of this type of change was when peer-to-peer file sharing 523 applications gained popularity in the early 2000s. To take one well- 524 documented case ([RFC5594]), the Bittorrent application created 525 "swarms" of hosts, uploading and downloading files to each other, 526 rather than communicating with a server. Bittorrent favored peers 527 who uploaded as much as they downloaded, so that new Bittorrent users 528 had an incentive to significantly increase their upstream bandwidth 529 utilization. 531 The combination of the large volume of "torrents" and the peer-to- 532 peer characteristic of swarm transfers meant that end user hosts were 533 suddenly uploading higher volumes of traffic to more destinations 534 than was the case before Bittorrent. This caused at least one large 535 internet service provider (ISP) to attempt to "throttle" these 536 transfers, to mitigate the load that these hosts placed on their 537 network. These efforts were met by increased use of encryption in 538 Bittorrent, similar to an arms race, and set off discussions about 539 "Net Neutrality" and calls for regulatory action. 541 Especially as end users increase use of video-based social networking 542 applications, it will be helpful for access network providers to 543 watch for increasing numbers of end users uploading significant 544 amounts of content. 546 3.7. Extremely Unpredictable Usage Profiles 548 The causes of unpredictable usage described in Section 3.6 were more 549 or less the result of human choices, but we were reminded during a 550 post-IETF 107 meeting that humans are not always in control, and 551 forces of nature can cause enormous fluctuations in traffic patterns. 553 In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19 554 pandemic broke out in early 2020, 556 * Comcast's streaming and web video consumption rose by 38%, with 557 their reported peak traffic up 32% overall between March 1 to 558 March 30, 560 * AT&T reported a 28% jump in core network traffic (single day in 561 April, as compared to pre stay-at-home daily average traffic), 562 with video accounting for nearly half of all mobile network 563 traffic, while social networking and web browsing remained the 564 highest percentage (almost a quarter each) of overall mobility 565 traffic, and 567 * Verizon reported similar trends with video traffic up 36% over an 568 average day (pre COVID-19)}. 570 We note that other operators saw similar spikes during this time 571 period. Craig Labowitz [Labovitz] reported 573 * Weekday peak traffic increases over 45%-50% from pre-lockdown 574 levels, 576 * A 30% increase in upstream traffic over their pre-pandemic levels, 577 and 579 * A steady increase in the overall volume of DDoS traffic, with 580 amounts exceeding the pre-pandemic levels by 40%. (He attributed 581 this increase to the significant rise in gaming-related DDoS 582 attacks ([LabovitzDDoS]), as gaming usage also increased.) 584 Subsequently, the Internet Architecture Board (IAB) held a COVID-19 585 Network Impacts Workshop [IABcovid] in November 2020. Given a larger 586 number of reports and more time to reflect, the following 587 observations from the draft workshop report are worth considering. 589 * Participants describing different types of networks reported 590 different kinds of impacts, but all types of networks saw impacts. 592 * Mobile networks saw traffic reductions and residential networks 593 saw significant increases. 595 * Reported traffic increases from ISPs and internet exchange points 596 (IXP) over just a few weeks were as big as the traffic growth over 597 the course of a typical year, representing a 15-20% surge in 598 growth to land at a new normal that was much higher than 599 anticipated. 601 * At DE-CIX Frankfurt, the world's largest Internet Exchange Point 602 in terms of data throughput, the year 2020 has seen the largest 603 increase in peak traffic within a single year since the IXP was 604 founded in 1995. 606 * The usage pattern changed significantly as work-from-home and 607 videoconferencing usage peaked during normal work hours, which 608 would have typically been off-peak hours with adults at work and 609 children at school. One might expect that the peak would have had 610 more impact on networks if it had happened during typical evening 611 peak hours for video streaming applications. 613 * The increase in daytime bandwidth consumption reflected both 614 significant increases in "essential" applications such as 615 videoconferencing and virtual private networks (VPN), and 616 entertainment applications as people watched videos or played 617 games. 619 * At the IXP-level, it was observed that port utilization increased. 620 This phenomenon is mostly explained by a higher traffic demand 621 from residential users. 623 4. Latency Considerations 625 Streaming media latency refers to the "glass-to-glass" time duration, 626 which is the delay between the real-life occurrence of an event and 627 the streamed media being appropriately displayed on an end user's 628 device. Note that this is different from the network latency 629 (defined as the time for a packet to cross a network from one end to 630 another end) because it includes video encoding/decoding and 631 buffering time, and for most cases also ingest to an intermediate 632 service such as a CDN or other video distribution service, rather 633 than a direct connection to an end user. 635 Streaming media can be usefully categorized according to the 636 application's latency requirements into a few rough categories: 638 * ultra low-latency (less than 1 second) 640 * low-latency live (less than 10 seconds) 642 * non-low-latency live (10 seconds to a few minutes) 644 * on-demand (hours or more) 646 4.1. Ultra Low-Latency 648 Ultra low-latency delivery of media is defined here as having a 649 glass-to-glass delay target under one second. 651 Some media content providers aim to achieve this level of latency for 652 live media events. This introduces new challenges relative to less- 653 restricted levels of latency requirements because this latency is the 654 same scale as commonly observed end-to-end network latency variation 655 (for example, due to effects such as bufferbloat ([CoDel]), Wi-Fi 656 error correction, or packet reordering). These effects can make it 657 difficult to achieve this level of latency for the general case, and 658 may require tradeoffs in relatively frequent user-visible media 659 artifacts. However, for controlled environments or targeted networks 660 that provide mitigations against such effects, this level of latency 661 is potentially achievable with the right provisioning. 663 Applications requiring ultra low latency for media delivery are 664 usually tightly constrained on the available choices for media 665 transport technologies, and sometimes may need to operate in 666 controlled environments to reliably achieve their latency and quality 667 goals. 669 Most applications operating over IP networks and requiring latency 670 this low use the Real-time Transport Protocol (RTP) [RFC3550] or 671 WebRTC [RFC8825], which uses RTP for the media transport as well as 672 several other protocols necessary for safe operation in browsers. 674 Worth noting is that many applications for ultra low-latency delivery 675 do not need to scale to more than a few users at a time, which 676 simplifies many delivery considerations relative to other use cases. 678 Recommended reading for applications adopting an RTP-based approach 679 also includes [RFC7656]. For increasing the robustness of the 680 playback by implementing adaptive playout methods, refer to [RFC4733] 681 and [RFC6843]. 683 Applications with further-specialized latency requirements are out of 684 scope for this document. 686 4.2. Low-Latency Live 688 Low-latency live delivery of media is defined here as having a glass- 689 to-glass delay target under 10 seconds. 691 This level of latency is targeted to have a user experience similar 692 to traditional broadcast TV delivery. A frequently cited problem 693 with failing to achieve this level of latency for live sporting 694 events is the user experience failure from having crowds within 695 earshot of one another who react audibly to an important play, or 696 from users who learn of an event in the match via some other channel, 697 for example social media, before it has happened on the screen 698 showing the sporting event. 700 Applications requiring low-latency live media delivery are generally 701 feasible at scale with some restrictions. This typically requires 702 the use of a premium service dedicated to the delivery of live video, 703 and some tradeoffs may be necessary relative to what's feasible in a 704 higher latency service. The tradeoffs may include higher costs, or 705 delivering a lower quality video, or reduced flexibility for adaptive 706 bitrates, or reduced flexibility for available resolutions so that 707 fewer devices can receive an encoding tuned for their display. Low- 708 latency live delivery is also more susceptible to user-visible 709 disruptions due to transient network conditions than higher latency 710 services. 712 Implementation of a low-latency live video service can be achieved 713 with the use of low-latency extensions of HLS (called LL-HLS) 714 [I-D.draft-pantos-hls-rfc8216bis] and DASH (called LL-DASH) 715 [LL-DASH]. These extensions use the Common Media Application Format 716 (CMAF) standard [MPEG-CMAF] that allows the media to be packaged into 717 and transmitted in units smaller than segments, which are called 718 chunks in CMAF language. This way, the latency can be decoupled from 719 the duration of the media segments. Without a CMAF-like packaging, 720 lower latencies can only be achieved by using very short segment 721 durations. However, shorter segments means more frequent intra-coded 722 frames and that is detrimental to video encoding quality. CMAF 723 allows us to still use longer segments (improving encoding quality) 724 without penalizing latency. 726 While an LL-HLS client retrieves each chunk with a separate HTTP GET 727 request, an LL-DASH client uses the chunked transfer encoding feature 728 of the HTTP [CMAF-CTE] which allows the LL-DASH client to fetch all 729 the chunks belonging to a segment with a single GET request. An HTTP 730 server can transmit the CMAF chunks to the LL-DASH client as they 731 arrive from the encoder/packager. A detailed comparison of LL-HLS 732 and LL-DASH is given in [MMSP20]. 734 4.3. Non-Low-Latency Live 736 Non-low-latency live delivery of media is defined here as a live 737 stream that does not have a latency target shorter than 10 seconds. 739 This level of latency is the historically common case for segmented 740 video delivery using HLS [RFC8216] and DASH [MPEG-DASH]. This level 741 of latency is often considered adequate for content like news or pre- 742 recorded content. This level of latency is also sometimes achieved 743 as a fallback state when some part of the delivery system or the 744 client-side players do not have the necessary support for the 745 features necessary to support low-latency live streaming. 747 This level of latency can typically be achieved at scale with 748 commodity CDN services for HTTP(s) delivery, and in some cases the 749 increased time window can allow for production of a wider range of 750 encoding options relative to the requirements for a lower latency 751 service without the need for increasing the hardware footprint, which 752 can allow for wider device interoperability. 754 4.4. On-Demand 756 On-Demand media streaming refers to playback of pre-recorded media 757 based on a user's action. In some cases on-demand media is produced 758 as a by-product of a live media production, using the same segments 759 as the live event, but freezing the manifest after the live event has 760 finished. In other cases, on-demand media is constructed out of pre- 761 recorded assets with no streaming necessarily involved during the 762 production of the on-demand content. 764 On-demand media generally is not subject to latency concerns, but 765 other timing-related considerations can still be as important or even 766 more important to the user experience than the same considerations 767 with live events. These considerations include the startup time, the 768 stability of the media stream's playback quality, and avoidance of 769 stalls and video artifacts during the playback under all but the most 770 severe network conditions. 772 In some applications, optimizations are available to on-demand video 773 that are not always available to live events, such as pre-loading the 774 first segment for a startup time that doesn't have to wait for a 775 network download to begin. 777 5. Adaptive Encoding, Adaptive Delivery, and Measurement Collection 779 5.1. Overview 781 A simple model of video playback can be described as a video stream 782 consumer, a buffer, and a transport mechanism that fills the buffer. 783 The consumption rate is fairly static and is represented by the 784 content bitrate. The size of the buffer is also commonly a fixed 785 size. The fill process needs to be at least fast enough to ensure 786 that the buffer is never empty, however it also can have significant 787 complexity when things like personalization or ad workflows are 788 introduced. 790 The challenges in filling the buffer in a timely way fall into two 791 broad categories: 1. content selection and 2. content variation. 792 Content selection comprises all of the steps needed to determine 793 which content variation to offer the client. Content variation is 794 the number of content options that exist at any given selection 795 point. A common example, easily visualized, is Adaptive BitRate 796 (ABR), described in more detail below. The mechanism used to select 797 the bitrate is part of the content selection, and the content 798 variation are all of the different bitrate renditions. 800 ABR is a sort of application-level response strategy in which the 801 streaming client attempts to detect the available bandwidth of the 802 network path by observing the successful application-layer download 803 speed, then chooses a bitrate for each of the video, audio, subtitles 804 and metadata (among the limited number of available options) that 805 fits within that bandwidth, typically adjusting as changes in 806 available bandwidth occur in the network or changes in capabilities 807 occur during the playback (such as available memory, CPU, display 808 size, etc.). 810 5.2. Adaptive Encoding 812 Media servers can provide media streams at various bitrates because 813 the media has been encoded at various bitrates. This is a so-called 814 "ladder" of bitrates, that can be offered to media players as part of 815 the manifest that describes the media being requested by the media 816 player, so that the media player can select among the available 817 bitrate choices. 819 The media server may also choose to alter which bitrates are made 820 available to players by adding or removing bitrate options from the 821 ladder delivered to the player in subsequent manifests built and sent 822 to the player. This way, both the player, through its selection of 823 bitrate to request from the manifest, and the server, through its 824 construction of the bitrates offered in the manifest, are able to 825 affect network utilization. 827 5.3. Adaptive Segmented Delivery 829 ABR playback is commonly implemented by streaming clients using HLS 830 [RFC8216] or DASH [MPEG-DASH] to perform a reliable segmented 831 delivery of media over HTTP. Different implementations use different 832 strategies [ABRSurvey], often relying on proprietary algorithms 833 (called rate adaptation or bitrate selection algorithms) to perform 834 available bandwidth estimation/prediction and the bitrate selection. 836 Many server-player systems will do an initial probe or a very simple 837 throughput speed test at the start of a video playback. This is done 838 to get a rough sense of the highest video bitrate in the ABR ladder 839 that the network between the server and player will likely be able to 840 provide under initial network conditions. After the initial testing, 841 clients tend to rely upon passive network observations and will make 842 use of player side statistics such as buffer fill rates to monitor 843 and respond to changing network conditions. 845 The choice of bitrate occurs within the context of optimizing for 846 some metric monitored by the client, such as highest achievable video 847 quality or lowest chances for a rebuffering event (playback stall). 849 5.4. Advertising 851 A variety of business models exist for producers of streaming media. 852 Some content providers derive the majority of the revenue associated 853 with streaming media directly from consumer subscriptions or one-time 854 purchases. Others derive the majority of their streaming media 855 associated revenue from advertising. Many content providers derive 856 income from a mix of these and other sources of funding. The 857 inclusion of advertising alongside or interspersed with streaming 858 media content is therefore common in today's media landscape. 860 Some commonly used forms of advertising can introduce potential user 861 experience issues for a media stream. This section provides a very 862 brief overview of a complex and evolving space, but a complete 863 coverage of the potential issues is out of scope for this document. 865 The same techniques used to allow a media player to switch between 866 renditions of different bitrates at segment or chunk boundaries can 867 also be used to enable the dynamic insertion of advertisements. 869 Ads may be inserted either with Client Side Ad Insertion (CSAI) or 870 Server Side Ad Insertion (SSAI). In CSAI, the ABR manifest will 871 generally include links to an external ad server for some segments of 872 the media stream, while in SSAI the server will remain the same 873 during advertisements, but will include media segments that contain 874 the advertising. In SSAI, the media segments may or may not be 875 sourced from an external ad server like with CSAI. 877 In general, the more targeted the ad request is, the more requests 878 the ad service needs to be able to handle concurrently. If 879 connectivity is poor to the ad service, this can cause rebuffering 880 even if the underlying video assets (both content and ads) are able 881 to be accessed quickly. The less targeted, the more likely the ad 882 requests can be consolidated and can leverage the same caching 883 techniques as the video content. 885 In some cases, especially with SSAI, advertising space in a stream is 886 reserved for a specific advertiser and can be integrated with the 887 video so that the segments share the same encoding properties such as 888 bitrate, dynamic range, and resolution. However, in many cases ad 889 servers integrate with a Supply Side Platform (SSP) that offers 890 advertising space in real-time auctions via an Ad Exchange, with bids 891 for the advertising space coming from Demand Side Platforms (DSPs) 892 that collect money from advertisers for delivering the 893 advertisements. Most such Ad Exchanges use application-level 894 protocol specifications published by the Interactive Advertising 895 Bureau [IAB-ADS], an industry trade organization. 897 This ecosystem balances several competing objectives, and integrating 898 with it naively can produce surprising user experience results. For 899 example, ad server provisioning and/or the bitrate of the ad segments 900 might be different from that of the main video, either of which can 901 sometimes result in video stalls. For another example, since the 902 inserted ads are often produced independently they might have a 903 different base volume level than the main video, which can make for a 904 jarring user experience. 906 Additionally, this market historically has had incidents of ad fraud 907 (misreporting of ad delivery to end users for financial gain). As a 908 mitigation for concerns driven by those incidents, some SSPs have 909 required the use of players with features like reporting of ad 910 delivery, or providing information that can be used for user 911 tracking. Some of these and other measures have raised privacy 912 concerns for end users. 914 In general this is a rapidly developing space with many 915 considerations, and media streaming operators engaged in advertising 916 may need to research these and other concerns to find solutions that 917 meet their user experience, user privacy, and financial goals. For 918 further reading on mitigations, [BAP] has published some standards 919 and best practices based on user experience research. 921 5.5. Bitrate Detection Challenges 923 This kind of bandwidth-measurement system can experience trouble in 924 several ways that are affected by networking issues. Because 925 adaptive application-level response strategies are often using rates 926 as observed by the application layer, there are sometimes inscrutable 927 transport-level protocol behaviors that can produce surprising 928 measurement values when the application-level feedback loop is 929 interacting with a transport-level feedback loop. 931 A few specific examples of surprising phenomena that affect bitrate 932 detection measurements are described in the following subsections. 933 As these examples will demonstrate, it's common to encounter cases 934 that can deliver application level measurements that are too low, too 935 high, and (possibly) correct but varying more quickly than a lab- 936 tested selection algorithm might expect. 938 These effects and others that cause transport behavior to diverge 939 from lab modeling can sometimes have a significant impact on bitrate 940 selection and on user quality of experience, especially where players 941 use naive measurement strategies and selection algorithms that don't 942 account for the likelihood of bandwidth measurements that diverge 943 from the true path capacity. 945 5.5.1. Idle Time between Segments 947 When the bitrate selection is chosen substantially below the 948 available capacity of the network path, the response to a segment 949 request will typically complete in much less absolute time than the 950 duration of the requested segment, leaving significant idle time 951 between segment downloads. This can have a few surprising 952 consequences: 954 * TCP slow-start when restarting after idle requires multiple RTTs 955 to re-establish a throughput at the network's available capacity. 956 When the active transmission time for segments is substantially 957 shorter than the time between segments, leaving an idle gap 958 between segments that triggers a restart of TCP slow-start, the 959 estimate of the successful download speed coming from the 960 application-visible receive rate on the socket can thus end up 961 much lower than the actual available network capacity. This in 962 turn can prevent a shift to the most appropriate bitrate. 963 [RFC7661] provides some mitigations for this effect at the TCP 964 transport layer, for senders who anticipate a high incidence of 965 this problem. 967 * Mobile flow-bandwidth spectrum and timing mapping can be impacted 968 by idle time in some networks. The carrier capacity assigned to a 969 link can vary with activity. Depending on the idle time 970 characteristics, this can result in a lower available bitrate than 971 would be achievable with a steadier transmission in the same 972 network. 974 Some receiver-side ABR algorithms such as [ELASTIC] are designed to 975 try to avoid this effect. 977 Another way to mitigate this effect is by the help of two 978 simultaneous TCP connections, as explained in [MMSys11] for Microsoft 979 Smooth Streaming. In some cases, the system-level TCP slow-start 980 restart can also be disabled, for example as described in 981 [OReilly-HPBN]. 983 5.5.2. Head-of-Line Blocking 985 In the event of a lost packet on a TCP connection with SACK support 986 (a common case for segmented delivery in practice), loss of a packet 987 can provide a confusing bandwidth signal to the receiving 988 application. Because of the sliding window in TCP, many packets may 989 be accepted by the receiver without being available to the 990 application until the missing packet arrives. Upon arrival of the 991 one missing packet after retransmit, the receiver will suddenly get 992 access to a lot of data at the same time. 994 To a receiver measuring bytes received per unit time at the 995 application layer, and interpreting it as an estimate of the 996 available network bandwidth, this appears as a high jitter in the 997 goodput measurement, presenting as a stall, followed by a sudden leap 998 that can far exceed the actual capacity of the transport path from 999 the server when the hole in the received data is filled by a later 1000 retransmission. 1002 It's worth noting that more modern transport protocols such as QUIC 1003 have mitigation of head-of-line blocking as a protocol design goal. 1004 See Section 6.3 for more details. 1006 5.5.3. Wide and Rapid Variation in Path Capacity 1008 As many end devices have moved to wireless connectivity for the final 1009 hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have 1010 emerged from radio interference and signal strength effects. 1012 Each of these technologies can experience sudden changes in capacity 1013 as the end user device moves from place to place and encounters new 1014 sources of interference. Microwave ovens, for example, can cause a 1015 throughput degradation of more than a factor of 2 while active 1016 [Micro]. 5G and LTE likewise can easily see rate variation by a 1017 factor of 2 or more over a span of seconds as users move around. 1019 These swings in actual transport capacity can result in user 1020 experience issues that can be exacerbated by insufficiently 1021 responsive ABR algorithms. 1023 5.6. Measurement Collection 1025 In addition to measurements media players use to guide their segment- 1026 by-segment adaptive streaming requests, streaming media providers may 1027 also rely on measurements collected from media players to provide 1028 analytics that can be used for decisions such as whether the adaptive 1029 encoding bitrates in use are the best ones to provide to media 1030 players, or whether current media content caching is providing the 1031 best experience for viewers. To that effect, the Consumer Technology 1032 Association (CTA) who owns the Web Application Video Ecosystem (WAVE) 1033 project has published two important specifications. 1035 5.6.1. CTA-2066: Streaming Quality of Experience Events, Properties and 1036 Metrics 1038 [CTA-2066] specifies a set of media player events, properties, 1039 quality of experience (QoE) metrics and associated terminology for 1040 representing streaming media quality of experience across systems, 1041 media players and analytics vendors. While all these events, 1042 properties, metrics and associated terminology is used across a 1043 number of proprietary analytics and measurement solutions, they were 1044 used in slightly (or vastly) different ways that led to 1045 interoperability issues. CTA-2066 attempts to address this issue by 1046 defining a common terminology as well as how each metric should be 1047 computed for consistent reporting. 1049 5.6.2. CTA-5004: Common Media Client Data (CMCD) 1051 Many assume that the CDNs have a holistic view into the health and 1052 performance of the streaming clients. However, this is not the case. 1053 The CDNs produce millions of log lines per second across hundreds of 1054 thousands of clients and they have no concept of a "session" as a 1055 client would have, so CDNs are decoupled from the metrics the clients 1056 generate and report. A CDN cannot tell which request belongs to 1057 which playback session, the duration of any media object, the 1058 bitrate, or whether any of the clients have stalled and are 1059 rebuffering or are about to stall and will rebuffer. The consequence 1060 of this decoupling is that a CDN cannot prioritize delivery for when 1061 the client needs it most, prefetch content, or trigger alerts when 1062 the network itself may be underperforming. One approach to couple 1063 the CDN to the playback sessions is for the clients to communicate 1064 standardized media-relevant information to the CDNs while they are 1065 fetching data. [CTA-5004] was developed exactly for this purpose. 1067 5.7. Unreliable Transport 1069 In contrast to segmented delivery, several applications use 1070 unreliable UDP or SCTP with its "partial reliability" extension 1071 [RFC3758] to deliver Media encapsulated in RTP [RFC3550] or raw MPEG 1072 Transport Stream ("MPEG-TS")-formatted video [MPEG-TS], when the 1073 media is being delivered in situations such as broadcast and live 1074 streaming, that better tolerate occasional packet loss without 1075 retransmission. 1077 Under congestion and loss, this approach generally experiences more 1078 video artifacts with fewer delay or head-of-line blocking effects. 1079 Often one of the key goals is to reduce latency, to better support 1080 applications like videoconferencing, or for other live-action video 1081 with interactive components, such as some sporting events. 1083 The Secure Reliable Transport protocol [SRT] also uses UDP in an 1084 effort to achieve lower latency for streaming media, although it adds 1085 reliability at the application layer. 1087 Congestion avoidance strategies for deployments using unreliable 1088 transport protocols vary widely in practice, ranging from being 1089 entirely unresponsive to congestion, to using feedback signaling to 1090 change encoder settings (as in [RFC5762]), to using fewer enhancement 1091 layers (as in [RFC6190]), to using proprietary methods to detect 1092 "quality of experience" issues and turn off video in order to allow 1093 less bandwidth-intensive media such as audio to be delivered. 1095 More details about congestion avoidance strategies used with 1096 unreliable transport protocols are included in Section 6.1. 1098 6. Evolution of Transport Protocols and Transport Protocol Behaviors 1100 Because networking resources are shared between users, a good place 1101 to start our discussion is how contention between users, and 1102 mechanisms to resolve that contention in ways that are "fair" between 1103 users, impact streaming media users. These topics are closely tied 1104 to transport protocol behaviors. 1106 As noted in Section 5, ABR response strategies such as HLS [RFC8216] 1107 or DASH [MPEG-DASH] are attempting to respond to changing path 1108 characteristics, and underlying transport protocols are also 1109 attempting to respond to changing path characteristics. 1111 For most of the history of the Internet, these transport protocols, 1112 described in Section 6.1 and Section 6.2, have had relatively 1113 consistent behaviors that have changed slowly, if at all, over time. 1114 Newly standardized transport protocols like QUIC [RFC9000] can behave 1115 differently from existing transport protocols, and these behaviors 1116 may evolve over time more rapidly than currently-used transport 1117 protocols. 1119 For this reason, we have included a description of how the path 1120 characteristics that streaming media providers may see are likely to 1121 evolve over time. 1123 6.1. UDP and Its Behavior 1125 For most of the history of the Internet, we have trusted UDP-based 1126 applications to limit their impact on other users. One of the 1127 strategies used was to use UDP for simple query-response application 1128 protocols, such as DNS, which is often used to send a single-packet 1129 request to look up the IP address for a DNS name, and return a 1130 single-packet response containing the IP address. Although it is 1131 possible to saturate a path between a DNS client and DNS server with 1132 DNS requests, in practice, that was rare enough that DNS included few 1133 mechanisms to resolve contention between DNS users and other users 1134 (whether they are also using DNS, or using other application 1135 protocols). 1137 In recent times, the usage of UDP-based applications that were not 1138 simple query-response protocols has grown substantially, and since 1139 UDP does not provide any feedback mechanism to senders to help limit 1140 impacts on other users, application-level protocols such as RTP 1141 [RFC3550] have been responsible for the decisions that TCP-based 1142 applications have delegated to TCP - what to send, how much to send, 1143 and when to send it. So, the way some UDP-based applications 1144 interact with other users has changed. 1146 It's also worth pointing out that because UDP has no transport-layer 1147 feedback mechanisms, UDP-based applications that send and receive 1148 substantial amounts of information are expected to provide their own 1149 feedback mechanisms. This expectation is most recently codified in 1150 Best Current Practice [RFC8085]. 1152 RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own 1153 feedback mechanism, and even includes Circuit Breakers for Unicast 1154 RTP Sessions [RFC8083] for situations when normal RTP congestion 1155 control has not been able to react sufficiently to RTP flows sending 1156 at rates that result in sustained packet loss. 1158 The notion of "Circuit Breakers" has also been applied to other UDP 1159 applications in [RFC8084], such as tunneling packets over UDP that 1160 are potentially not congestion-controlled (for example, 1161 "Encapsulating MPLS in UDP", as described in [RFC7510]). If 1162 streaming media is carried in tunnels encapsulated in UDP, these 1163 media streams may encounter "tripped circuit breakers", with 1164 resulting user-visible impacts. 1166 6.2. TCP and Its Behavior 1168 For most of the history of the Internet, we have trusted TCP to limit 1169 the impact of applications that sent a significant number of packets, 1170 in either or both directions, on other users. Although early 1171 versions of TCP were not particularly good at limiting this impact 1172 [RFC0793], the addition of Slow Start and Congestion Avoidance, as 1173 described in [RFC2001], were critical in allowing TCP-based 1174 applications to "use as much bandwidth as possible, but to avoid 1175 using more bandwidth than was possible". Although dozens of RFCs 1176 have been written refining TCP decisions about what to send, how much 1177 to send, and when to send it, since 1988 [Jacobson-Karels] the 1178 signals available for TCP senders remained unchanged - end-to-end 1179 acknowledgements for packets that were successfully sent and 1180 received, and packet timeouts for packets that were not. 1182 The success of the largely TCP-based Internet is evidence that the 1183 mechanisms TCP used to achieve equilibrium quickly, at a point where 1184 TCP senders do not interfere with other TCP senders for sustained 1185 periods of time, have been largely successful. The Internet 1186 continued to work even when the specific mechanisms used to reach 1187 equilibrium changed over time. Because TCP provides a common tool to 1188 avoid contention, as some TCP-based applications like FTP were 1189 largely replaced by other TCP-based applications like HTTP, the 1190 transport behavior remained consistent. 1192 In recent times, the TCP goal of probing for available bandwidth, and 1193 "backing off" when a network path is saturated, has been supplanted 1194 by the goal of avoiding growing queues along network paths, which 1195 prevent TCP senders from reacting quickly when a network path is 1196 saturated. Congestion control mechanisms such as COPA [COPA18] and 1197 BBR [I-D.cardwell-iccrg-bbr-congestion-control] make these decisions 1198 based on measured path delays, assuming that if the measured path 1199 delay is increasing, the sender is injecting packets onto the network 1200 path faster than the receiver can accept them, so the sender should 1201 adjust its sending rate accordingly. 1203 Although TCP behavior has changed over time, the common practice of 1204 implementing TCP as part of an operating system kernel has acted to 1205 limit how quickly TCP behavior can change. Even with the widespread 1206 use of automated operating system update installation on many end- 1207 user systems, streaming media providers could have a reasonable 1208 expectation that they could understand TCP transport protocol 1209 behaviors, and that those behaviors would remain relatively stable in 1210 the short term. 1212 6.3. The QUIC Protocol and Its Behavior 1214 The QUIC protocol, developed from a proprietary protocol into an IETF 1215 standards-track protocol [RFC9000], turns many of the statements made 1216 in Section 6.1 and Section 6.2 on their heads. 1218 Although QUIC provides an alternative to the TCP and UDP transport 1219 protocols, QUIC is itself encapsulated in UDP. As noted elsewhere in 1220 Section 7.1, the QUIC protocol encrypts almost all of its transport 1221 parameters, and all of its payload, so any intermediaries that 1222 network operators may be using to troubleshoot HTTP streaming media 1223 performance issues, perform analytics, or even intercept exchanges in 1224 current applications will not work for QUIC-based applications 1225 without making changes to their networks. Section 7 describes the 1226 implications of media encryption in more detail. 1228 While QUIC is designed as a general-purpose transport protocol, and 1229 can carry different application-layer protocols, the current 1230 standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which 1231 describes how QUIC transport features are used for HTTP. The 1232 convention is for HTTP/3 to run over UDP port 443 [Port443] but this 1233 is not a strict requirement. 1235 When HTTP/3 is encapsulated in QUIC, which is then encapsulated in 1236 UDP, streaming operators (and network operators) might see UDP 1237 traffic patterns that are similar to HTTP(S) over TCP. Since earlier 1238 versions of HTTP(S) rely on TCP, UDP ports may be blocked for any 1239 port numbers that are not commonly used, such as UDP 53 for DNS. 1241 Even when UDP ports are not blocked and HTTP/3 can flow, streaming 1242 operators (and network operators) may severely rate-limit this 1243 traffic because they do not expect to see legitimate high-bandwidth 1244 traffic such as streaming media over the UDP ports that HTTP/3 is 1245 using. 1247 As noted in Section 5.5.2, because TCP provides a reliable, in-order 1248 delivery service for applications, any packet loss for a TCP 1249 connection causes "head-of-line blocking", so that no TCP segments 1250 arriving after a packet is lost will be delivered to the receiving 1251 application until the lost packet is retransmitted, allowing in-order 1252 delivery to the application to continue. As described in [RFC9000], 1253 QUIC connections can carry multiple streams, and when packet losses 1254 do occur, only the streams carried in the lost packet are delayed. 1256 A QUIC extension currently being specified ([I-D.ietf-quic-datagram]) 1257 adds the capability for "unreliable" delivery, similar to the service 1258 provided by UDP, but these datagrams are still subject to the QUIC 1259 connection's congestion controller, providing some transport-level 1260 congestion avoidance measures, which UDP does not. 1262 As noted in Section 6.2, there is increasing interest in transport 1263 protocol behaviors that respond to delay measurements, instead of 1264 responding to packet loss. These behaviors may deliver improved user 1265 experience, but in some cases have not responded to sustained packet 1266 loss, which exhausts available buffers along the end-to-end path that 1267 may affect other users sharing that path. The QUIC protocol provides 1268 a set of congestion control hooks that can be used for algorithm 1269 agility, and [RFC9002] defines a basic algorithm with transport 1270 behavior that is roughly similar to TCP NewReno [RFC6582]. However, 1271 QUIC senders can and do unilaterally choose to use different 1272 algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or 1273 BBR, or even something completely different. 1275 We do have experience with deploying new congestion controllers 1276 without melting the Internet (CUBIC is one example), but the point 1277 mentioned in Section 6.2 about TCP being implemented in operating 1278 system kernels is also different with QUIC. Although QUIC can be 1279 implemented in operating system kernels, one of the design goals when 1280 this work was chartered was "QUIC is expected to support rapid, 1281 distributed development and testing of features", and to meet this 1282 expectation, many implementers have chosen to implement QUIC in user 1283 space, outside the operating system kernel, and to even distribute 1284 QUIC libraries with their own applications. 1286 The decision to deploy a new version of QUIC is relatively 1287 uncontrolled, compared to other widely used transport protocols, and 1288 this can include new transport behaviors that appear without much 1289 notice except to the QUIC endpoints. At IETF 105, Christian Huitema 1290 and Brian Trammell presented a talk on "Congestion Defense in Depth" 1291 [CDiD], that explored potential concerns about new QUIC congestion 1292 controllers being broadly deployed without the testing and 1293 instrumentation that current major content providers routinely 1294 include. The sense of the room at IETF 105 was that the current 1295 major content providers understood what is at stake when they deploy 1296 new congestion controllers, but this presentation, and the related 1297 discussion in TSVAREA minutes from IETF 105 ([tsvarea-105], are still 1298 worth a look for new and rapidly growing content providers. 1300 It is worth considering that if TCP-based HTTP traffic and UDP-based 1301 HTTP/3 traffic are allowed to enter operator networks on roughly 1302 equal terms, questions of fairness and contention will be heavily 1303 dependent on interactions between the congestion controllers in use 1304 for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. 1306 More broadly, [I-D.ietf-quic-manageability] discusses manageability 1307 of the QUIC transport protocol, focusing on the implications of 1308 QUIC's design and wire image on network operations involving QUIC 1309 traffic. It discusses what network operators can consider in some 1310 detail. 1312 7. Streaming Encrypted Media 1314 "Encrypted Media" has at least three meanings: 1316 * Media encrypted at the application layer, typically using some 1317 sort of Digital Rights Management (DRM) system, and typically 1318 remaining encrypted "at rest", when senders and receivers store 1319 it, 1321 * Media encrypted by the sender at the transport layer, and 1322 remaining encrypted until it reaches the ultimate media consumer 1323 (in this document, referred to as "end-to-end media encryption"), 1324 and 1326 * Media encrypted by the sender at the transport layer, and 1327 remaining encrypted until it reaches some intermediary that is 1328 _not_ the ultimate media consumer, but has credentials allowing 1329 decryption of the media content. This intermediary may examine 1330 and even transform the media content in some way, before 1331 forwarding re-encrypted media content (in this document referred 1332 to as "hop-by-hop media encryption"). 1334 Both "hop-by-hop" and "end-to-end" encrypted transport may carry 1335 media that is, in addition, encrypted at the application layer. 1337 Each of these encryption strategies is intended to achieve a 1338 different goal. For instance, application-level encryption may be 1339 used for business purposes, such as avoiding piracy or enforcing 1340 geographic restrictions on playback, while transport-layer encryption 1341 may be used to prevent media steam manipulation or to protect 1342 manifests. 1344 This document does not take a position on whether those goals are 1345 "valid" (whatever that might mean). 1347 In this document, we will focus on media encrypted at the transport 1348 layer, whether encrypted "hop-by-hop" or "end-to-end". Because media 1349 encrypted at the application layer will only be processed by 1350 application-level entities, this encryption does not have transport- 1351 layer implications. 1353 Both "End-to-End" and "Hop-by-Hop" media encryption have specific 1354 implications for streaming operators. These are described in 1355 Section 7.2 and Section 7.3. 1357 7.1. General Considerations for Media Encryption 1359 The use of strong encryption does provide confidentiality for 1360 encrypted streaming media, from the sender to either an intermediary 1361 or the ultimate media consumer, and this does prevent Deep Packet 1362 Inspection by any intermediary that does not possess credentials 1363 allowing decryption. However, even encrypted content streams may be 1364 vulnerable to traffic analysis. An intermediary that can identify an 1365 encrypted media stream without decrypting it, may be able to 1366 "fingerprint" the encrypted media stream of known content, and then 1367 match the targeted media stream against the fingerprints of known 1368 content. This protection can be lessened if a media provider is 1369 repeatedly encrypting the same content. [CODASPY17] is an example of 1370 what is possible when identifying HTTPS-protected videos over TCP 1371 transport, based either on the length of entire resources being 1372 transferred, or on characteristic packet patterns at the beginning of 1373 a resource being transferred. 1375 If traffic analysis is successful at identifying encrypted content 1376 and associating it with specific users, this breaks privacy as 1377 certainly as examining decrypted traffic. 1379 Because HTTPS has historically layered HTTP on top of TLS, which is 1380 in turn layered on top of TCP, intermediaries do have access to 1381 unencrypted TCP-level transport information, such as retransmissions, 1382 and some carriers exploited this information in attempts to improve 1383 transport-layer performance [RFC3135]. The most recent standardized 1384 version of HTTPS, HTTP/3 [I-D.ietf-quic-http], uses the QUIC protocol 1386 [RFC9000] as its transport layer. QUIC relies on the TLS 1.3 initial 1387 handshake [RFC8446] only for key exchange [RFC9001], and encrypts 1388 almost all transport parameters itself, with the exception of a few 1389 invariant header fields. In the QUIC short header, the only 1390 transport-level parameter which is sent "in the clear" is the 1391 Destination Connection ID [RFC8999], and even in the QUIC long 1392 header, the only transport-level parameters sent "in the clear" are 1393 the Version, Destination Connection ID, and Source Connection ID. 1394 For these reasons, HTTP/3 is significantly more "opaque" than HTTPS 1395 with HTTP/1 or HTTP/2. 1397 7.2. Considerations for "Hop-by-Hop" Media Encryption 1399 Although the IETF has put considerable emphasis on end-to-end 1400 streaming media encryption, there are still important use cases that 1401 require the insertion of intermediaries. 1403 There are a variety of ways to involve intermediaries, and some are 1404 much more intrusive than others. 1406 From a content provider's perspective, a number of considerations are 1407 in play. The first question is likely whether the content provider 1408 intends that intermediaries are explicitly addressed from endpoints, 1409 or whether the content provider is willing to allow intermediaries to 1410 "intercept" streaming content transparently, with no awareness or 1411 permission from either endpoint. 1413 If a content provider does not actively work to avoid interception by 1414 intermediaries, the effect will be indistinguishable from 1415 "impersonation attacks", and endpoints cannot be assumed of any level 1416 of privacy. 1418 Assuming that a content provider does intend to allow intermediaries 1419 to participate in content streaming, and does intend to provide some 1420 level of privacy for endpoints, there are a number of possible tools, 1421 either already available or still being specified. These include 1423 * Server And Network assisted DASH [MPEG-DASH-SAND] - this 1424 specification introduces explicit messaging between DASH clients 1425 and network elements or between various network elements for the 1426 purpose of improving the efficiency of streaming sessions by 1427 providing information about real-time operational characteristics 1428 of networks, servers, proxies, caches, CDNs, as well as DASH 1429 client's performance and status. 1431 * "Double Encryption Procedures for the Secure Real-Time Transport 1432 Protocol (SRTP)" [RFC8723] - this specification provides a 1433 cryptographic transform for the Secure Real-time Transport 1434 Protocol that provides both hop-by-hop and end-to-end security 1435 guarantees. 1437 * Secure Media Frames [SFRAME] - [RFC8723] is closely tied to SRTP, 1438 and this close association impeded widespread deployment, because 1439 it could not be used for the most common media content delivery 1440 mechanisms. A more recent proposal, Secure Media Frames [SFRAME], 1441 also provides both hop-by-hop and end-to-end security guarantees, 1442 but can be used with other transport protocols beyond SRTP. 1444 If a content provider chooses not to involve intermediaries, this 1445 choice should be carefully considered. As an example, if media 1446 manifests are encrypted end-to-end, network providers who had been 1447 able to lower offered quality and reduce on their networks will no 1448 longer be able to do that. Some resources that might inform this 1449 consideration are in [RFC8825] (for WebRTC) and 1450 [I-D.ietf-quic-manageability] (for HTTP/3 and QUIC). 1452 7.3. Considerations for "End-to-End" Media Encryption 1454 "End-to-end" media encryption offers the potential of providing 1455 privacy for streaming media consumers, with the idea being that if an 1456 unauthorized intermediary can't decrypt streaming media, the 1457 intermediary can't use Deep Packet Inspection (DPI) to examine HTTP 1458 request and response headers and identify the media content being 1459 streamed. 1461 "End-to-end" media encryption has become much more widespread in the 1462 years since the IETF issued "Pervasive Monitoring Is an Attack" 1463 [RFC7258] as a Best Current Practice, describing pervasive monitoring 1464 as a much greater threat than previously appreciated. After the 1465 Snowden disclosures, many content providers made the decision to use 1466 HTTPS protection - HTTP over TLS - for most or all content being 1467 delivered as a routine practice, rather than in exceptional cases for 1468 content that was considered "sensitive". 1470 Unfortunately, as noted in [RFC7258], there is no way to prevent 1471 pervasive monitoring by an "attacker", while allowing monitoring by a 1472 more benign entity who "only" wants to use DPI to examine HTTP 1473 requests and responses in order to provide a better user experience. 1474 If a modern encrypted transport protocol is used for end-to-end media 1475 encryption, intermediary streaming operators are unable to examine 1476 transport and application protocol behavior. As described in 1477 Section 7.2, only an intermediary streaming operator who is 1478 explicitly authorized to examine packet payloads, rather than 1479 intercepting packets and examining them without authorization, can 1480 continue these practices. 1482 [RFC7258] said that "The IETF will strive to produce specifications 1483 that mitigate pervasive monitoring attacks", so streaming operators 1484 should expect the IETF's direction toward preventing unauthorized 1485 monitoring of IETF protocols to continue for the forseeable future. 1487 8. Further Reading and References 1489 Editor's note: This section is to be kept in a living document where 1490 future references, links and/or updates to the existing references 1491 will be reflected. That living document is likely to be an IETF- 1492 owned Wiki: https://tinyurl.com/streaming-opcons-reading 1494 8.1. Industry Terminology 1496 * SVA Glossary: https://glossary.streamingvideoalliance.org/ 1498 * Datazoom Video Player Data Dictionary: 1499 https://help.datazoom.io/hc/en-us/articles/360031323311 1501 * Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/ 1502 en-us/articles/360046177191 1504 8.2. Surveys and Tutorials 1506 8.2.1. Encoding 1508 The following papers describe how video is encoded, different video 1509 encoding standards and tradeoffs in selecting encoding parameters. 1511 * Overview of the Versatile Video Coding (VVC) Standard and its 1512 Applications (https://ieeexplore.ieee.org/document/9503377) 1514 * Video Compression - From Concepts to the H.264/AVC Standard 1515 (https://ieeexplore.ieee.org/document/1369695) 1517 * Developments in International Video Coding Standardization After 1518 AVC, With an Overview of Versatile Video Coding (VVC) 1519 (https://ieeexplore.ieee.org/document/9328514) 1521 * A Technical Overview of AV1 (https://ieeexplore.ieee.org/ 1522 document/9363937) 1524 * CTU Depth Decision Algorithms for HEVC: A Survey 1525 (https://arxiv.org/abs/2104.08328) 1527 8.2.2. Packaging 1529 The following papers summarize the methods for selecting packaging 1530 configurations such as the resolution-bitrate pairs, segment 1531 durations, use of constant vs. variable-duration segments, etc. 1533 * Deep Reinforced Bitrate Ladders for Adaptive Video Streaming 1534 (https://dl.acm.org/doi/10.1145/3458306.3458873) 1536 * Comparing Fixed and Variable Segment Durations for Adaptive Video 1537 Streaming: a Holistic Analysis (https://dl.acm.org/ 1538 doi/10.1145/3339825.3391858) 1540 8.2.3. Content Delivery 1542 The following links describe some of the issues and solutions 1543 regarding the interconnecting of the content delivery networks. 1545 * Open Caching: Open standards for Caching in ISP Networks: 1546 https://www.streamingvideoalliance.org/working-group/open-caching/ 1548 * Netflix Open Connect: https://openconnect.netflix.com 1550 8.2.4. ABR Algorithms 1552 The two surveys describe and compare different rate-adaptation 1553 algorithms in terms of different metrics like achieved bitrate/ 1554 quality, stall rate/duration, bitrate switching frequency, fairness, 1555 network utilization, etc. 1557 * A Survey on Bitrate Adaptation Schemes for Streaming Media Over 1558 HTTP (https://ieeexplore.ieee.org/document/8424813) 1560 * A Survey of Rate Adaptation Techniques for Dynamic Adaptive 1561 Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970) 1563 8.2.5. Low-Latency Live Adaptive Streaming 1565 The following papers describe the peculiarities of adaptive streaming 1566 in low-latency live streaming scenarios. 1568 * Catching the Moment with LoL+ in Twitch-like Low-latency Live 1569 Streaming Platforms (https://ieeexplore.ieee.org/document/9429986) 1571 * Data-driven Bandwidth Prediction Models and Automated Model 1572 Selection for Low Latency (https://ieeexplore.ieee.org/ 1573 document/9154522) 1575 * Performance Analysis of ACTE: A Bandwidth Prediction Method for 1576 Low-latency Chunked Streaming (https://dl.acm.org/ 1577 doi/10.1145/3387921) 1579 * Online Learning for Low-latency Adaptive Streaming 1580 (https://dl.acm.org/doi/10.1145/3339825.3397042) 1582 * Tightrope Walking in Low-latency Live Streaming: Optimal Joint 1583 Adaptation of Video Rate and Playback Speed (https://dl.acm.org/ 1584 doi/10.1145/3458305.3463382) 1586 * Content-aware Playback Speed Control for Low-latency Live 1587 Streaming of Sports (https://dl.acm.org/ 1588 doi/10.1145/3458305.3478437) 1590 8.2.6. Server/Client/Network Collaboration 1592 The following papers explain the benefits of server and network 1593 assistance in client-driven streaming systems. There is also a good 1594 reference about how congestion affects video quality and how rate 1595 control works in streaming applications. 1597 * Manus Manum Lavat: Media Clients and Servers Cooperating with 1598 Common Media Client/Server Data (https://dl.acm.org/ 1599 doi/10.1145/3472305.3472886) 1601 * Common media client data (CMCD): initial findings 1602 (https://dl.acm.org/doi/10.1145/3458306.3461444) 1604 * SDNDASH: Improving QoE of HTTP Adaptive Streaming Using Software 1605 Defined Networking (https://dl.acm.org/ 1606 doi/10.1145/2964284.2964332) 1608 * Caching in HTTP Adaptive Streaming: Friend or Foe? 1609 (https://dl.acm.org/doi/10.1145/2578260.2578270) 1611 * A Survey on Multi-Access Edge Computing Applied to Video 1612 Streaming: Some Research Issues and Challenges 1613 (https://ieeexplore.ieee.org/document/9374553) 1615 * The Ultimate Guide to Internet Congestion Control 1616 (https://www.compiralabs.com/ultimate-guide-congestion-control) 1618 8.2.7. QoE Metrics 1620 The following papers describe various QoE metrics one can use in 1621 streaming applications. 1623 * QoE Management of Multimedia Streaming Services in Future 1624 Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/ 1625 document/8930519) 1627 * A Survey on Quality of Experience of HTTP Adaptive Streaming 1628 (https://ieeexplore.ieee.org/document/6913491) 1630 * QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open 1631 Challenges (https://ieeexplore.ieee.org/document/8666971) 1633 8.2.8. Point Clouds and Immersive Media 1635 The following papers explain the latest developments in the immersive 1636 media domain (for video and audio) and the developing standards for 1637 such media. 1639 * A Survey on Adaptive 360o Video Streaming: Solutions, Challenges 1640 and Opportunities (https://ieeexplore.ieee.org/document/9133103) 1642 * MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/ 1643 document/9374648) 1645 * Emerging MPEG Standards for Point Cloud Compression 1646 (https://ieeexplore.ieee.org/document/8571288) 1648 * Compression of Sparse and Dense Dynamic Point Clouds--Methods and 1649 Standards (https://ieeexplore.ieee.org/document/9457097) 1651 * MPEG Standards for Compressed Representation of Immersive Audio 1652 (https://ieeexplore.ieee.org/document/9444109) 1654 * An Overview of Omnidirectional MediA Format (OMAF) 1655 (https://ieeexplore.ieee.org/document/9380215) 1657 * From Capturing to Rendering: Volumetric Media Delivery with Six 1658 Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522) 1660 8.3. Open-Source Tools 1662 * 5G-MA: https://www.5g-mag.com/reference-tools 1664 * dash.js: http://reference.dashif.org/dash.js/latest/samples/ 1666 * DASH-IF Conformance: https://conformance.dashif.org 1668 * ExoPlayer: https://github.com/google/ExoPlayer 1670 * FFmpeg: https://www.ffmpeg.org/ 1672 * GPAC: https://gpac.wp.imt.fr/ 1674 * hls.js: https://github.com/video-dev/hls.js 1676 * OBS Studio: https://obsproject.com/ 1678 * Shaka Player: https://github.com/google/shaka-player 1680 * Shaka Packager: https://github.com/google/shaka-packager 1682 * Traffic Control CDN: https://trafficcontrol.apache.org/ 1684 * VideoLAN: https://www.videolan.org/projects/ 1686 * video.js: https://github.com/videojs/video.js 1688 8.4. Technical Events 1690 * ACM Mile High Video (MHV): https://mile-high.video/ 1692 * ACM Multimedia Systems (MMSys): https://acmmmsys.org 1694 * ACM Multimedia (MM): https://acmmm.org 1696 * ACM NOSSDAV: https://www.nossdav.org/ 1698 * ACM Packet Video: https://packet.video/ 1700 * Demuxed and meetups: https://demuxed.com/ and https://demuxed.com/ 1701 events/ 1703 * DVB World: https://www.dvbworld.org 1705 * EBU BroadThinking: https://tech.ebu.ch/events/broadthinking2021 1707 * IBC Conference: https://show.ibc.org/conference/ibc-conference 1708 * IEEE Int. Conf. on Multimedia and Expo (ICME) 1710 * Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws 1712 * Live Video Stack: https://sh2021.livevideostack.com 1714 * Picture Coding Symp. (PCS) 1716 * SCTE Expo: https://expo.scte.org/ 1718 8.5. List of Organizations Working on Streaming Media 1720 * 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/ 1721 sa4-codec 1723 * 5G-MAG: https://www.5g-mag.com/ 1725 * AOM: http://aomedia.org/ 1727 * ATSC: https://www.atsc.org/ 1729 * CTA WAVE: https://cta.tech/Resources/Standards/WAVE-Project 1731 * DASH Industry Forum: https://dashif.org/ 1733 * DVB: https://dvb.org/ 1735 * HbbTV: https://www.hbbtv.org/ 1737 * HESP Alliance: https://www.hespalliance.org/ 1739 * IAB: https://www.iab.com/ 1741 * MPEG: https://www.mpegstandards.org/ 1743 * Streaming Video Alliance: https://www.streamingvideoalliance.org/ 1745 * SCTE: https://www.scte.org/ 1747 * SMPTE: https://www.smpte.org/ 1749 * SRT Alliance: https://www.srtalliance.org/ 1751 * Video Services Forum: https://vsf.tv/ 1753 * VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx 1755 * W3C: https://www.w3.org/ 1757 8.6. Topics to Keep an Eye on 1759 8.6.1. 5G and Media 1761 5G new radio and systems technologies provide new functionalities for 1762 video distribution. 5G targets not only smartphones, but also new 1763 devices such as augmented reality glasses or automotive receivers. 1764 Higher bandwidth, lower latencies, edge and cloud computing 1765 functionalities, service-based architectures, low power consumption, 1766 broadcast/multicast functionalities and other network functions come 1767 hand in hand with new media formats and processing capabilities 1768 promising better and more consistent quality for traditional video 1769 streaming services as well as enabling new experiences such as 1770 immersive media and augmented realities. 1772 * 5G Multimedia Standardization (https://www.riverpublishers.com/ 1773 journal_read_html_article.php?j=JICTS/6/1/8) 1775 8.6.2. Ad Insertion 1777 Ads can be inserted at different stages in the streaming workflow, on 1778 the server side or client side. The DASH-IF guidelines detail 1779 server-side ad-insertion with period replacements based on 1780 manipulating the manifest. HLS interstitials provide a similar 1781 approach. The idea is that the manifest can be changed and point to 1782 a sub-playlist of segments, possibly located on a different location. 1783 This approach results in efficient resource usage in the network, as 1784 duplicate caching is avoided, but some intelligence at the player is 1785 needed to deal with content transitions (e.g., codec changes, 1786 timeline gaps, etc.). Player support for such content is gradually 1787 maturing. Other important technologies for ad insertion include 1788 signalling of ads and breaks that is still typically based on SCTE-35 1789 for HLS and SCTE-214 for DASH. Such signals provide useful 1790 information for scheduling the ads and contacting ad servers. The 1791 usage of SCTE-35 for ad insertion is popular in the broadcast 1792 industry, while the exact usage in the OTT space is still being 1793 discussed in SCTE. Another important technology is identification of 1794 ads, such as based on ad-id or other commercial entities that provide 1795 such services. The identification of the ad in a manifest or stream 1796 is usually standardized by SMPTE. Other key technologies for ad 1797 insertion include tracking of viewer impressions, usually based on 1798 Video Ad Serving Template (VAST) defined by IAB. 1800 * DASH-IF Ad Insertion Guidelines: https://dashif.org/docs/CR-Ad- 1801 Insertion-r7.pdf 1803 * SCTE-214-1: https://www.scte.org/standards-development/library/ 1804 standards-catalog/ansiscte-214-1-2016/ 1806 * RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital 1807 Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/ 1808 document/7291518 1810 * IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio- 1811 video/tech-lab-digital-video-suite/ 1813 8.6.3. Contribution and Ingest 1815 There are different contribution and ingest specifications dealing 1816 with different use cases. A common case is contribution that 1817 previously happened over satellite to a broadcast or streaming 1818 headend. RIST and SRT are examples of such contribution protocols. 1819 Within a streaming headend the encoder and packager/CDN may have an 1820 ingest/contribution interface as well. This is specified by the 1821 DASH-IF Ingest. 1823 * DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest 1825 * RIST: https://www.rist.tv/ 1827 * SRT: https://github.com/Haivision/srt 1829 8.6.4. Synchronized Encoding and Packaging 1831 Practical streaming headends need redundant encoders and packagers to 1832 operate without glitches and blackouts. The redundant operation 1833 requires synchronization between two or more encoders and also 1834 between two or more packagers that possibly handle different inputs 1835 and outputs, generating compatible inter-changeable output 1836 representations. This problem is important for anyone developing a 1837 streaming headend at scale, and the synchronization problem is 1838 currently under discussion in the wider community. Follow the 1839 developments at: https://sites.google.com/view/encodersyncworkshop/ 1840 home 1842 8.6.5. WebRTC-Based Streaming 1844 WebRTC is increasingly being used for streaming of time-sensitive 1845 content such as live sporting events. Innovations in cloud computing 1846 allow implementers to efficiently scale delivery of content using 1847 WebRTC. Support for WebRTC communication is available on all modern 1848 web browsers and is available on native clients for all major 1849 platforms. 1851 * DASH-IF WebRTC Discussions: https://dashif.org/webRTC/ 1853 * Overview of WebRTC: https://webrtc.org/ 1855 9. IANA Considerations 1857 This document requires no actions from IANA. 1859 10. Security Considerations 1861 Security is an important matter for streaming media applications and 1862 it was briefly touched on in Section 7.1. This document itself 1863 introduces no new security issues. 1865 11. Acknowledgments 1867 Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, 1868 Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, 1869 Matt Stock, Mike English, Renan Krishna, Roni Even, and Will Law for 1870 very helpful suggestions, reviews and comments. 1872 (If we missed your name, please let us know!) 1874 12. Informative References 1876 [ABRSurvey] 1877 Taani, B., Begen, A.C., Timmerer, C., Zimmermann, R., and 1878 A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes 1879 for Streaming Media Over HTTP", IEEE Communications 1880 Surveys & Tutorials , 2019, 1881 . 1883 [BAP] "The Coalition for Better Ads", n.d., 1884 . 1886 [CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion 1887 Defense in Depth", July 2019, 1888 . 1891 [CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked- 1892 Encoded and Chunked Transferred CMAF", October 2018, 1893 . 1896 [CODASPY17] 1897 Reed, A. and M. Kranch, "Identifying HTTPS-Protected 1898 Netflix Videos in Real-Time", ACM CODASPY , March 2017, 1899 . 1901 [CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", 1902 Communications of the ACM, Volume 55, Issue 7, pp. 42-50 , 1903 July 2012. 1905 [COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based 1906 Congestion Control for the Internet", USENIX NSDI , April 1907 2018, . 1909 [CTA-2066] Consumer Technology Association, "Streaming Quality of 1910 Experience Events, Properties and Metrics", March 2020, 1911 . 1914 [CTA-5004] CTA, ., "Common Media Client Data (CMCD)", September 2020, 1915 . 1918 [CVNI] "Cisco Visual Networking Index: Forecast and Trends, 1919 2017-2022 White Paper", 27 February 2019, 1920 . 1924 [ELASTIC] De Cicco, L., Caldaralo, V., Palmisano, V., and S. 1925 Mascolo, "ELASTIC: A client-side controller for dynamic 1926 adaptive streaming over HTTP (DASH)", Packet Video 1927 Workshop , December 2013, 1928 . 1930 [Encodings] 1931 Apple, Inc, ., "HLS Authoring Specification for Apple 1932 Devices", June 2020, 1933 . 1937 [I-D.cardwell-iccrg-bbr-congestion-control] 1938 Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. 1939 Jacobson, "BBR Congestion Control", Work in Progress, 1940 Internet-Draft, draft-cardwell-iccrg-bbr-congestion- 1941 control-01, 7 November 2021, 1942 . 1945 [I-D.draft-pantos-hls-rfc8216bis] 1946 Pantos, R., "HTTP Live Streaming 2nd Edition", Work in 1947 Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-10, 1948 8 November 2021, . 1951 [I-D.ietf-httpbis-cache] 1952 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1953 Caching", Work in Progress, Internet-Draft, draft-ietf- 1954 httpbis-cache-19, 12 September 2021, 1955 . 1958 [I-D.ietf-quic-datagram] 1959 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 1960 Datagram Extension to QUIC", Work in Progress, Internet- 1961 Draft, draft-ietf-quic-datagram-07, 8 December 2021, 1962 . 1965 [I-D.ietf-quic-http] 1966 Bishop, M., "Hypertext Transfer Protocol Version 3 1967 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1968 quic-http-34, 2 February 2021, 1969 . 1972 [I-D.ietf-quic-manageability] 1973 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 1974 Transport Protocol", Work in Progress, Internet-Draft, 1975 draft-ietf-quic-manageability-13, 2 September 2021, 1976 . 1979 [I-D.ietf-quic-qlog-h3-events] 1980 Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK 1981 event definitions for qlog", Work in Progress, Internet- 1982 Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021, 1983 . 1986 [I-D.ietf-quic-qlog-main-schema] 1987 Marx, R., Niccolini, L., and M. Seemann, "Main logging 1988 schema for qlog", Work in Progress, Internet-Draft, draft- 1989 ietf-quic-qlog-main-schema-01, 25 October 2021, 1990 . 1993 [I-D.ietf-quic-qlog-quic-events] 1994 Marx, R., Niccolini, L., and M. Seemann, "QUIC event 1995 definitions for qlog", Work in Progress, Internet-Draft, 1996 draft-ietf-quic-qlog-quic-events-00, 10 June 2021, 1997 . 2000 [IAB-ADS] "IAB", n.d., . 2002 [IABcovid] Arkko, J., Farrel, S., Kühlewind, M., and C. Perkins, 2003 "Report from the IAB COVID-19 Network Impacts Workshop 2004 2020", November 2020, . 2007 [Jacobson-Karels] 2008 Jacobson, V. and M. Karels, "Congestion Avoidance and 2009 Control", November 1988, 2010 . 2012 [Labovitz] Labovitz, C., "Network traffic insights in the time of 2013 COVID-19: April 9 update", April 2020, 2014 . 2017 [LabovitzDDoS] 2018 Takahashi, D., "Why the game industry is still vulnerable 2019 to DDoS attacks", May 2018, 2020 . 2024 [LL-DASH] DASH-IF, ., "Low-latency Modes for DASH", March 2020, 2025 . 2027 [Micro] Taher, T.M., Misurac, M.J., LoCicero, J.L., and D.R. Ucci, 2028 "Microwave Oven Signal Interference Mitigation For Wi-Fi 2029 Communication Systems", 2008 5th IEEE Consumer 2030 Communications and Networking Conference 5th IEEE, pp. 2031 67-68 , 2008. 2033 [Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video 2034 Alliance", April 2020, 2035 . 2040 [MMSP20] Durak, K. and . et al, "Evaluating the performance of 2041 Apple's low-latency HLS", IEEE MMSP , September 2020, 2042 . 2044 [MMSys11] Akhshabi, S., Begen, A.C., and C. Dovrolis, "An 2045 experimental evaluation of rate-adaptation algorithms in 2046 adaptive streaming over HTTP", ACM MMSys , February 2011, 2047 . 2049 [MPEG-CMAF] 2050 "ISO/IEC 23000-19:2020 Multimedia application format 2051 (MPEG-A) - Part 19: Common media application format (CMAF) 2052 for segmented media", March 2020, 2053 . 2055 [MPEG-DASH] 2056 "ISO/IEC 23009-1:2019 Dynamic adaptive streaming over HTTP 2057 (DASH) - Part 1: Media presentation description and 2058 segment formats", December 2019, 2059 . 2061 [MPEG-DASH-SAND] 2062 "ISO/IEC 23009-5:2017 Dynamic adaptive streaming over HTTP 2063 (DASH) - Part 5: Server and network assisted DASH (SAND)", 2064 February 2017, . 2066 [MPEG-TS] "H.222.0 : Information technology - Generic coding of 2067 moving pictures and associated audio information: 2068 Systems", 29 August 2018, 2069 . 2071 [MPEGI] Boyce, J.M. and . et al, "MPEG Immersive Video Coding 2072 Standard", Proceedings of the IEEE , n.d., 2073 . 2075 [OReilly-HPBN] 2076 "High Performance Browser Networking (Chapter 2: Building 2077 Blocks of TCP)", May 2021, 2078 . 2080 [PCC] Schwarz, S. and . et al, "Emerging MPEG Standards for 2081 Point Cloud Compression", IEEE Journal on Emerging and 2082 Selected Topics in Circuits and Systems , March 2019, 2083 . 2085 [Port443] "Service Name and Transport Protocol Port Number 2086 Registry", April 2021, . 2090 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2091 RFC 793, DOI 10.17487/RFC0793, September 1981, 2092 . 2094 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 2095 Retransmit, and Fast Recovery Algorithms", RFC 2001, 2096 DOI 10.17487/RFC2001, January 1997, 2097 . 2099 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 2100 Shelby, "Performance Enhancing Proxies Intended to 2101 Mitigate Link-Related Degradations", RFC 3135, 2102 DOI 10.17487/RFC3135, June 2001, 2103 . 2105 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2106 Jacobson, "RTP: A Transport Protocol for Real-Time 2107 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2108 July 2003, . 2110 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2111 Conrad, "Stream Control Transmission Protocol (SCTP) 2112 Partial Reliability Extension", RFC 3758, 2113 DOI 10.17487/RFC3758, May 2004, 2114 . 2116 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 2117 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 2118 DOI 10.17487/RFC4733, December 2006, 2119 . 2121 [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop 2122 on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", 2123 RFC 5594, DOI 10.17487/RFC5594, July 2009, 2124 . 2126 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 2127 Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 2128 2010, . 2130 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 2131 Eleftheriadis, "RTP Payload Format for Scalable Video 2132 Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, 2133 . 2135 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 2136 NewReno Modification to TCP's Fast Recovery Algorithm", 2137 RFC 6582, DOI 10.17487/RFC6582, April 2012, 2138 . 2140 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 2141 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 2142 DOI 10.17487/RFC6817, December 2012, 2143 . 2145 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 2146 (RTCP) Extended Report (XR) Block for Delay Metric 2147 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 2148 . 2150 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2151 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2152 2014, . 2154 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2155 "Encapsulating MPLS in UDP", RFC 7510, 2156 DOI 10.17487/RFC7510, April 2015, 2157 . 2159 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 2160 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 2161 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 2162 DOI 10.17487/RFC7656, November 2015, 2163 . 2165 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 2166 TCP to Support Rate-Limited Traffic", RFC 7661, 2167 DOI 10.17487/RFC7661, October 2015, 2168 . 2170 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 2171 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 2172 DOI 10.17487/RFC8083, March 2017, 2173 . 2175 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 2176 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 2177 . 2179 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2180 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2181 March 2017, . 2183 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 2184 RFC 8216, DOI 10.17487/RFC8216, August 2017, 2185 . 2187 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 2188 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 2189 RFC 8312, DOI 10.17487/RFC8312, February 2018, 2190 . 2192 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2193 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2194 . 2196 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 2197 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 2198 June 2019, . 2200 [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, 2201 "Double Encryption Procedures for the Secure Real-Time 2202 Transport Protocol (SRTP)", RFC 8723, 2203 DOI 10.17487/RFC8723, April 2020, 2204 . 2206 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 2207 Browser-Based Applications", RFC 8825, 2208 DOI 10.17487/RFC8825, January 2021, 2209 . 2211 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 2212 RFC 8999, DOI 10.17487/RFC8999, May 2021, 2213 . 2215 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 2216 Multiplexed and Secure Transport", RFC 9000, 2217 DOI 10.17487/RFC9000, May 2021, 2218 . 2220 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 2221 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 2222 . 2224 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 2225 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 2226 May 2021, . 2228 [SFRAME] "Secure Media Frames Working Group (Home Page)", n.d., 2229 . 2231 [SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol 2232 Overview", 15 April 2020, 2233 . 2238 [Survey360o] 2239 Yaqoob, A., Bi, T., and G.-M. Muntean, "A Survey on 2240 Adaptive 360° Video Streaming: Solutions, Challenges and 2241 Opportunities", IEEE Communications Surveys & Tutorials , 2242 July 2020, . 2244 [tsvarea-105] 2245 "TSVAREA Minutes - IETF 105", July 2019, 2246 . 2249 Authors' Addresses 2251 Jake Holland 2252 Akamai Technologies, Inc. 2253 150 Broadway 2254 Cambridge, MA 02144, 2255 United States of America 2257 Email: jakeholland.net@gmail.com 2259 Ali Begen 2260 Networked Media 2261 Turkey 2263 Email: ali.begen@networked.media 2265 Spencer Dawkins 2266 Tencent America LLC 2267 United States of America 2269 Email: spencerdawkins.ietf@gmail.com