| < draft-ietf-mops-streaming-opcons-09.txt | draft-ietf-mops-streaming-opcons-10.txt > | |||
|---|---|---|---|---|
| MOPS J. Holland | MOPS J. Holland | |||
| Internet-Draft Akamai Technologies, Inc. | Internet-Draft Akamai Technologies, Inc. | |||
| Intended status: Informational A. Begen | Intended status: Informational A. Begen | |||
| Expires: 2 September 2022 Networked Media | Expires: 23 October 2022 Networked Media | |||
| S. Dawkins | S. Dawkins | |||
| Tencent America LLC | Tencent America LLC | |||
| 1 March 2022 | 21 April 2022 | |||
| Operational Considerations for Streaming Media | Operational Considerations for Streaming Media | |||
| draft-ietf-mops-streaming-opcons-09 | draft-ietf-mops-streaming-opcons-10 | |||
| Abstract | Abstract | |||
| This document provides an overview of operational networking issues | This document provides an overview of operational networking issues | |||
| that pertain to quality of experience when streaming video and other | that pertain to quality of experience when streaming video and other | |||
| high-bitrate media over the Internet. | high-bitrate media over the Internet. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 2 September 2022. | This Internet-Draft will expire on 23 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 4 | 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 4 | |||
| 1.1.1. Venues for Contribution and Discussion . . . . . . . 5 | 1.1.1. Venues for Contribution and Discussion . . . . . . . 4 | |||
| 2. Our Focus on Streaming Video . . . . . . . . . . . . . . . . 5 | 2. Our Focus on Streaming Video . . . . . . . . . . . . . . . . 5 | |||
| 3. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6 | 3. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1. Scaling Requirements for Media Delivery . . . . . . . . . 6 | 3.1. Scaling Requirements for Media Delivery . . . . . . . . . 6 | |||
| 3.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6 | 3.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 7 | 3.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6 | |||
| 3.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7 | 3.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7 | |||
| 3.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8 | 3.2.1. Recognizing Changes from an Expected Baseline . . . . 8 | |||
| 3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9 | 3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 10 | 3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11 | 3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11 | |||
| 3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11 | 3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11 | |||
| 3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12 | 3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12 | |||
| 4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14 | 4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14 | 4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15 | 4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16 | 4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16 | |||
| 4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 5. Adaptive Encoding, Adaptive Delivery, and Measurement | 5. Adaptive Encoding, Adaptive Delivery, and Measurement | |||
| Collection . . . . . . . . . . . . . . . . . . . . . . . 17 | Collection . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 | 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18 | 5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18 | 5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18 | |||
| 5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 21 | 5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20 | |||
| 5.5.1. Idle Time between Segments . . . . . . . . . . . . . 21 | 5.5.1. Idle Time between Segments . . . . . . . . . . . . . 21 | |||
| 5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 22 | 5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21 | |||
| 5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22 | 5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22 | |||
| 5.6. Measurement Collection . . . . . . . . . . . . . . . . . 23 | 5.6. Measurement Collection . . . . . . . . . . . . . . . . . 22 | |||
| 5.6.1. CTA-2066: Streaming Quality of Experience Events, | ||||
| Properties and Metrics . . . . . . . . . . . . . . . 23 | ||||
| 5.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23 | ||||
| 5.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 24 | ||||
| 6. Evolution of Transport Protocols and Transport Protocol | 6. Evolution of Transport Protocols and Transport Protocol | |||
| Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24 | Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 25 | 6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24 | |||
| 6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 26 | 6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25 | |||
| 6.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 27 | 6.3. QUIC and Its Behavior . . . . . . . . . . . . . . . . . . 26 | |||
| 7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 29 | 7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28 | |||
| 7.1. General Considerations for Media Encryption . . . . . . . 30 | 7.1. General Considerations for Media Encryption . . . . . . . 29 | |||
| 7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 31 | 7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30 | |||
| 7.3. Considerations for "End-to-End" Media Encryption . . . . 32 | 7.3. Considerations for "End-to-End" Media Encryption . . . . 32 | |||
| 8. Further Reading and References . . . . . . . . . . . . . . . 33 | 8. Further Reading and References . . . . . . . . . . . . . . . 32 | |||
| 8.1. Industry Terminology . . . . . . . . . . . . . . . . . . 33 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 33 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 33 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33 | 12. Informative References . . . . . . . . . . . . . . . . . . . 33 | |||
| 8.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 34 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 8.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 34 | ||||
| 8.2.5. Low-Latency Live Adaptive Streaming . . . . . . . . . 34 | ||||
| 8.2.6. Server/Client/Network Collaboration . . . . . . . . . 35 | ||||
| 8.2.7. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35 | ||||
| 8.2.8. Point Clouds and Immersive Media . . . . . . . . . . 36 | ||||
| 8.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36 | ||||
| 8.4. Technical Events . . . . . . . . . . . . . . . . . . . . 37 | ||||
| 8.5. List of Organizations Working on Streaming Media . . . . 37 | ||||
| 8.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38 | ||||
| 8.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38 | ||||
| 8.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 39 | ||||
| 8.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 40 | ||||
| 8.6.4. Synchronized Encoding and Packaging . . . . . . . . . 40 | ||||
| 8.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 40 | ||||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 | ||||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | ||||
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 | ||||
| 12. Informative References . . . . . . . . . . . . . . . . . . . 41 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
| 1. Introduction | 1. Introduction | |||
| This document examines networking issues as they relate to quality of | This document examines networking and transport protocol issues as | |||
| experience in Internet media delivery, especially focusing on | they relate to quality of experience (QOE) in Internet media | |||
| capturing characteristics of streaming video delivery that have | delivery, especially focusing on capturing characteristics of | |||
| surprised network designers or transport experts who lack specific | streaming video delivery that have surprised network designers or | |||
| video expertise, since streaming media highlights key differences | transport experts who lack specific video expertise, since streaming | |||
| between common assumptions in existing networking practices and | media highlights key differences between common assumptions in | |||
| observations of video delivery issues encountered when streaming | existing networking practices and observations of video delivery | |||
| media over those existing networks. | issues encountered when streaming media over those existing networks. | |||
| This document specifically focuses on streaming applications and | This document specifically focuses on streaming applications and | |||
| defines streaming as follows: | defines streaming as follows: | |||
| * Streaming is transmission of a continuous media from a server to a | * Streaming is transmission of a continuous media from a server to a | |||
| client and its simultaneous consumption by the client. | client and its simultaneous consumption by the client. | |||
| * Here, "continuous media" refers to media and associated streams | * Here, "continuous media" refers to media and associated streams | |||
| such as video, audio, metadata, etc. In this definition, the | such as video, audio, metadata, etc. In this definition, the | |||
| critical term is "simultaneous", as it is not considered streaming | critical term is "simultaneous", as it is not considered streaming | |||
| skipping to change at page 5, line 30 ¶ | skipping to change at page 5, line 11 ¶ | |||
| * Join: https://www.ietf.org/mailman/listinfo/mops | * Join: https://www.ietf.org/mailman/listinfo/mops | |||
| (https://www.ietf.org/mailman/listinfo/mops) | (https://www.ietf.org/mailman/listinfo/mops) | |||
| * Search: https://mailarchive.ietf.org/arch/browse/mops/ | * Search: https://mailarchive.ietf.org/arch/browse/mops/ | |||
| (https://mailarchive.ietf.org/arch/browse/mops/) | (https://mailarchive.ietf.org/arch/browse/mops/) | |||
| 2. Our Focus on Streaming Video | 2. Our Focus on Streaming Video | |||
| As the internet has grown, an increasingly large share of the traffic | As the internet has grown, an increasingly large share of the traffic | |||
| delivered to end users has become video. Estimates put the total | delivered to end users has become video. The most recent available | |||
| share of internet video traffic at 75% in 2019, expected to grow to | estimates found that 75% of the total traffic to end users was video | |||
| 82% by 2022. This estimate projects the gross volume of video | in 2019. At that time, the share of traffic that was video had been | |||
| traffic will more than double during this time, based on a compound | growing for years and was projected to continue growing (Appendix D | |||
| annual growth rate continuing at 34% (from Appendix D of [CVNI]). | of [CVNI]). | |||
| A substantial part of this growth is due to increased use of | A substantial part of this growth is due to increased use of | |||
| streaming video, although the amount of video traffic in real-time | streaming video, although the amount of video traffic in real-time | |||
| communications (for example, online videoconferencing) has also grown | communications (for example, online videoconferencing) has also grown | |||
| significantly. While both streaming video and videoconferencing have | significantly. While both streaming video and videoconferencing have | |||
| real-time delivery and latency requirements, these requirements vary | real-time delivery and latency requirements, these requirements vary | |||
| from one application to another. For example, videoconferencing | from one application to another. For additional discussion of | |||
| demands an end-to-end (one-way) latency of a few hundreds of | latency requirements, see Section 4. | |||
| milliseconds whereas live streaming can tolerate latencies of several | ||||
| seconds. | ||||
| In many contexts, video traffic can be handled transparently as | In many contexts, video traffic can be handled transparently as | |||
| generic application-level traffic. However, as the volume of video | generic application-level traffic. However, as the volume of video | |||
| traffic continues to grow, it is becoming increasingly important to | traffic continues to grow, it is becoming increasingly important to | |||
| consider the effects of network design decisions on application-level | consider the effects of network design decisions on application-level | |||
| performance, with considerations for the impact on video delivery. | performance, with considerations for the impact on video delivery. | |||
| Much of the focus of this document is on reliable media using HTTP | Much of the focus of this document is on reliable media using HTTP. | |||
| over TCP, which is widely used because | HTTP is widely used because | |||
| * support for HTTP is widely available in a wide range of operating | * support for HTTP is widely available in a wide range of operating | |||
| systems, | systems, | |||
| * HTTP is also used in a wide variety of other applications, | * HTTP is also used in a wide variety of other applications, | |||
| * HTTP has been demonstrated to provide acceptable performance over | * HTTP has been demonstrated to provide acceptable performance over | |||
| the open Internet, | the open Internet, | |||
| * HTTP includes state of the art standardized security mechanisms, | * HTTP includes state of the art standardized security mechanisms, | |||
| and | and | |||
| * HTTP can make use of already-deployed caching infrastructure. | * HTTP can make use of already-deployed caching infrastructure such | |||
| as CDNs (Content Delivery Networks), local proxies, and browser | ||||
| caches. | ||||
| Various HTTP versions have been used for media delivery. HTTP/1.0, | ||||
| HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport | ||||
| behavior is described in Section 6.2. HTTP/3 is carried over QUIC, | ||||
| and QUIC's transport behavior is described in Section 6.3. | ||||
| Unreliable media delivery using RTP and other UDP-based protocols is | Unreliable media delivery using RTP and other UDP-based protocols is | |||
| also discussed in Section 4.1, Section 5.7, Section 6.1, and | also discussed in Section 4.1, Section 6.1, and Section 7.2, but it | |||
| Section 7.2, but it is difficult to give general guidance for these | is difficult to give general guidance for these applications. For | |||
| applications. For instance, when loss occurs, the most appropriate | instance, when loss occurs, the most appropriate response may depend | |||
| response may depend on the type of codec being used. | on the type of codec being used. | |||
| 3. Bandwidth Provisioning | 3. Bandwidth Provisioning | |||
| 3.1. Scaling Requirements for Media Delivery | 3.1. Scaling Requirements for Media Delivery | |||
| 3.1.1. Video Bitrates | 3.1.1. Video Bitrates | |||
| Video bitrate selection depends on many variables including the | Video bitrate selection depends on many variables including the | |||
| resolution (height and width), frame rate, color depth, codec, | resolution (height and width), frame rate, color depth, codec, | |||
| encoding parameters, scene complexity and amount of motion. | encoding parameters, scene complexity and amount of motion. | |||
| skipping to change at page 8, line 19 ¶ | skipping to change at page 7, line 45 ¶ | |||
| in greater detail in Section 5. | in greater detail in Section 5. | |||
| * Media servers also typically implement transport protocols with | * Media servers also typically implement transport protocols with | |||
| capacity-seeking congestion controllers that probe for bandwidth, | capacity-seeking congestion controllers that probe for bandwidth, | |||
| and adjust the sending rate based on transport mechanisms. This | and adjust the sending rate based on transport mechanisms. This | |||
| is described in greater detail in Section 6. | is described in greater detail in Section 6. | |||
| The result is that these two (potentially competing) "helpful" | The result is that these two (potentially competing) "helpful" | |||
| mechanisms each respond to the same bottleneck with no coordination | mechanisms each respond to the same bottleneck with no coordination | |||
| between themselves, so that each is unaware of actions taken by the | between themselves, so that each is unaware of actions taken by the | |||
| other, and this can result in a quality of experience for users that | other, and this can result in QOE for users that is significantly | |||
| is significantly lower than what could have been achieved. | lower than what could have been achieved. | |||
| In one example, if a media server overestimates the available | In one example, if a media server overestimates the available | |||
| bandwidth to the media player, | bandwidth to the media player, | |||
| * the transport protocol detects loss due to congestion, and reduces | * the transport protocol detects loss due to congestion, and reduces | |||
| its sending window size per round trip, | its sending window size per round trip, | |||
| * the media server adapts to application-level feedback from the | * the media server adapts to application-level feedback from the | |||
| media player, and reduces its own sending rate, | media player, and reduces its own sending rate, | |||
| skipping to change at page 8, line 49 ¶ | skipping to change at page 8, line 26 ¶ | |||
| * the transport protocol can't probe for available path bandwidth by | * the transport protocol can't probe for available path bandwidth by | |||
| sending at a higher rate. | sending at a higher rate. | |||
| In order to avoid these types of situations, which can potentially | In order to avoid these types of situations, which can potentially | |||
| affect all the users whose streaming media traverses a bottleneck | affect all the users whose streaming media traverses a bottleneck | |||
| link, there are several possible mitigations that streaming operators | link, there are several possible mitigations that streaming operators | |||
| can use, but the first step toward mitigating a problem is knowing | can use, but the first step toward mitigating a problem is knowing | |||
| when that problem occurs. | when that problem occurs. | |||
| 3.2.1. Know Your Network Traffic | 3.2.1. Recognizing Changes from an Expected Baseline | |||
| There are many reasons why path characteristics might change | There are many reasons why path characteristics might change | |||
| suddenly, for example, | suddenly, for example, | |||
| * "cross traffic" that traverses part of the path, especially if | * "cross traffic" that traverses part of the path, especially if | |||
| this traffic is "inelastic", and does not, itself, respond to | this traffic is "inelastic", and does not, itself, respond to | |||
| indications of path congestion. | indications of path congestion. | |||
| * routing changes, which can happen in normal operation, especially | * routing changes, which can happen in normal operation, especially | |||
| if the new path now includes path segments that are more heavily | if the new path now includes path segments that are more heavily | |||
| loaded, offer lower total bandwidth, or simply cover more | loaded, offer lower total bandwidth, or simply cover more | |||
| distance. | distance. | |||
| Recognizing that a path carrying streaming media is "not behaving the | In order to recognize that a path carrying streaming media is "not | |||
| way it normally does" is fundamental. Analytics that aid in that | behaving the way it normally does", having an expected baseline that | |||
| recognition can be more or less sophisticated, and can be as simple | describes "the way it normally does" is fundamental. Analytics that | |||
| as noticing that the apparent round trip times for media traffic | aid in that recognition can be more or less sophisticated, and can be | |||
| carried over TCP transport on some paths are suddenly and | as simple as noticing that the apparent round trip times for media | |||
| traffic carried over TCP transport on some paths are suddenly and | ||||
| significantly longer than usual. Passive monitors can detect changes | significantly longer than usual. Passive monitors can detect changes | |||
| in the elapsed time between the acknowledgements for specific TCP | in the elapsed time between the acknowledgements for specific TCP | |||
| segments from a TCP receiver, since TCP octet sequence numbers and | segments from a TCP receiver, since TCP octet sequence numbers and | |||
| acknowledgements for those sequence numbers are "carried in the | acknowledgements for those sequence numbers are "carried in the | |||
| clear", even if the TCP payload itself is encrypted. See Section 6.2 | clear", even if the TCP payload itself is encrypted. See Section 6.2 | |||
| for more information. | for more information. | |||
| As transport protocols evolve to encrypt their transport header | As transport protocols evolve to encrypt their transport header | |||
| fields, one side effect of increasing encryption is that the kind of | fields, one side effect of increasing encryption is that the kind of | |||
| passive monitoring, or even "performance enhancement" ([RFC3135]) | passive monitoring, or even "performance enhancement" ([RFC3135]) | |||
| skipping to change at page 12, line 22 ¶ | skipping to change at page 12, line 4 ¶ | |||
| "swarms" of hosts, uploading and downloading files to each other, | "swarms" of hosts, uploading and downloading files to each other, | |||
| rather than communicating with a server. Bittorrent favored peers | rather than communicating with a server. Bittorrent favored peers | |||
| who uploaded as much as they downloaded, so that new Bittorrent users | who uploaded as much as they downloaded, so that new Bittorrent users | |||
| had an incentive to significantly increase their upstream bandwidth | had an incentive to significantly increase their upstream bandwidth | |||
| utilization. | utilization. | |||
| The combination of the large volume of "torrents" and the peer-to- | The combination of the large volume of "torrents" and the peer-to- | |||
| peer characteristic of swarm transfers meant that end user hosts were | peer characteristic of swarm transfers meant that end user hosts were | |||
| suddenly uploading higher volumes of traffic to more destinations | suddenly uploading higher volumes of traffic to more destinations | |||
| than was the case before Bittorrent. This caused at least one large | than was the case before Bittorrent. This caused at least one large | |||
| internet service provider (ISP) to attempt to "throttle" these | Internet service provider (ISP) to attempt to "throttle" these | |||
| transfers in order to to mitigate the load that these hosts placed on | transfers in order to to mitigate the load that these hosts placed on | |||
| their network. These efforts were met by increased use of encryption | their network. These efforts were met by increased use of encryption | |||
| in Bittorrent, similar to an arms race, and set off discussions about | in Bittorrent, and complaints to regulators calling for regulatory | |||
| "Net Neutrality" and calls for regulatory action. | action. | |||
| The BitTorrent case study is just one example, but the example is | ||||
| included here to make it clear that unpredicted and unpredictable | ||||
| massive traffic spikes may not be the result of natural disasters, | ||||
| but they can still have significant impacts. | ||||
| Especially as end users increase use of video-based social networking | Especially as end users increase use of video-based social networking | |||
| applications, it will be helpful for access network providers to | applications, it will be helpful for access network providers to | |||
| watch for increasing numbers of end users uploading significant | watch for increasing numbers of end users uploading significant | |||
| amounts of content. | amounts of content. | |||
| 3.7. Extremely Unpredictable Usage Profiles | 3.7. Extremely Unpredictable Usage Profiles | |||
| The causes of unpredictable usage described in Section 3.6 were more | The causes of unpredictable usage described in Section 3.6 were more | |||
| or less the result of human choices, but we were reminded during a | or less the result of human choices, but we were reminded during a | |||
| skipping to change at page 13, line 40 ¶ | skipping to change at page 13, line 21 ¶ | |||
| Network Impacts Workshop [IABcovid] in November 2020. Given a larger | Network Impacts Workshop [IABcovid] in November 2020. Given a larger | |||
| number of reports and more time to reflect, the following | number of reports and more time to reflect, the following | |||
| observations from the draft workshop report are worth considering. | observations from the draft workshop report are worth considering. | |||
| * Participants describing different types of networks reported | * Participants describing different types of networks reported | |||
| different kinds of impacts, but all types of networks saw impacts. | different kinds of impacts, but all types of networks saw impacts. | |||
| * Mobile networks saw traffic reductions and residential networks | * Mobile networks saw traffic reductions and residential networks | |||
| saw significant increases. | saw significant increases. | |||
| * Reported traffic increases from ISPs and internet exchange points | * Reported traffic increases from ISPs and Internet Exchange Points | |||
| (IXP) over just a few weeks were as big as the traffic growth over | (IXP) over just a few weeks were as big as the traffic growth over | |||
| the course of a typical year, representing a 15-20% surge in | the course of a typical year, representing a 15-20% surge in | |||
| growth to land at a new normal that was much higher than | growth to land at a new normal that was much higher than | |||
| anticipated. | anticipated. | |||
| * At DE-CIX Frankfurt, the world's largest Internet Exchange Point | * At DE-CIX Frankfurt, the world's largest Internet Exchange Point | |||
| in terms of data throughput, the year 2020 has seen the largest | in terms of data throughput, the year 2020 has seen the largest | |||
| increase in peak traffic within a single year since the IXP was | increase in peak traffic within a single year since the IXP was | |||
| founded in 1995. | founded in 1995. | |||
| skipping to change at page 14, line 18 ¶ | skipping to change at page 13, line 45 ¶ | |||
| children at school. One might expect that the peak would have had | children at school. One might expect that the peak would have had | |||
| more impact on networks if it had happened during typical evening | more impact on networks if it had happened during typical evening | |||
| peak hours for video streaming applications. | peak hours for video streaming applications. | |||
| * The increase in daytime bandwidth consumption reflected both | * The increase in daytime bandwidth consumption reflected both | |||
| significant increases in "essential" applications such as | significant increases in "essential" applications such as | |||
| videoconferencing and virtual private networks (VPN), and | videoconferencing and virtual private networks (VPN), and | |||
| entertainment applications as people watched videos or played | entertainment applications as people watched videos or played | |||
| games. | games. | |||
| * At the IXP-level, it was observed that port utilization increased. | * At the IXP level, it was observed that physical link utilization | |||
| This phenomenon is mostly explained by a higher traffic demand | increased. This phenomenon could probably be explained by a | |||
| from residential users. | higher level of uncacheable traffic such as videoconferencing and | |||
| VPNs from residential users as they stopped commuting and switched | ||||
| to work-at-home. | ||||
| 4. Latency Considerations | 4. Latency Considerations | |||
| Streaming media latency refers to the "glass-to-glass" time duration, | Streaming media latency refers to the "glass-to-glass" time duration, | |||
| which is the delay between the real-life occurrence of an event and | which is the delay between the real-life occurrence of an event and | |||
| the streamed media being appropriately displayed on an end user's | the streamed media being appropriately displayed on an end user's | |||
| device. Note that this is different from the network latency | device. Note that this is different from the network latency | |||
| (defined as the time for a packet to cross a network from one end to | (defined as the time for a packet to cross a network from one end to | |||
| another end) because it includes video encoding/decoding and | another end) because it includes video encoding/decoding and | |||
| buffering time, and for most cases also ingest to an intermediate | buffering time, and for most cases also ingest to an intermediate | |||
| skipping to change at page 19, line 5 ¶ | skipping to change at page 18, line 31 ¶ | |||
| 5.3. Adaptive Segmented Delivery | 5.3. Adaptive Segmented Delivery | |||
| ABR playback is commonly implemented by streaming clients using HLS | ABR playback is commonly implemented by streaming clients using HLS | |||
| [RFC8216] or DASH [MPEG-DASH] to perform a reliable segmented | [RFC8216] or DASH [MPEG-DASH] to perform a reliable segmented | |||
| delivery of media over HTTP. Different implementations use different | delivery of media over HTTP. Different implementations use different | |||
| strategies [ABRSurvey], often relying on proprietary algorithms | strategies [ABRSurvey], often relying on proprietary algorithms | |||
| (called rate adaptation or bitrate selection algorithms) to perform | (called rate adaptation or bitrate selection algorithms) to perform | |||
| available bandwidth estimation/prediction and the bitrate selection. | available bandwidth estimation/prediction and the bitrate selection. | |||
| Many server-player systems will do an initial probe or a very simple | Many systems will do an initial probe or a very simple throughput | |||
| throughput speed test at the start of a video playback. This is done | speed test at the start of a video playback. This is done to get a | |||
| to get a rough sense of the highest video bitrate in the ABR ladder | rough sense of the highest video bitrate in the ABR ladder that the | |||
| that the network between the server and player will likely be able to | network between the server and player will likely be able to provide | |||
| provide under initial network conditions. After the initial testing, | under initial network conditions. After the initial testing, clients | |||
| clients tend to rely upon passive network observations and will make | tend to rely upon passive network observations and will make use of | |||
| use of player side statistics such as buffer fill rates to monitor | player side statistics such as buffer fill rates to monitor and | |||
| and respond to changing network conditions. | respond to changing network conditions. | |||
| The choice of bitrate occurs within the context of optimizing for | The choice of bitrate occurs within the context of optimizing for one | |||
| some metric monitored by the client, such as highest achievable video | or more metrics monitored by the client, such as highest achievable | |||
| quality or lowest chances for a rebuffering event (playback stall). | video quality or lowest chances for a rebuffering event (playback | |||
| stall). | ||||
| 5.4. Advertising | 5.4. Advertising | |||
| A variety of business models exist for producers of streaming media. | A variety of business models exist for producers of streaming media. | |||
| Some content providers derive the majority of the revenue associated | Some content providers derive the majority of the revenue associated | |||
| with streaming media directly from consumer subscriptions or one-time | with streaming media directly from consumer subscriptions or one-time | |||
| purchases. Others derive the majority of their streaming media | purchases. Others derive the majority of their streaming media | |||
| associated revenue from advertising. Many content providers derive | associated revenue from advertising. Many content providers derive | |||
| income from a mix of these and other sources of funding. The | income from a mix of these and other sources of funding. The | |||
| inclusion of advertising alongside or interspersed with streaming | inclusion of advertising alongside or interspersed with streaming | |||
| skipping to change at page 21, line 8 ¶ | skipping to change at page 20, line 32 ¶ | |||
| In general this is a rapidly developing space with many | In general this is a rapidly developing space with many | |||
| considerations, and media streaming operators engaged in advertising | considerations, and media streaming operators engaged in advertising | |||
| may need to research these and other concerns to find solutions that | may need to research these and other concerns to find solutions that | |||
| meet their user experience, user privacy, and financial goals. For | meet their user experience, user privacy, and financial goals. For | |||
| further reading on mitigations, [BAP] has published some standards | further reading on mitigations, [BAP] has published some standards | |||
| and best practices based on user experience research. | and best practices based on user experience research. | |||
| 5.5. Bitrate Detection Challenges | 5.5. Bitrate Detection Challenges | |||
| This kind of bandwidth-measurement system can experience trouble in | This kind of bandwidth-measurement system can experience trouble in | |||
| several ways that are affected by networking issues. Because | several ways that are affected by networking and transport protocol | |||
| adaptive application-level response strategies are often using rates | issues. Because adaptive application-level response strategies are | |||
| as observed by the application layer, there are sometimes inscrutable | often using rates as observed by the application layer, there are | |||
| transport-level protocol behaviors that can produce surprising | sometimes inscrutable transport-level protocol behaviors that can | |||
| measurement values when the application-level feedback loop is | produce surprising measurement values when the application-level | |||
| interacting with a transport-level feedback loop. | feedback loop is interacting with a transport-level feedback loop. | |||
| A few specific examples of surprising phenomena that affect bitrate | A few specific examples of surprising phenomena that affect bitrate | |||
| detection measurements are described in the following subsections. | detection measurements are described in the following subsections. | |||
| As these examples will demonstrate, it is common to encounter cases | As these examples will demonstrate, it is common to encounter cases | |||
| that can deliver application level measurements that are too low, too | that can deliver application level measurements that are too low, too | |||
| high, and (possibly) correct but varying more quickly than a lab- | high, and (possibly) correct but varying more quickly than a lab- | |||
| tested selection algorithm might expect. | tested selection algorithm might expect. | |||
| These effects and others that cause transport behavior to diverge | These effects and others that cause transport behavior to diverge | |||
| from lab modeling can sometimes have a significant impact on bitrate | from lab modeling can sometimes have a significant impact on bitrate | |||
| selection and on user quality of experience, especially where players | selection and on user QOE, especially where players use naive | |||
| use naive measurement strategies and selection algorithms that don't | measurement strategies and selection algorithms that don't account | |||
| account for the likelihood of bandwidth measurements that diverge | for the likelihood of bandwidth measurements that diverge from the | |||
| from the true path capacity. | true path capacity. | |||
| 5.5.1. Idle Time between Segments | 5.5.1. Idle Time between Segments | |||
| When the bitrate selection is chosen substantially below the | When the bitrate selection is chosen substantially below the | |||
| available capacity of the network path, the response to a segment | available capacity of the network path, the response to a segment | |||
| request will typically complete in much less absolute time than the | request will typically complete in much less absolute time than the | |||
| duration of the requested segment, leaving significant idle time | duration of the requested segment, leaving significant idle time | |||
| between segment downloads. This can have a few surprising | between segment downloads. This can have a few surprising | |||
| consequences: | consequences: | |||
| skipping to change at page 23, line 14 ¶ | skipping to change at page 22, line 36 ¶ | |||
| throughput degradation of more than a factor of 2 while active | throughput degradation of more than a factor of 2 while active | |||
| [Micro]. 5G and LTE likewise can easily see rate variation by a | [Micro]. 5G and LTE likewise can easily see rate variation by a | |||
| factor of 2 or more over a span of seconds as users move around. | factor of 2 or more over a span of seconds as users move around. | |||
| These swings in actual transport capacity can result in user | These swings in actual transport capacity can result in user | |||
| experience issues that can be exacerbated by insufficiently | experience issues that can be exacerbated by insufficiently | |||
| responsive ABR algorithms. | responsive ABR algorithms. | |||
| 5.6. Measurement Collection | 5.6. Measurement Collection | |||
| In addition to measurements media players use to guide their segment- | Media players use measurements to guide their segment-by-segment | |||
| by-segment adaptive streaming requests, streaming media providers may | adaptive streaming requests, but may also provide measurements to | |||
| also rely on measurements collected from media players to provide | streaming media providers. | |||
| analytics that can be used for decisions such as whether the adaptive | ||||
| encoding bitrates in use are the best ones to provide to media | ||||
| players, or whether current media content caching is providing the | ||||
| best experience for viewers. To that effect, the Consumer Technology | ||||
| Association (CTA) who owns the Web Application Video Ecosystem (WAVE) | ||||
| project has published two important specifications. | ||||
| 5.6.1. CTA-2066: Streaming Quality of Experience Events, Properties and | In turn, providers may base analytics on these measurements, to guide | |||
| Metrics | decisions such as whether adaptive encoding bitrates in use are the | |||
| best ones to provide to media players, or whether current media | ||||
| content caching is providing the best experience for viewers. | ||||
| [CTA-2066] specifies a set of media player events, properties, | To that effect, the Consumer Technology Association (CTA) who owns | |||
| quality of experience (QoE) metrics and associated terminology for | the Web Application Video Ecosystem (WAVE) project has published two | |||
| representing streaming media quality of experience across systems, | important specifications. | |||
| media players and analytics vendors. While all these events, | ||||
| properties, metrics and associated terminology is used across a | * CTA-2066: Streaming Quality of Experience Events, Properties and | |||
| number of proprietary analytics and measurement solutions, they were | Metrics | |||
| used in slightly (or vastly) different ways that led to | ||||
| [CTA-2066] specifies a set of media player events, properties, QOE | ||||
| metrics and associated terminology for representing streaming media | ||||
| QOE across systems, media players and analytics vendors. While all | ||||
| these events, properties, metrics and associated terminology is used | ||||
| across a number of proprietary analytics and measurement solutions, | ||||
| they were used in slightly (or vastly) different ways that led to | ||||
| interoperability issues. CTA-2066 attempts to address this issue by | interoperability issues. CTA-2066 attempts to address this issue by | |||
| defining a common terminology as well as how each metric should be | defining a common terminology as well as how each metric should be | |||
| computed for consistent reporting. | computed for consistent reporting. | |||
| 5.6.2. CTA-5004: Common Media Client Data (CMCD) | * CTA-5004: Common Media Client Data (CMCD) | |||
| Many assume that the CDNs have a holistic view into the health and | Many assume that the CDNs have a holistic view into the health and | |||
| performance of the streaming clients. However, this is not the case. | performance of the streaming clients. However, this is not the case. | |||
| The CDNs produce millions of log lines per second across hundreds of | The CDNs produce millions of log lines per second across hundreds of | |||
| thousands of clients and they have no concept of a "session" as a | thousands of clients and they have no concept of a "session" as a | |||
| client would have, so CDNs are decoupled from the metrics the clients | client would have, so CDNs are decoupled from the metrics the clients | |||
| generate and report. A CDN cannot tell which request belongs to | generate and report. A CDN cannot tell which request belongs to | |||
| which playback session, the duration of any media object, the | which playback session, the duration of any media object, the | |||
| bitrate, or whether any of the clients have stalled and are | bitrate, or whether any of the clients have stalled and are | |||
| rebuffering or are about to stall and will rebuffer. The consequence | rebuffering or are about to stall and will rebuffer. The consequence | |||
| of this decoupling is that a CDN cannot prioritize delivery for when | of this decoupling is that a CDN cannot prioritize delivery for when | |||
| the client needs it most, prefetch content, or trigger alerts when | the client needs it most, prefetch content, or trigger alerts when | |||
| the network itself may be underperforming. One approach to couple | the network itself may be underperforming. One approach to couple | |||
| the CDN to the playback sessions is for the clients to communicate | the CDN to the playback sessions is for the clients to communicate | |||
| standardized media-relevant information to the CDNs while they are | standardized media-relevant information to the CDNs while they are | |||
| fetching data. [CTA-5004] was developed exactly for this purpose. | fetching data. [CTA-5004] was developed exactly for this purpose. | |||
| 5.7. Unreliable Transport | ||||
| In contrast to segmented delivery, several applications use | ||||
| unreliable UDP or SCTP with its "partial reliability" extension | ||||
| [RFC3758] to deliver Media encapsulated in RTP [RFC3550] or raw MPEG | ||||
| Transport Stream ("MPEG-TS")-formatted video [MPEG-TS], when the | ||||
| media is being delivered in situations such as broadcast and live | ||||
| streaming, that better tolerate occasional packet loss without | ||||
| retransmission. | ||||
| Under congestion and loss, this approach generally experiences more | ||||
| video artifacts with fewer delay or head-of-line blocking effects. | ||||
| Often one of the key goals is to reduce latency, to better support | ||||
| applications like videoconferencing, or for other live-action video | ||||
| with interactive components, such as some sporting events. | ||||
| The Secure Reliable Transport protocol [SRT] also uses UDP in an | ||||
| effort to achieve lower latency for streaming media, although it adds | ||||
| reliability at the application layer. | ||||
| Congestion avoidance strategies for deployments using unreliable | ||||
| transport protocols vary widely in practice, ranging from being | ||||
| entirely unresponsive to congestion, to using feedback signaling to | ||||
| change encoder settings (as in [RFC5762]), to using fewer enhancement | ||||
| layers (as in [RFC6190]), to using proprietary methods to detect | ||||
| "quality of experience" issues and turn off video in order to allow | ||||
| less bandwidth-intensive media such as audio to be delivered. | ||||
| More details about congestion avoidance strategies used with | ||||
| unreliable transport protocols are included in Section 6.1. | ||||
| 6. Evolution of Transport Protocols and Transport Protocol Behaviors | 6. Evolution of Transport Protocols and Transport Protocol Behaviors | |||
| Because networking resources are shared between users, a good place | Because networking resources are shared between users, a good place | |||
| to start our discussion is how contention between users, and | to start our discussion is how contention between users, and | |||
| mechanisms to resolve that contention in ways that are "fair" between | mechanisms to resolve that contention in ways that are "fair" between | |||
| users, impact streaming media users. These topics are closely tied | users, impact streaming media users. These topics are closely tied | |||
| to transport protocol behaviors. | to transport protocol behaviors. | |||
| As noted in Section 5, ABR response strategies such as HLS [RFC8216] | As noted in Section 5, ABR response strategies such as HLS [RFC8216] | |||
| or DASH [MPEG-DASH] are attempting to respond to changing path | or DASH [MPEG-DASH] are attempting to respond to changing path | |||
| skipping to change at page 25, line 29 ¶ | skipping to change at page 24, line 21 ¶ | |||
| For most of the history of the Internet, we have trusted UDP-based | For most of the history of the Internet, we have trusted UDP-based | |||
| applications to limit their impact on other users. One of the | applications to limit their impact on other users. One of the | |||
| strategies used was to use UDP for simple query-response application | strategies used was to use UDP for simple query-response application | |||
| protocols, such as DNS, which is often used to send a single-packet | protocols, such as DNS, which is often used to send a single-packet | |||
| request to look up the IP address for a DNS name, and return a | request to look up the IP address for a DNS name, and return a | |||
| single-packet response containing the IP address. Although it is | single-packet response containing the IP address. Although it is | |||
| possible to saturate a path between a DNS client and DNS server with | possible to saturate a path between a DNS client and DNS server with | |||
| DNS requests, in practice, that was rare enough that DNS included few | DNS requests, in practice, that was rare enough that DNS included few | |||
| mechanisms to resolve contention between DNS users and other users | mechanisms to resolve contention between DNS users and other users | |||
| (whether they are also using DNS, or using other application | (whether they are also using DNS, or using other application | |||
| protocols). | protocols that share the same pathways). | |||
| In recent times, the usage of UDP-based applications that were not | In recent times, the usage of UDP-based applications that were not | |||
| simple query-response protocols has grown substantially, and since | simple query-response protocols has grown substantially, and since | |||
| UDP does not provide any feedback mechanism to senders to help limit | UDP does not provide any feedback mechanism to senders to help limit | |||
| impacts on other users, application-level protocols such as RTP | impacts on other users, application-level protocols such as RTP | |||
| [RFC3550] have been responsible for the decisions that TCP-based | [RFC3550] have been responsible for the decisions that TCP-based | |||
| applications have delegated to TCP - what to send, how much to send, | applications have delegated to TCP - what to send, how much to send, | |||
| and when to send it. So, the way some UDP-based applications | and when to send it. Because UDP itself has no transport-layer | |||
| interact with other users has changed. | ||||
| It is also worth pointing out that because UDP has no transport-layer | ||||
| feedback mechanisms, UDP-based applications that send and receive | feedback mechanisms, UDP-based applications that send and receive | |||
| substantial amounts of information are expected to provide their own | substantial amounts of information are expected to provide their own | |||
| feedback mechanisms. This expectation is most recently codified in | feedback mechanisms, and to respond to the feedback the application | |||
| Best Current Practice [RFC8085]. | receives. This expectation is most recently codified in Best Current | |||
| Practice [RFC8085]. | ||||
| In contrast to adaptive segmented delivery over a reliable tansport | ||||
| as described in Section 5.3, some applications deliver streaming | ||||
| media using an unreliable transport, and rely on a variety of | ||||
| approaches, including: | ||||
| * raw MPEG Transport Stream ("MPEG-TS")-formatted video [MPEG-TS] | ||||
| over UDP, which makes no attempt to account for reordering or loss | ||||
| in the transport, | ||||
| * RTP [RFC3550], which can notice loss and repair some limited | ||||
| reordering, | ||||
| * SCTP [RFC4960], which can use partial reliability [RFC3758] to | ||||
| recover from some loss, but can abandon recovery to limit head-of- | ||||
| line blocking, and | ||||
| * SRT [SRT], which can use forward error correction and time-bound | ||||
| retransmission to recover from loss within certain limits, but can | ||||
| abandon recovery to limit head-of-line blocking. | ||||
| Under congestion and loss, approaches like the above generally | ||||
| experiences transient video artifacts more often and delay of | ||||
| playback effects less often, as compared with reliable segment | ||||
| transport. Often one of the key goals of using a UDP-based transport | ||||
| that allows some unreliability is to reduce latency and better | ||||
| support applications like videoconferencing, or for other live-action | ||||
| video with interactive components, such as some sporting events. | ||||
| Congestion avoidance strategies for deployments using unreliable | ||||
| transport protocols vary widely in practice, ranging from being | ||||
| entirely unresponsive to congestion, to using feedback signaling to | ||||
| change encoder settings (as in [RFC5762]), to using fewer enhancement | ||||
| layers (as in [RFC6190]), to using proprietary methods to detect QOE | ||||
| issues and turn off video in order to allow less bandwidth-intensive | ||||
| media such as audio to be delivered. | ||||
| RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own | RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own | |||
| feedback mechanism, and even includes Circuit Breakers for Unicast | feedback mechanism, and even includes Circuit Breakers for Unicast | |||
| RTP Sessions [RFC8083] for situations when normal RTP congestion | RTP Sessions [RFC8083] for situations when normal RTP congestion | |||
| control has not been able to react sufficiently to RTP flows sending | control has not been able to react sufficiently to RTP flows sending | |||
| at rates that result in sustained packet loss. | at rates that result in sustained packet loss. | |||
| The notion of "Circuit Breakers" has also been applied to other UDP | The notion of "Circuit Breakers" has also been applied to other UDP | |||
| applications in [RFC8084], such as tunneling packets over UDP that | applications in [RFC8084], such as tunneling packets over UDP that | |||
| are potentially not congestion-controlled (for example, | are potentially not congestion-controlled (for example, | |||
| skipping to change at page 27, line 10 ¶ | skipping to change at page 26, line 36 ¶ | |||
| Although TCP behavior has changed over time, the common practice of | Although TCP behavior has changed over time, the common practice of | |||
| implementing TCP as part of an operating system kernel has acted to | implementing TCP as part of an operating system kernel has acted to | |||
| limit how quickly TCP behavior can change. Even with the widespread | limit how quickly TCP behavior can change. Even with the widespread | |||
| use of automated operating system update installation on many end- | use of automated operating system update installation on many end- | |||
| user systems, streaming media providers could have a reasonable | user systems, streaming media providers could have a reasonable | |||
| expectation that they could understand TCP transport protocol | expectation that they could understand TCP transport protocol | |||
| behaviors, and that those behaviors would remain relatively stable in | behaviors, and that those behaviors would remain relatively stable in | |||
| the short term. | the short term. | |||
| 6.3. The QUIC Protocol and Its Behavior | 6.3. QUIC and Its Behavior | |||
| The QUIC protocol, developed from a proprietary protocol into an IETF | The QUIC protocol, developed from a proprietary protocol into an IETF | |||
| standards-track protocol [RFC9000], turns many of the statements made | standards-track protocol [RFC9000], turns many of the statements made | |||
| in Section 6.1 and Section 6.2 on their heads. | in Section 6.1 and Section 6.2 on their heads. | |||
| Although QUIC provides an alternative to the TCP and UDP transport | Although QUIC provides an alternative to the TCP and UDP transport | |||
| protocols, QUIC is itself encapsulated in UDP. As noted elsewhere in | protocols, QUIC is itself encapsulated in UDP. As noted elsewhere in | |||
| Section 7.1, the QUIC protocol encrypts almost all of its transport | Section 7.1, the QUIC protocol encrypts almost all of its transport | |||
| parameters, and all of its payload, so any intermediaries that | parameters, and all of its payload, so any intermediaries that | |||
| network operators may be using to troubleshoot HTTP streaming media | network operators may be using to troubleshoot HTTP streaming media | |||
| skipping to change at page 28, line 24 ¶ | skipping to change at page 28, line 5 ¶ | |||
| experience, but in some cases have not responded to sustained packet | experience, but in some cases have not responded to sustained packet | |||
| loss, which exhausts available buffers along the end-to-end path that | loss, which exhausts available buffers along the end-to-end path that | |||
| may affect other users sharing that path. The QUIC protocol provides | may affect other users sharing that path. The QUIC protocol provides | |||
| a set of congestion control hooks that can be used for algorithm | a set of congestion control hooks that can be used for algorithm | |||
| agility, and [RFC9002] defines a basic algorithm with transport | agility, and [RFC9002] defines a basic algorithm with transport | |||
| behavior that is roughly similar to TCP NewReno [RFC6582]. However, | behavior that is roughly similar to TCP NewReno [RFC6582]. However, | |||
| QUIC senders can and do unilaterally choose to use different | QUIC senders can and do unilaterally choose to use different | |||
| algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or | algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or | |||
| BBR, or even something completely different. | BBR, or even something completely different. | |||
| We do have experience with deploying new congestion controllers | The Internet community does have experience with deploying new | |||
| without melting the Internet (CUBIC is one example), but the point | congestion controllers without melting the Internet. As noted in | |||
| mentioned in Section 6.2 about TCP being implemented in operating | [RFC8312], both the CUBIC congestion controller and its predecessor | |||
| system kernels is also different with QUIC. Although QUIC can be | BIC have significantly different behavior from Reno-style congestion | |||
| implemented in operating system kernels, one of the design goals when | controllers such as TCP NewReno [RFC6582], but both CUBIC and BIC | |||
| this work was chartered was "QUIC is expected to support rapid, | were added to the Linux kernel in order to allow experimentation and | |||
| distributed development and testing of features", and to meet this | analysis, and both were then selected as the default TCP congestion | |||
| expectation, many implementers have chosen to implement QUIC in user | controllers in Linux, and both were deployed globally. | |||
| space, outside the operating system kernel, and to even distribute | ||||
| QUIC libraries with their own applications. | ||||
| The decision to deploy a new version of QUIC is relatively | The point mentioned in Section 6.2 about TCP congestion controllers | |||
| uncontrolled, compared to other widely used transport protocols, and | being implemented in operating system kernels is different with QUIC. | |||
| this can include new transport behaviors that appear without much | Although QUIC can be implemented in operating system kernels, one of | |||
| notice except to the QUIC endpoints. At IETF 105, Christian Huitema | the design goals when this work was chartered was "QUIC is expected | |||
| and Brian Trammell presented a talk on "Congestion Defense in Depth" | to support rapid, distributed development and testing of features", | |||
| [CDiD], that explored potential concerns about new QUIC congestion | and to meet this expectation, many implementers have chosen to | |||
| controllers being broadly deployed without the testing and | implement QUIC in user space, outside the operating system kernel, | |||
| instrumentation that current major content providers routinely | and to even distribute QUIC libraries with their own applications. | |||
| include. The sense of the room at IETF 105 was that the current | It is worth noting that streaming operators using HTTP/3, carried | |||
| major content providers understood what is at stake when they deploy | over QUIC, can expect more frequent deployment of new congestion | |||
| new congestion controllers, but this presentation, and the related | controller behavior than has been the case with HTTP/1 and HTTP/2, | |||
| discussion in TSVAREA minutes from IETF 105 ([tsvarea-105], are still | carried over TCP. | |||
| worth a look for new and rapidly growing content providers. | ||||
| It is worth considering that if TCP-based HTTP traffic and UDP-based | It is worth considering that if TCP-based HTTP traffic and UDP-based | |||
| HTTP/3 traffic are allowed to enter operator networks on roughly | HTTP/3 traffic are allowed to enter operator networks on roughly | |||
| equal terms, questions of fairness and contention will be heavily | equal terms, questions of fairness and contention will be heavily | |||
| dependent on interactions between the congestion controllers in use | dependent on interactions between the congestion controllers in use | |||
| for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. | for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. | |||
| More broadly, [I-D.ietf-quic-manageability] discusses manageability | ||||
| of the QUIC transport protocol, focusing on the implications of | ||||
| QUIC's design and wire image on network operations involving QUIC | ||||
| traffic. It discusses what network operators can consider in some | ||||
| detail. | ||||
| 7. Streaming Encrypted Media | 7. Streaming Encrypted Media | |||
| "Encrypted Media" has at least three meanings: | "Encrypted Media" has at least three meanings: | |||
| * Media encrypted at the application layer, typically using some | * Media encrypted at the application layer, typically using some | |||
| sort of Digital Rights Management (DRM) system, and typically | sort of Digital Rights Management (DRM) system, and typically | |||
| remaining encrypted "at rest", when senders and receivers store | remaining encrypted "at rest", when senders and receivers store | |||
| it. | it. | |||
| * Media encrypted by the sender at the transport layer, and | * Media encrypted by the sender at the transport layer, and | |||
| skipping to change at page 29, line 38 ¶ | skipping to change at page 29, line 5 ¶ | |||
| (in this document, referred to as "end-to-end media encryption"). | (in this document, referred to as "end-to-end media encryption"). | |||
| * Media encrypted by the sender at the transport layer, and | * Media encrypted by the sender at the transport layer, and | |||
| remaining encrypted until it reaches some intermediary that is | remaining encrypted until it reaches some intermediary that is | |||
| _not_ the ultimate media consumer, but has credentials allowing | _not_ the ultimate media consumer, but has credentials allowing | |||
| decryption of the media content. This intermediary may examine | decryption of the media content. This intermediary may examine | |||
| and even transform the media content in some way, before | and even transform the media content in some way, before | |||
| forwarding re-encrypted media content (in this document referred | forwarding re-encrypted media content (in this document referred | |||
| to as "hop-by-hop media encryption"). | to as "hop-by-hop media encryption"). | |||
| Both "hop-by-hop" and "end-to-end" encrypted transport may carry | In this document, we will focus on media encrypted at the transport | |||
| media that is, in addition, encrypted at the application layer. | layer, whether encrypted "hop-by-hop" or "end-to-end". Because media | |||
| encrypted at the application layer will only be processed by | ||||
| application-level entities, this encryption does not have transport- | ||||
| layer implications. Of course, both "hop-by-hop" and "end-to-end" | ||||
| encrypted transport may carry media that is, in addition, encrypted | ||||
| at the application layer. | ||||
| Each of these encryption strategies is intended to achieve a | Each of these encryption strategies is intended to achieve a | |||
| different goal. For instance, application-level encryption may be | different goal. For instance, application-level encryption may be | |||
| used for business purposes, such as avoiding piracy or enforcing | used for business purposes, such as avoiding piracy or enforcing | |||
| geographic restrictions on playback, while transport-layer encryption | geographic restrictions on playback, while transport-layer encryption | |||
| may be used to prevent media steam manipulation or to protect | may be used to prevent media steam manipulation or to protect | |||
| manifests. | manifests. | |||
| This document does not take a position on whether those goals are | This document does not take a position on whether those goals are | |||
| "valid" (whatever that might mean). | "valid" (whatever that might mean). | |||
| In this document, we will focus on media encrypted at the transport | Both "end-to-end" and "hop-by-hop" media encryption have specific | |||
| layer, whether encrypted "hop-by-hop" or "end-to-end". Because media | ||||
| encrypted at the application layer will only be processed by | ||||
| application-level entities, this encryption does not have transport- | ||||
| layer implications. | ||||
| Both "End-to-End" and "Hop-by-Hop" media encryption have specific | ||||
| implications for streaming operators. These are described in | implications for streaming operators. These are described in | |||
| Section 7.2 and Section 7.3. | Section 7.2 and Section 7.3. | |||
| 7.1. General Considerations for Media Encryption | 7.1. General Considerations for Media Encryption | |||
| The use of strong encryption does provide confidentiality for | The use of strong encryption does provide confidentiality for | |||
| encrypted streaming media, from the sender to either an intermediary | encrypted streaming media, from the sender to either an intermediary | |||
| or the ultimate media consumer, and this does prevent Deep Packet | or the ultimate media consumer, and this does prevent Deep Packet | |||
| Inspection by any intermediary that does not possess credentials | Inspection by any intermediary that does not possess credentials | |||
| allowing decryption. However, even encrypted content streams may be | allowing decryption. However, even encrypted content streams may be | |||
| skipping to change at page 31, line 5 ¶ | skipping to change at page 30, line 17 ¶ | |||
| handshake [RFC8446] only for key exchange [RFC9001], and encrypts | handshake [RFC8446] only for key exchange [RFC9001], and encrypts | |||
| almost all transport parameters itself, with the exception of a few | almost all transport parameters itself, with the exception of a few | |||
| invariant header fields. In the QUIC short header, the only | invariant header fields. In the QUIC short header, the only | |||
| transport-level parameter which is sent "in the clear" is the | transport-level parameter which is sent "in the clear" is the | |||
| Destination Connection ID [RFC8999], and even in the QUIC long | Destination Connection ID [RFC8999], and even in the QUIC long | |||
| header, the only transport-level parameters sent "in the clear" are | header, the only transport-level parameters sent "in the clear" are | |||
| the Version, Destination Connection ID, and Source Connection ID. | the Version, Destination Connection ID, and Source Connection ID. | |||
| For these reasons, HTTP/3 is significantly more "opaque" than HTTPS | For these reasons, HTTP/3 is significantly more "opaque" than HTTPS | |||
| with HTTP/1 or HTTP/2. | with HTTP/1 or HTTP/2. | |||
| [I-D.ietf-quic-manageability] discusses manageability of the QUIC | ||||
| transport protocol that is used to encapsulate HTTP/3, focusing on | ||||
| the implications of QUIC's design and wire image on network | ||||
| operations involving QUIC traffic. It discusses what network | ||||
| operators can consider in some detail. | ||||
| More broadly, RFC 9065 [RFC9065], "Considerations around Transport | ||||
| Header Confidentiality, Network Operations, and the Evolution of | ||||
| Internet Transport Protocols" describes the impact of increased | ||||
| encryption of transport headers in general terms. | ||||
| 7.2. Considerations for "Hop-by-Hop" Media Encryption | 7.2. Considerations for "Hop-by-Hop" Media Encryption | |||
| Although the IETF has put considerable emphasis on end-to-end | Although the IETF has put considerable emphasis on end-to-end | |||
| streaming media encryption, there are still important use cases that | streaming media encryption, there are still important use cases that | |||
| require the insertion of intermediaries. | require the insertion of intermediaries. | |||
| There are a variety of ways to involve intermediaries, and some are | There are a variety of ways to involve intermediaries, and some are | |||
| much more intrusive than others. | much more intrusive than others. | |||
| From a content provider's perspective, a number of considerations are | From a content provider's perspective, a number of considerations are | |||
| skipping to change at page 32, line 5 ¶ | skipping to change at page 31, line 31 ¶ | |||
| Protocol that provides both hop-by-hop and end-to-end security | Protocol that provides both hop-by-hop and end-to-end security | |||
| guarantees. | guarantees. | |||
| * Secure Media Frames [SFRAME] - [RFC8723] is closely tied to SRTP, | * Secure Media Frames [SFRAME] - [RFC8723] is closely tied to SRTP, | |||
| and this close association impeded widespread deployment, because | and this close association impeded widespread deployment, because | |||
| it could not be used for the most common media content delivery | it could not be used for the most common media content delivery | |||
| mechanisms. A more recent proposal, Secure Media Frames [SFRAME], | mechanisms. A more recent proposal, Secure Media Frames [SFRAME], | |||
| also provides both hop-by-hop and end-to-end security guarantees, | also provides both hop-by-hop and end-to-end security guarantees, | |||
| but can be used with other transport protocols beyond SRTP. | but can be used with other transport protocols beyond SRTP. | |||
| If a content provider chooses not to involve intermediaries, this | The choice of whether to involve intermediaries sometimes requires | |||
| choice should be carefully considered. As an example, if media | careful consideration. As an example, when ABR manifests were | |||
| manifests are encrypted end-to-end, network providers who had been | commonly sent unencrypted some networks would modify manifests during | |||
| able to lower offered quality and reduce on their networks will no | peak hours by removing high-bitrate renditions in order to prevent | |||
| longer be able to do that. Some resources that might inform this | players from choosing those renditions, thus reducing the overall | |||
| consideration are in [RFC8825] (for WebRTC) and | bandwidth consumed for delivering these media streams and thereby | |||
| improving the network load and the user experience for their | ||||
| customers. Now that ubiquitous encryption typically prevents this | ||||
| kind of modification, in order to maintain the same level of network | ||||
| health and user experience across networks whose users would have | ||||
| benefitted from this intervention a media streaming operator | ||||
| sometimes needs to choose between adding intermediaries who are | ||||
| authorized to change the manifests or adding significant extra | ||||
| complexity to their service. | ||||
| Some resources that might inform other similar considerations are | ||||
| further discussed in [RFC8824] (for WebRTC) and | ||||
| [I-D.ietf-quic-manageability] (for HTTP/3 and QUIC). | [I-D.ietf-quic-manageability] (for HTTP/3 and QUIC). | |||
| 7.3. Considerations for "End-to-End" Media Encryption | 7.3. Considerations for "End-to-End" Media Encryption | |||
| "End-to-end" media encryption offers the potential of providing | "End-to-end" media encryption offers the potential of providing | |||
| privacy for streaming media consumers, with the idea being that if an | privacy for streaming media consumers, with the idea being that if an | |||
| unauthorized intermediary can't decrypt streaming media, the | unauthorized intermediary can't decrypt streaming media, the | |||
| intermediary can't use Deep Packet Inspection (DPI) to examine HTTP | intermediary can't use Deep Packet Inspection to examine HTTP request | |||
| request and response headers and identify the media content being | and response headers and identify the media content being streamed. | |||
| streamed. | ||||
| "End-to-end" media encryption has become much more widespread in the | "End-to-end" media encryption has become much more widespread in the | |||
| years since the IETF issued "Pervasive Monitoring Is an Attack" | years since the IETF issued "Pervasive Monitoring Is an Attack" | |||
| [RFC7258] as a Best Current Practice, describing pervasive monitoring | [RFC7258] as a Best Current Practice, describing pervasive monitoring | |||
| as a much greater threat than previously appreciated. After the | as a much greater threat than previously appreciated. After the | |||
| Snowden disclosures, many content providers made the decision to use | Snowden disclosures, many content providers made the decision to use | |||
| HTTPS protection - HTTP over TLS - for most or all content being | HTTPS protection - HTTP over TLS - for most or all content being | |||
| delivered as a routine practice, rather than in exceptional cases for | delivered as a routine practice, rather than in exceptional cases for | |||
| content that was considered "sensitive". | content that was considered "sensitive". | |||
| skipping to change at page 33, line 7 ¶ | skipping to change at page 32, line 41 ¶ | |||
| intercepting packets and examining them without authorization, can | intercepting packets and examining them without authorization, can | |||
| continue these practices. | continue these practices. | |||
| [RFC7258] said that "The IETF will strive to produce specifications | [RFC7258] said that "The IETF will strive to produce specifications | |||
| that mitigate pervasive monitoring attacks", so streaming operators | that mitigate pervasive monitoring attacks", so streaming operators | |||
| should expect the IETF's direction toward preventing unauthorized | should expect the IETF's direction toward preventing unauthorized | |||
| monitoring of IETF protocols to continue for the forseeable future. | monitoring of IETF protocols to continue for the forseeable future. | |||
| 8. Further Reading and References | 8. Further Reading and References | |||
| Editor's note: This section is to be kept in a living document where | The Media Operations community maintains a list of references and | |||
| future references, links and/or updates to the existing references | resources for further reading at this location: | |||
| will be reflected. That living document is likely to be an IETF- | ||||
| owned Wiki: https://tinyurl.com/streaming-opcons-reading | ||||
| 8.1. Industry Terminology | ||||
| * SVA Glossary: https://glossary.streamingvideoalliance.org/ | ||||
| * Datazoom Video Player Data Dictionary: | ||||
| https://help.datazoom.io/hc/en-us/articles/360031323311 | ||||
| * Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/ | ||||
| en-us/articles/360046177191 | ||||
| 8.2. Surveys and Tutorials | ||||
| 8.2.1. Encoding | ||||
| The following papers describe how video is encoded, different video | ||||
| encoding standards and tradeoffs in selecting encoding parameters. | ||||
| * Overview of the Versatile Video Coding (VVC) Standard and its | ||||
| Applications (https://ieeexplore.ieee.org/document/9503377) | ||||
| * Video Compression - From Concepts to the H.264/AVC Standard | ||||
| (https://ieeexplore.ieee.org/document/1369695) | ||||
| * Developments in International Video Coding Standardization After | ||||
| AVC, With an Overview of Versatile Video Coding (VVC) | ||||
| (https://ieeexplore.ieee.org/document/9328514) | ||||
| * A Technical Overview of AV1 (https://ieeexplore.ieee.org/ | ||||
| document/9363937) | ||||
| * CTU Depth Decision Algorithms for HEVC: A Survey | ||||
| (https://arxiv.org/abs/2104.08328) | ||||
| 8.2.2. Packaging | ||||
| The following papers summarize the methods for selecting packaging | ||||
| configurations such as the resolution-bitrate pairs, segment | ||||
| durations, use of constant vs. variable-duration segments, etc. | ||||
| * Deep Reinforced Bitrate Ladders for Adaptive Video Streaming | ||||
| (https://dl.acm.org/doi/10.1145/3458306.3458873) | ||||
| * Comparing Fixed and Variable Segment Durations for Adaptive Video | ||||
| Streaming: a Holistic Analysis (https://dl.acm.org/ | ||||
| doi/10.1145/3339825.3391858) | ||||
| 8.2.3. Content Delivery | ||||
| The following links describe some of the issues and solutions | ||||
| regarding the interconnecting of the content delivery networks. | ||||
| * Open Caching: Open standards for Caching in ISP Networks: | ||||
| https://www.streamingvideoalliance.org/working-group/open-caching/ | ||||
| * Netflix Open Connect: https://openconnect.netflix.com | ||||
| 8.2.4. ABR Algorithms | ||||
| The two surveys describe and compare different rate-adaptation | ||||
| algorithms in terms of different metrics like achieved bitrate/ | ||||
| quality, stall rate/duration, bitrate switching frequency, fairness, | ||||
| network utilization, etc. | ||||
| * A Survey on Bitrate Adaptation Schemes for Streaming Media Over | ||||
| HTTP (https://ieeexplore.ieee.org/document/8424813) | ||||
| * A Survey of Rate Adaptation Techniques for Dynamic Adaptive | ||||
| Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970) | ||||
| 8.2.5. Low-Latency Live Adaptive Streaming | ||||
| The following papers describe the peculiarities of adaptive streaming | ||||
| in low-latency live streaming scenarios. | ||||
| * Catching the Moment with LoL+ in Twitch-like Low-latency Live | ||||
| Streaming Platforms (https://ieeexplore.ieee.org/document/9429986) | ||||
| * Data-driven Bandwidth Prediction Models and Automated Model | ||||
| Selection for Low Latency (https://ieeexplore.ieee.org/ | ||||
| document/9154522) | ||||
| * Performance Analysis of ACTE: A Bandwidth Prediction Method for | ||||
| Low-latency Chunked Streaming (https://dl.acm.org/ | ||||
| doi/10.1145/3387921) | ||||
| * Online Learning for Low-latency Adaptive Streaming | ||||
| (https://dl.acm.org/doi/10.1145/3339825.3397042) | ||||
| * Tightrope Walking in Low-latency Live Streaming: Optimal Joint | ||||
| Adaptation of Video Rate and Playback Speed (https://dl.acm.org/ | ||||
| doi/10.1145/3458305.3463382) | ||||
| * Content-aware Playback Speed Control for Low-latency Live | ||||
| Streaming of Sports (https://dl.acm.org/ | ||||
| doi/10.1145/3458305.3478437) | ||||
| 8.2.6. Server/Client/Network Collaboration | ||||
| The following papers explain the benefits of server and network | ||||
| assistance in client-driven streaming systems. There is also a good | ||||
| reference about how congestion affects video quality and how rate | ||||
| control works in streaming applications. | ||||
| * Manus Manum Lavat: Media Clients and Servers Cooperating with | ||||
| Common Media Client/Server Data (https://dl.acm.org/ | ||||
| doi/10.1145/3472305.3472886) | ||||
| * Common media client data (CMCD): initial findings | ||||
| (https://dl.acm.org/doi/10.1145/3458306.3461444) | ||||
| * SDNDASH: Improving QoE of HTTP Adaptive Streaming Using Software | ||||
| Defined Networking (https://dl.acm.org/ | ||||
| doi/10.1145/2964284.2964332) | ||||
| * Caching in HTTP Adaptive Streaming: Friend or Foe? | ||||
| (https://dl.acm.org/doi/10.1145/2578260.2578270) | ||||
| * A Survey on Multi-Access Edge Computing Applied to Video | ||||
| Streaming: Some Research Issues and Challenges | ||||
| (https://ieeexplore.ieee.org/document/9374553) | ||||
| * The Ultimate Guide to Internet Congestion Control | ||||
| (https://www.compiralabs.com/ultimate-guide-congestion-control) | ||||
| 8.2.7. QoE Metrics | ||||
| The following papers describe various QoE metrics one can use in | ||||
| streaming applications. | ||||
| * QoE Management of Multimedia Streaming Services in Future | ||||
| Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/ | ||||
| document/8930519) | ||||
| * A Survey on Quality of Experience of HTTP Adaptive Streaming | ||||
| (https://ieeexplore.ieee.org/document/6913491) | ||||
| * QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open | ||||
| Challenges (https://ieeexplore.ieee.org/document/8666971) | ||||
| 8.2.8. Point Clouds and Immersive Media | ||||
| The following papers explain the latest developments in the immersive | ||||
| media domain (for video and audio) and the developing standards for | ||||
| such media. | ||||
| * A Survey on Adaptive 360o Video Streaming: Solutions, Challenges | ||||
| and Opportunities (https://ieeexplore.ieee.org/document/9133103) | ||||
| * MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/ | ||||
| document/9374648) | ||||
| * Emerging MPEG Standards for Point Cloud Compression | ||||
| (https://ieeexplore.ieee.org/document/8571288) | ||||
| * Compression of Sparse and Dense Dynamic Point Clouds--Methods and | ||||
| Standards (https://ieeexplore.ieee.org/document/9457097) | ||||
| * MPEG Standards for Compressed Representation of Immersive Audio | ||||
| (https://ieeexplore.ieee.org/document/9444109) | ||||
| * An Overview of Omnidirectional MediA Format (OMAF) | ||||
| (https://ieeexplore.ieee.org/document/9380215) | ||||
| * From Capturing to Rendering: Volumetric Media Delivery with Six | ||||
| Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522) | ||||
| 8.3. Open-Source Tools | ||||
| * 5G-MA: https://www.5g-mag.com/reference-tools | ||||
| * dash.js: http://reference.dashif.org/dash.js/latest/samples/ | ||||
| * DASH-IF Conformance: https://conformance.dashif.org | ||||
| * ExoPlayer: https://github.com/google/ExoPlayer | ||||
| * FFmpeg: https://www.ffmpeg.org/ | ||||
| * GPAC: https://gpac.wp.imt.fr/ | ||||
| * hls.js: https://github.com/video-dev/hls.js | ||||
| * OBS Studio: https://obsproject.com/ | ||||
| * Shaka Player: https://github.com/google/shaka-player | ||||
| * Shaka Packager: https://github.com/google/shaka-packager | ||||
| * Traffic Control CDN: https://trafficcontrol.apache.org/ | ||||
| * VideoLAN: https://www.videolan.org/projects/ | ||||
| * video.js: https://github.com/videojs/video.js | ||||
| 8.4. Technical Events | ||||
| * ACM Mile High Video (MHV): https://mile-high.video/ | ||||
| * ACM Multimedia Systems (MMSys): https://acmmmsys.org | ||||
| * ACM Multimedia (MM): https://acmmm.org | ||||
| * ACM NOSSDAV: https://www.nossdav.org/ | ||||
| * ACM Packet Video: https://packet.video/ | ||||
| * Demuxed and meetups: https://demuxed.com/ and https://demuxed.com/ | ||||
| events/ | ||||
| * DVB World: https://www.dvbworld.org | ||||
| * EBU BroadThinking: https://tech.ebu.ch/events/broadthinking2021 | ||||
| * IBC Conference: https://show.ibc.org/conference/ibc-conference | ||||
| * IEEE Int. Conf. on Multimedia and Expo (ICME) | ||||
| * Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws | ||||
| * Live Video Stack: https://sh2021.livevideostack.com | ||||
| * Picture Coding Symp. (PCS) | ||||
| * SCTE Expo: https://expo.scte.org/ | ||||
| 8.5. List of Organizations Working on Streaming Media | ||||
| * 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/ | ||||
| sa4-codec | ||||
| * 5G-MAG: https://www.5g-mag.com/ | ||||
| * AOM: http://aomedia.org/ | ||||
| * ATSC: https://www.atsc.org/ | ||||
| * CTA WAVE: https://cta.tech/Resources/Standards/WAVE-Project | ||||
| * DASH Industry Forum: https://dashif.org/ | ||||
| * DVB: https://dvb.org/ | ||||
| * HbbTV: https://www.hbbtv.org/ | ||||
| * HESP Alliance: https://www.hespalliance.org/ | ||||
| * IAB: https://www.iab.com/ | ||||
| * MPEG: https://www.mpegstandards.org/ | ||||
| * Streaming Video Alliance: https://www.streamingvideoalliance.org/ | ||||
| * SCTE: https://www.scte.org/ | ||||
| * SMPTE: https://www.smpte.org/ | ||||
| * SRT Alliance: https://www.srtalliance.org/ | ||||
| * Video Services Forum: https://vsf.tv/ | ||||
| * VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx | ||||
| * W3C: https://www.w3.org/ | ||||
| 8.6. Topics to Keep an Eye on | ||||
| 8.6.1. 5G and Media | ||||
| 5G new radio and systems technologies provide new functionalities for | ||||
| video distribution. 5G targets not only smartphones, but also new | ||||
| devices such as augmented reality glasses or automotive receivers. | ||||
| Higher bandwidth, lower latencies, edge and cloud computing | ||||
| functionalities, service-based architectures, low power consumption, | ||||
| broadcast/multicast functionalities and other network functions come | ||||
| hand in hand with new media formats and processing capabilities | ||||
| promising better and more consistent quality for traditional video | ||||
| streaming services as well as enabling new experiences such as | ||||
| immersive media and augmented realities. | ||||
| * 5G Multimedia Standardization (https://www.riverpublishers.com/ | ||||
| journal_read_html_article.php?j=JICTS/6/1/8) | ||||
| 8.6.2. Ad Insertion | ||||
| Ads can be inserted at different stages in the streaming workflow, on | ||||
| the server side or client side. The DASH-IF guidelines detail | ||||
| server-side ad-insertion with period replacements based on | ||||
| manipulating the manifest. HLS interstitials provide a similar | ||||
| approach. The idea is that the manifest can be changed and point to | ||||
| a sub-playlist of segments, possibly located on a different location. | ||||
| This approach results in efficient resource usage in the network, as | ||||
| duplicate caching is avoided, but some intelligence at the player is | ||||
| needed to deal with content transitions (e.g., codec changes, | ||||
| timeline gaps, etc.). Player support for such content is gradually | ||||
| maturing. Other important technologies for ad insertion include | ||||
| signalling of ads and breaks that is still typically based on SCTE-35 | ||||
| for HLS and SCTE-214 for DASH. Such signals provide useful | ||||
| information for scheduling the ads and contacting ad servers. The | ||||
| usage of SCTE-35 for ad insertion is popular in the broadcast | ||||
| industry, while the exact usage in the OTT space is still being | ||||
| discussed in SCTE. Another important technology is identification of | ||||
| ads, such as based on ad-id or other commercial entities that provide | ||||
| such services. The identification of the ad in a manifest or stream | ||||
| is usually standardized by SMPTE. Other key technologies for ad | ||||
| insertion include tracking of viewer impressions, usually based on | ||||
| Video Ad Serving Template (VAST) defined by IAB. | ||||
| * DASH-IF Ad Insertion Guidelines: https://dashif.org/docs/CR-Ad- | ||||
| Insertion-r7.pdf | ||||
| * SCTE-214-1: https://www.scte.org/standards-development/library/ | ||||
| standards-catalog/ansiscte-214-1-2016/ | ||||
| * RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital | ||||
| Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/ | ||||
| document/7291518 | ||||
| * IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio- | ||||
| video/tech-lab-digital-video-suite/ | ||||
| 8.6.3. Contribution and Ingest | ||||
| There are different contribution and ingest specifications dealing | ||||
| with different use cases. A common case is contribution that | ||||
| previously happened over satellite to a broadcast or streaming | ||||
| headend. RIST and SRT are examples of such contribution protocols. | ||||
| Within a streaming headend the encoder and packager/CDN may have an | ||||
| ingest/contribution interface as well. This is specified by the | ||||
| DASH-IF Ingest. | ||||
| * DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest | ||||
| * RIST: https://www.rist.tv/ | ||||
| * SRT: https://github.com/Haivision/srt | ||||
| 8.6.4. Synchronized Encoding and Packaging | ||||
| Practical streaming headends need redundant encoders and packagers to | ||||
| operate without glitches and blackouts. The redundant operation | ||||
| requires synchronization between two or more encoders and also | ||||
| between two or more packagers that possibly handle different inputs | ||||
| and outputs, generating compatible inter-changeable output | ||||
| representations. This problem is important for anyone developing a | ||||
| streaming headend at scale, and the synchronization problem is | ||||
| currently under discussion in the wider community. Follow the | ||||
| developments at: https://sites.google.com/view/encodersyncworkshop/ | ||||
| home | ||||
| 8.6.5. WebRTC-Based Streaming | ||||
| WebRTC is increasingly being used for streaming of time-sensitive | ||||
| content such as live sporting events. Innovations in cloud computing | ||||
| allow implementers to efficiently scale delivery of content using | ||||
| WebRTC. Support for WebRTC communication is available on all modern | ||||
| web browsers and is available on native clients for all major | ||||
| platforms. | ||||
| * DASH-IF WebRTC Discussions: https://dashif.org/webRTC/ | * https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- | |||
| opcons/blob/main/living-doc-mops-streaming-opcons.md | ||||
| (https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- | ||||
| opcons/blob/main/living-doc-mops-streaming-opcons.md) | ||||
| * Overview of WebRTC: https://webrtc.org/ | Editor's note: The link above might or might not be changed during | |||
| IESG Evaluation. See https://github.com/ietf-wg-mops/draft-ietf- | ||||
| mops-streaming-opcons/issues/114 (https://github.com/ietf-wg-mops/ | ||||
| draft-ietf-mops-streaming-opcons/issues/114) for updates. | ||||
| 9. IANA Considerations | 9. IANA Considerations | |||
| This document requires no actions from IANA. | This document requires no actions from IANA. | |||
| 10. Security Considerations | 10. Security Considerations | |||
| Security is an important matter for streaming media applications and | Security is an important matter for streaming media applications and | |||
| it was briefly touched on in Section 7.1. This document itself | it was briefly touched on in Section 7.1. This document itself | |||
| introduces no new security issues. | introduces no new security issues. | |||
| 11. Acknowledgments | 11. Acknowledgments | |||
| Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, | Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, | |||
| Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, | Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark | |||
| Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, | Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, | |||
| and Will Law for very helpful suggestions, reviews and comments. | Sanjay Mishra, and Will Law for very helpful suggestions, reviews and | |||
| comments. | ||||
| 12. Informative References | 12. Informative References | |||
| [ABRSurvey] | [ABRSurvey] | |||
| Taani, B., Begen, A. C., Timmerer, C., Zimmermann, R., and | Taani, B., Begen, A. C., Timmerer, C., Zimmermann, R., and | |||
| A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes | A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes | |||
| for Streaming Media Over HTTP", IEEE Communications | for Streaming Media Over HTTP", IEEE Communications | |||
| Surveys & Tutorials , 2019, | Surveys & Tutorials , 2019, | |||
| <https://ieeexplore.ieee.org/abstract/document/8424813>. | <https://ieeexplore.ieee.org/abstract/document/8424813>. | |||
| [BAP] "The Coalition for Better Ads", n.d., | [BAP] "The Coalition for Better Ads", n.d., | |||
| <https://www.betterads.org/>. | <https://www.betterads.org/>. | |||
| [CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion | ||||
| Defense in Depth", July 2019, | ||||
| <https://datatracker.ietf.org/meeting/105/materials/ | ||||
| slides-105-tsvarea-congestion-defense-in-depth-00>. | ||||
| [CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked- | [CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked- | |||
| Encoded and Chunked Transferred CMAF", October 2018, | Encoded and Chunked Transferred CMAF", October 2018, | |||
| <https://www.akamai.com/us/en/multimedia/documents/white- | <https://www.akamai.com/us/en/multimedia/documents/white- | |||
| paper/low-latency-streaming-cmaf-whitepaper.pdf>. | paper/low-latency-streaming-cmaf-whitepaper.pdf>. | |||
| [CODASPY17] | [CODASPY17] | |||
| Reed, A. and M. Kranch, "Identifying HTTPS-Protected | Reed, A. and M. Kranch, "Identifying HTTPS-Protected | |||
| Netflix Videos in Real-Time", ACM CODASPY , March 2017, | Netflix Videos in Real-Time", ACM CODASPY , March 2017, | |||
| <https://dl.acm.org/doi/10.1145/3029806.3029821>. | <https://dl.acm.org/doi/10.1145/3029806.3029821>. | |||
| skipping to change at page 42, line 37 ¶ | skipping to change at page 34, line 37 ¶ | |||
| Apple, Inc, "HLS Authoring Specification for Apple | Apple, Inc, "HLS Authoring Specification for Apple | |||
| Devices", June 2020, | Devices", June 2020, | |||
| <https://developer.apple.com/documentation/ | <https://developer.apple.com/documentation/ | |||
| http_live_streaming/ | http_live_streaming/ | |||
| hls_authoring_specification_for_apple_devices>. | hls_authoring_specification_for_apple_devices>. | |||
| [I-D.cardwell-iccrg-bbr-congestion-control] | [I-D.cardwell-iccrg-bbr-congestion-control] | |||
| Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. | Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. | |||
| Jacobson, "BBR Congestion Control", Work in Progress, | Jacobson, "BBR Congestion Control", Work in Progress, | |||
| Internet-Draft, draft-cardwell-iccrg-bbr-congestion- | Internet-Draft, draft-cardwell-iccrg-bbr-congestion- | |||
| control-01, 7 November 2021, | control-02, 7 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-cardwell- | <https://datatracker.ietf.org/doc/html/draft-cardwell- | |||
| iccrg-bbr-congestion-control-01>. | iccrg-bbr-congestion-control-02>. | |||
| [I-D.draft-pantos-hls-rfc8216bis] | [I-D.draft-pantos-hls-rfc8216bis] | |||
| Pantos, R., "HTTP Live Streaming 2nd Edition", Work in | Pantos, R., "HTTP Live Streaming 2nd Edition", Work in | |||
| Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-10, | Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-10, | |||
| 8 November 2021, <https://datatracker.ietf.org/doc/html/ | 8 November 2021, <https://datatracker.ietf.org/doc/html/ | |||
| draft-pantos-hls-rfc8216bis-10>. | draft-pantos-hls-rfc8216bis-10>. | |||
| [I-D.ietf-httpbis-cache] | [I-D.ietf-httpbis-cache] | |||
| Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP | Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP | |||
| Caching", Work in Progress, Internet-Draft, draft-ietf- | Caching", Work in Progress, Internet-Draft, draft-ietf- | |||
| skipping to change at page 43, line 22 ¶ | skipping to change at page 35, line 22 ¶ | |||
| [I-D.ietf-quic-http] | [I-D.ietf-quic-http] | |||
| Bishop, M., "Hypertext Transfer Protocol Version 3 | Bishop, M., "Hypertext Transfer Protocol Version 3 | |||
| (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- | (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- | |||
| quic-http-34, 2 February 2021, | quic-http-34, 2 February 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| http-34>. | http-34>. | |||
| [I-D.ietf-quic-manageability] | [I-D.ietf-quic-manageability] | |||
| Kuehlewind, M. and B. Trammell, "Manageability of the QUIC | Kuehlewind, M. and B. Trammell, "Manageability of the QUIC | |||
| Transport Protocol", Work in Progress, Internet-Draft, | Transport Protocol", Work in Progress, Internet-Draft, | |||
| draft-ietf-quic-manageability-14, 21 January 2022, | draft-ietf-quic-manageability-16, 6 April 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| manageability-14>. | manageability-16>. | |||
| [I-D.ietf-quic-qlog-h3-events] | [I-D.ietf-quic-qlog-h3-events] | |||
| Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK | Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK | |||
| event definitions for qlog", Work in Progress, Internet- | qlog event definitions", Work in Progress, Internet-Draft, | |||
| Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021, | draft-ietf-quic-qlog-h3-events-01, 7 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| qlog-h3-events-00>. | qlog-h3-events-01>. | |||
| [I-D.ietf-quic-qlog-main-schema] | [I-D.ietf-quic-qlog-main-schema] | |||
| Marx, R., Niccolini, L., and M. Seemann, "Main logging | Marx, R., Niccolini, L., and M. Seemann, "Main logging | |||
| schema for qlog", Work in Progress, Internet-Draft, draft- | schema for qlog", Work in Progress, Internet-Draft, draft- | |||
| ietf-quic-qlog-main-schema-01, 25 October 2021, | ietf-quic-qlog-main-schema-02, 7 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| qlog-main-schema-01>. | qlog-main-schema-02>. | |||
| [I-D.ietf-quic-qlog-quic-events] | [I-D.ietf-quic-qlog-quic-events] | |||
| Marx, R., Niccolini, L., and M. Seemann, "QUIC event | Marx, R., Niccolini, L., and M. Seemann, "QUIC event | |||
| definitions for qlog", Work in Progress, Internet-Draft, | definitions for qlog", Work in Progress, Internet-Draft, | |||
| draft-ietf-quic-qlog-quic-events-00, 10 June 2021, | draft-ietf-quic-qlog-quic-events-01, 7 March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| qlog-quic-events-00>. | qlog-quic-events-01>. | |||
| [IAB-ADS] "IAB", n.d., <https://www.iab.com/>. | [IAB-ADS] "IAB", n.d., <https://www.iab.com/>. | |||
| [IABcovid] Arkko, J., Farrel, S., Kühlewind, M., and C. Perkins, | [IABcovid] Arkko, J., Farrel, S., Kühlewind, M., and C. Perkins, | |||
| "Report from the IAB COVID-19 Network Impacts Workshop | "Report from the IAB COVID-19 Network Impacts Workshop | |||
| 2020", November 2020, <https://datatracker.ietf.org/doc/ | 2020", November 2020, <https://datatracker.ietf.org/doc/ | |||
| draft-iab-covid19-workshop/>. | draft-iab-covid19-workshop/>. | |||
| [Jacobson-Karels] | [Jacobson-Karels] | |||
| Jacobson, V. and M. Karels, "Congestion Avoidance and | Jacobson, V. and M. Karels, "Congestion Avoidance and | |||
| skipping to change at page 46, line 27 ¶ | skipping to change at page 38, line 27 ¶ | |||
| Conrad, "Stream Control Transmission Protocol (SCTP) | Conrad, "Stream Control Transmission Protocol (SCTP) | |||
| Partial Reliability Extension", RFC 3758, | Partial Reliability Extension", RFC 3758, | |||
| DOI 10.17487/RFC3758, May 2004, | DOI 10.17487/RFC3758, May 2004, | |||
| <https://www.rfc-editor.org/rfc/rfc3758>. | <https://www.rfc-editor.org/rfc/rfc3758>. | |||
| [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF | [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF | |||
| Digits, Telephony Tones, and Telephony Signals", RFC 4733, | Digits, Telephony Tones, and Telephony Signals", RFC 4733, | |||
| DOI 10.17487/RFC4733, December 2006, | DOI 10.17487/RFC4733, December 2006, | |||
| <https://www.rfc-editor.org/rfc/rfc4733>. | <https://www.rfc-editor.org/rfc/rfc4733>. | |||
| [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | ||||
| RFC 4960, DOI 10.17487/RFC4960, September 2007, | ||||
| <https://www.rfc-editor.org/rfc/rfc4960>. | ||||
| [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop | [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop | |||
| on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", | on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", | |||
| RFC 5594, DOI 10.17487/RFC5594, July 2009, | RFC 5594, DOI 10.17487/RFC5594, July 2009, | |||
| <https://www.rfc-editor.org/rfc/rfc5594>. | <https://www.rfc-editor.org/rfc/rfc5594>. | |||
| [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control | [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control | |||
| Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April | Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April | |||
| 2010, <https://www.rfc-editor.org/rfc/rfc5762>. | 2010, <https://www.rfc-editor.org/rfc/rfc5762>. | |||
| [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. | [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. | |||
| skipping to change at page 48, line 19 ¶ | skipping to change at page 40, line 24 ¶ | |||
| [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for | [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for | |||
| Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, | Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, | |||
| June 2019, <https://www.rfc-editor.org/rfc/rfc8622>. | June 2019, <https://www.rfc-editor.org/rfc/rfc8622>. | |||
| [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, | [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, | |||
| "Double Encryption Procedures for the Secure Real-Time | "Double Encryption Procedures for the Secure Real-Time | |||
| Transport Protocol (SRTP)", RFC 8723, | Transport Protocol (SRTP)", RFC 8723, | |||
| DOI 10.17487/RFC8723, April 2020, | DOI 10.17487/RFC8723, April 2020, | |||
| <https://www.rfc-editor.org/rfc/rfc8723>. | <https://www.rfc-editor.org/rfc/rfc8723>. | |||
| [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static | ||||
| Context Header Compression (SCHC) for the Constrained | ||||
| Application Protocol (CoAP)", RFC 8824, | ||||
| DOI 10.17487/RFC8824, June 2021, | ||||
| <https://www.rfc-editor.org/rfc/rfc8824>. | ||||
| [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for | [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for | |||
| Browser-Based Applications", RFC 8825, | Browser-Based Applications", RFC 8825, | |||
| DOI 10.17487/RFC8825, January 2021, | DOI 10.17487/RFC8825, January 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc8825>. | <https://www.rfc-editor.org/rfc/rfc8825>. | |||
| [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", | [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", | |||
| RFC 8999, DOI 10.17487/RFC8999, May 2021, | RFC 8999, DOI 10.17487/RFC8999, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc8999>. | <https://www.rfc-editor.org/rfc/rfc8999>. | |||
| [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| skipping to change at page 48, line 41 ¶ | skipping to change at page 41, line 5 ¶ | |||
| <https://www.rfc-editor.org/rfc/rfc9000>. | <https://www.rfc-editor.org/rfc/rfc9000>. | |||
| [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | |||
| QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9001>. | <https://www.rfc-editor.org/rfc/rfc9001>. | |||
| [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection | [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection | |||
| and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, | and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, | |||
| May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. | May 2021, <https://www.rfc-editor.org/rfc/rfc9002>. | |||
| [RFC9065] Fairhurst, G. and C. Perkins, "Considerations around | ||||
| Transport Header Confidentiality, Network Operations, and | ||||
| the Evolution of Internet Transport Protocols", RFC 9065, | ||||
| DOI 10.17487/RFC9065, July 2021, | ||||
| <https://www.rfc-editor.org/rfc/rfc9065>. | ||||
| [SFRAME] "Secure Media Frames Working Group (Home Page)", n.d., | [SFRAME] "Secure Media Frames Working Group (Home Page)", n.d., | |||
| <https://datatracker.ietf.org/doc/charter-ietf-sframe/>. | <https://datatracker.ietf.org/doc/charter-ietf-sframe/>. | |||
| [SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol | [SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol | |||
| Overview", 15 April 2020, | Overview", 15 April 2020, | |||
| <https://datatracker.ietf.org/meeting/interim-2020-mops- | <https://datatracker.ietf.org/meeting/interim-2020-mops- | |||
| 01/materials/slides-interim-2020-mops-01-sessa-april- | 01/materials/slides-interim-2020-mops-01-sessa-april- | |||
| 15-2020-mops-interim-an-update-on-streaming-video- | 15-2020-mops-interim-an-update-on-streaming-video- | |||
| alliance>. | alliance>. | |||
| [Survey360o] | [Survey360o] | |||
| Yaqoob, A., Bi, T., and G. Muntean, "A Survey on Adaptive | Yaqoob, A., Bi, T., and G. Muntean, "A Survey on Adaptive | |||
| 360° Video Streaming: Solutions, Challenges and | 360° Video Streaming: Solutions, Challenges and | |||
| Opportunities", IEEE Communications Surveys & Tutorials , | Opportunities", IEEE Communications Surveys & Tutorials , | |||
| July 2020, <https://ieeexplore.ieee.org/document/9133103>. | July 2020, <https://ieeexplore.ieee.org/document/9133103>. | |||
| [tsvarea-105] | ||||
| "TSVAREA Minutes - IETF 105", July 2019, | ||||
| <https://datatracker.ietf.org/meeting/105/materials/ | ||||
| minutes-105-tsvarea-00>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Jake Holland | Jake Holland | |||
| Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
| 150 Broadway | 150 Broadway | |||
| Cambridge, MA 02144, | Cambridge, MA 02144, | |||
| United States of America | United States of America | |||
| Email: jakeholland.net@gmail.com | Email: jakeholland.net@gmail.com | |||
| Ali Begen | Ali Begen | |||
| End of changes. 68 change blocks. | ||||
| 600 lines changed or deleted | 263 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||