rfc9317.original   rfc9317.txt 
MOPS J. Holland Internet Engineering Task Force (IETF) J. Holland
Internet-Draft Akamai Technologies, Inc. Request for Comments: 9317 Akamai Technologies, Inc.
Intended status: Informational A. Begen Category: Informational A. Begen
Expires: 9 February 2023 Networked Media ISSN: 2070-1721 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
8 August 2022 October 2022
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-12
Abstract Abstract
This document provides an overview of operational networking and This document provides an overview of operational networking and
transport protocol issues that pertain to the quality of experience transport protocol issues that pertain to the quality of experience
when streaming video and other high-bitrate media over the Internet. (QoE) when streaming video and other high-bitrate media over the
Internet.
This document is intended to explain the characteristics of streaming This document explains the characteristics of streaming media
media delivery that have surprised network designers or transport delivery that have surprised network designers or transport experts
experts who lack specific media expertise, since streaming media who lack specific media expertise, since streaming media highlights
highlights key differences between common assumptions in existing key differences between common assumptions in existing networking
networking practices and observations of media delivery issues practices and observations of media delivery issues encountered when
encountered when streaming media over those existing networks. streaming media over those existing networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 9 February 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9317.
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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Key Definitions . . . . . . . . . . . . . . . . . . . . . 3 1.1. Key Definitions
1.2. Document Scope . . . . . . . . . . . . . . . . . . . . . 5 1.2. Document Scope
1.3. Notes for Contributors and Reviewers . . . . . . . . . . 6 2. Our Focus on Streaming Video
1.3.1. Venues for Contribution and Discussion . . . . . . . 6 3. Bandwidth Provisioning
2. Our Focus on Streaming Video . . . . . . . . . . . . . . . . 7 3.1. Scaling Requirements for Media Delivery
3. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 8 3.1.1. Video Bitrates
3.1. Scaling Requirements for Media Delivery . . . . . . . . . 8 3.1.2. Virtual Reality Bitrates
3.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 8 3.2. Path Bottlenecks and Constraints
3.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 9 3.2.1. Recognizing Changes from a Baseline
3.2. Path Bottlenecks and Constraints . . . . . . . . . . . . 10 3.3. Path Requirements
3.2.1. Recognizing Changes from a Baseline . . . . . . . . . 11 3.4. Caching Systems
3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 12 3.5. Predictable Usage Profiles
3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 13 3.6. Unpredictable Usage Profiles
3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 14 3.6.1. Peer-to-Peer Applications
3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 14 3.6.2. Impact of Global Pandemic
3.6.1. Peer-to-peer Applications . . . . . . . . . . . . . . 14 4. Latency Considerations
3.6.2. Impact of Global Pandemic . . . . . . . . . . . . . . 15 4.1. Ultra-Low-Latency
4. Latency Considerations . . . . . . . . . . . . . . . . . . . 16 4.1.1. Near-Real-Time Latency
4.1. Ultra-Low-Latency . . . . . . . . . . . . . . . . . . . . 16 4.2. Low-Latency Live
4.1.1. Near-Realtime Latency . . . . . . . . . . . . . . . . 17 4.3. Non-Low-Latency Live
4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 17 4.4. On-Demand
4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 19
4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Adaptive Encoding, Adaptive Delivery, and Measurement 5. Adaptive Encoding, Adaptive Delivery, and Measurement
Collection . . . . . . . . . . . . . . . . . . . . . . . 20 Collection
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview
5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 21 5.2. Adaptive Encoding
5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 21 5.3. Adaptive Segmented Delivery
5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Advertising
5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 23 5.5. Bitrate Detection Challenges
5.5.1. Idle Time between Segments . . . . . . . . . . . . . 24 5.5.1. Idle Time between Segments
5.5.2. Noisy Measurements . . . . . . . . . . . . . . . . . 25 5.5.2. Noisy Measurements
5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 25 5.5.3. Wide and Rapid Variation in Path Capacity
5.6. Measurement Collection . . . . . . . . . . . . . . . . . 25 5.6. Measurement Collection
6. Transport Protocol Behaviors and Their Implications for Media 6. Transport Protocol Behaviors and Their Implications for Media
Transport Protocols . . . . . . . . . . . . . . . . . . . 27 Transport Protocols
6.1. Media Transport over Reliable Transport Protocols
6.1. Media Transport Over Reliable Transport Protocols . . . . 28 6.2. Media Transport over Unreliable Transport Protocols
6.2. Media Transport Over Unreliable Transport Protocols . . . 29 6.3. QUIC and Changing Transport Protocol Behavior
6.3. QUIC and Changing Transport Protocol Behavior . . . . . . 30 7. Streaming Encrypted Media
7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 32 7.1. General Considerations for Streaming Media Encryption
7.1. General Considerations for Streaming Media Encryption . . 33 7.2. Considerations for Hop-by-Hop Media Encryption
7.2. Considerations for Hop-by-Hop Media Encryption . . . . . 35 7.3. Considerations for End-to-End Media Encryption
7.3. Considerations for End-to-End Media Encryption . . . . . 36 8. Additional Resources for Streaming Media
8. Further Reading and References . . . . . . . . . . . . . . . 37 9. IANA Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. Informative References
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 Acknowledgments
12. Informative References . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document provides an overview of operational networking and This document provides an overview of operational networking and
transport protocol issues that pertain to the quality of experience transport protocol issues that pertain to the quality of experience
(QoE) when streaming video and other high-bitrate media over the (QoE) when streaming video and other high-bitrate media over the
Internet. Internet.
This document is intended to explain the characteristics of streaming This document is intended to explain the characteristics of streaming
media delivery that have surprised network designers or transport media delivery that have surprised network designers or transport
skipping to change at page 4, line 9 skipping to change at line 146
- The term "simultaneous" is critical, as media segment - The term "simultaneous" is critical, as media segment
transmission is not considered "streaming" if one downloads a transmission is not considered "streaming" if one downloads a
media file and plays it after the download is completed. media file and plays it after the download is completed.
Instead, this would be called "download and play". Instead, this would be called "download and play".
- This has two implications. First, the sending rate for media - This has two implications. First, the sending rate for media
segments must match the client's consumption rate (whether segments must match the client's consumption rate (whether
loosely or tightly) to provide uninterrupted playback. That loosely or tightly) to provide uninterrupted playback. That
is, the client must not run out of media segments (buffer is, the client must not run out of media segments (buffer
underrun), and must not accept more media segments than it can underrun) and must not accept more media segments than it can
buffer before playback (buffer overrun). buffer before playback (buffer overrun).
- Second, the client's media segment consumption rate is limited - Second, the client's media segment consumption rate is limited
not only by the path's available bandwidth but also by media not only by the path's available bandwidth but also by media
segment availability. The client cannot fetch media segments segment availability. The client cannot fetch media segments
that a media server cannot provide (yet). that a media server cannot provide (yet).
* "Media" refers to any type of media and associated streams such as * "Media" refers to any type of media and associated streams, such
video, audio, metadata, etc. as video, audio, metadata, etc.
* "Over the Internet" means that a single operator does not have * "Over the Internet" means that a single operator does not have
control of the entire path between media servers and media control of the entire path between media servers and media
clients, so not a "walled garden". clients, so it is not a "walled garden".
This document uses these terms, to describe the streaming media This document uses these terms to describe the streaming media
ecosystem: ecosystem:
Streaming Media Operator: An entity that provides streaming media Streaming Media Operator: an entity that provides streaming media
servers servers
Media Server: A server that provides streaming media to a media Media Server: a server that provides streaming media to a media
player player, which is also referred to as a streaming media server, or
simply a server
Also refered to as a streaming media server, or simply a server
Intermediary: An entity that is on-path, between the streaming media Intermediary: an entity that is on-path, between the streaming media
operator and the ultimate media consumer, and that is media-aware operator and the ultimate media consumer, and that is media aware
When the streaming media is encrypted, an intermediary must have When the streaming media is encrypted, an intermediary must have
credentials that allow the intermediary to decrypt the media in credentials that allow the intermediary to decrypt the media in
order to be media-aware order to be media aware.
An intermediary can be one of many specialized subtypes that meet An intermediary can be one of many specialized subtypes that meet
this definition this definition.
Media Player: An endpoint that requests streaming media from a media
player for an ultimate media consumer
Also referred to as a streaming media client, or simply a client Media Player: an endpoint that requests streaming media from a media
server for an ultimate media consumer, which is also referred to
as a streaming media client, or simply a client
Ultimate Media Consumer: A human using a media player Ultimate Media Consumer: a human or machine using a media player
1.2. Document Scope 1.2. Document Scope
A full review of all streaming media considerations for all types of A full review of all streaming media considerations for all types of
media over all types of network paths is too broad a topic to cover media over all types of network paths is too broad a topic to cover
comprehensively in a single document. comprehensively in a single document.
This document focuses chiefly on the large-scale delivery of This document focuses chiefly on the large-scale delivery of
streaming high-bitrate media to end users. It is primarily intended streaming high-bitrate media to end users. It is primarily intended
for those controlling endpoints involved in delivering streaming for those controlling endpoints involved in delivering streaming
media traffic. This can include origin servers publishing content, media traffic. This can include origin servers publishing content,
intermediaries like content delivery networks (CDNs), and providers intermediaries like content delivery networks (CDNs), and providers
for client devices and media players. for client devices and media players.
Most of the considerations covered in this document apply both to Most of the considerations covered in this document apply to both
"live media" (created and streamed as an event is in progress) and "live media" (created and streamed as an event is in progress) and
"media on demand" (previously recorded media that is streamed from "media on demand" (previously recorded media that is streamed from
storage), except where noted. storage), except where noted.
Most of the considerations covered in this document apply both to Most of the considerations covered in this document apply to both
media that is consumed by a media player, for viewing by a human, and media that is consumed by a media player, for viewing by a human, and
media that is consumed by a machine, such as a media recorder that is media that is consumed by a machine, such as a media recorder that is
executing an ABR algorithm, except where noted. executing an adaptive bitrate (ABR) streaming algorithm, except where
noted.
This document contains This document contains
* A short description of streaming video characteristics in * a short description of streaming video characteristics in
Section 2, to set the stage for the rest of the document, Section 2 to set the stage for the rest of the document,
* General guidance on bandwidth provisioning (Section 3) and latency * general guidance on bandwidth provisioning (Section 3) and latency
considerations (Section 4) for streaming media delivery, considerations (Section 4) for streaming media delivery,
* A description of adaptive encoding and adaptive delivery * a description of adaptive encoding and adaptive delivery
techniques in common use for streaming video, along with a techniques in common use for streaming video, along with a
description of the challenges media senders face in detecting the description of the challenges media senders face in detecting the
bitrate available between the media sender and media receiver, and bitrate available between the media sender and media receiver, and
collection of measurements by a third party for use in analytics a collection of measurements by a third party for use in analytics
(Section 5), (Section 5),
* A description of existing transport protocols used for media * a description of existing transport protocols used for media
streaming and the issues encountered when using those protocols, streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol [RFC9000] along with a description of the QUIC transport protocol [RFC9000]
more recently used for streaming media (Section 6), more recently used for streaming media (Section 6),
* A description of implications when streaming encrypted media * a description of implications when streaming encrypted media
(Section 7), and (Section 7), and
* Several pointers for further reading on this rapidly changing * a pointer to additional resources for further reading on this
subject (Section 8). rapidly changing subject (Section 8).
Topics outside this scope include: Topics outside this scope include the following:
* in-depth examination of real-time two-way interactive media, such * an in-depth examination of real-time, two-way interactive media,
as videoconferencing; although this document touches lightly on such as videoconferencing; although this document touches lightly
topics related to this space, the intent is to let readers know on topics related to this space, the intent is to let readers know
that for more in-depth coverage, they should look to other that for more in-depth coverage they should look to other
documents, since the techniques and issues for interactive real- documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large- time, two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media. scale, one-way delivery of streaming media.
* specific recommendations on operational practices to mitigate * specific recommendations on operational practices to mitigate
issues described in this document; although some known mitigations issues described in this document; although some known mitigations
are mentioned in passing, the primary intent is to provide a point are mentioned in passing, the primary intent is to provide a point
of reference for future solution proposals to describe how new of reference for future solution proposals to describe how new
technologies address or avoid existing problems. technologies address or avoid existing problems.
* generalized network performance techniques; while considerations * generalized network performance techniques; while considerations,
such as datacenter design, transit network design, and "walled such as data center design, transit network design, and "walled
garden" optimizations can be crucial components of a performant garden" optimizations, can be crucial components of a performant
streaming media service, these are considered independent topics streaming media service, these are considered independent topics
better addressed by other documents. that are better addressed by other documents.
* transparent tunnels; while tunnels can have an impact on streaming * transparent tunnels; while tunnels can have an impact on streaming
media via issues like the round-trip time and the maximum media via issues like the round-trip time and the maximum
transmission unit (MTU) of packets carried over tunnels, for the transmission unit (MTU) of packets carried over tunnels, for the
purposes of this document, these issues are considered as part of purposes of this document, these issues are considered as part of
the set of network path properties. the set of network path properties.
It is worth pointing out explicitly because questions about "Web Questions about whether this document also covers "Web Real-Time
Real-Time Communication (WebRTC)" has come up often, that RTP, Communication (WebRTC)" have come up often. It does not. WebRTC's
WebRTC's principal media transport protocol ([RFC8834], [RFC8835]), principal media transport protocol [RFC8834] [RFC8835], the Real-time
is mentioned in this document. However, (as noted in Section 2) it Transport Protocol (RTP), is mentioned in this document. However, as
is difficult to give general guidance for unreliable media transport noted in Section 2, it is difficult to give general guidance for
protocols used to carry interactive real-time media. unreliable media transport protocols used to carry interactive real-
time media.
1.3. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section and its subsections
before publication.
This section is to provide references to make it easier to review the
development and discussion on the draft so far.
1.3.1. Venues for Contribution and Discussion
This document is in the GitHub repository at:
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons
(https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons)
Readers are welcome to open issues and send pull requests for this
document.
Substantial discussion of this document should take place on the MOPS
working group mailing list (mops@ietf.org).
* Join: https://www.ietf.org/mailman/listinfo/mops
(https://www.ietf.org/mailman/listinfo/mops)
* Search: 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. The most recent available delivered to end users has become video. The most recent available
estimates found that 75% of the total traffic to end users was video estimates found that 75% of the total traffic to end users was video
in 2019 (as described in [RFC8404], such traffic surveys have since in 2019 (as described in [RFC8404], such traffic surveys have since
become impossible to conduct due to ubiquitous encryption). At that become impossible to conduct due to ubiquitous encryption). At that
time, the share of video traffic had been growing for years and was time, the share of video traffic had been growing for years and was
projected to continue growing (Appendix D of [CVNI]). projected to continue growing (Appendix D of [CVNI]).
skipping to change at page 8, line 4 skipping to change at line 304
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 media delivery. performance, with considerations for the impact on media delivery.
Much of the focus of this document is on media streaming over HTTP. Much of the focus of this document is on media streaming over HTTP.
HTTP is widely used for media streaming because HTTP is widely used for media streaming 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 use already-deployed caching infrastructure such as * HTTP can use already-deployed caching infrastructure, such as
content delivery networks (CDN), local proxies, and browser CDNs, local proxies, and browser caches.
caches.
Various HTTP versions have been used for media delivery. HTTP/1.0, Various HTTP versions have been used for media delivery. HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP [I-D.ietf-tcpm-rfc793bis], HTTP/1.1, and HTTP/2 are carried over TCP [RFC9293], and TCP's
and TCP's transport behavior is described in Section 6.1. HTTP/3 is transport behavior is described in Section 6.1. HTTP/3 is carried
carried over QUIC, and QUIC's transport behavior is described in over QUIC, and QUIC's transport behavior is described in Section 6.3.
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 6.2, and Section 7.2, but it also discussed in Sections 4.1, 6.2, and 7.2, but it is difficult to
is difficult to give general guidance for these applications. For give general guidance for these applications. For instance, when
instance, when packet loss occurs, the most appropriate response may packet loss occurs, the most appropriate response may depend on the
depend on the type of codec being used. 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.
Generally speaking, as the resolution, frame rate, color depth, scene Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate complexity, and amount of motion increase, the encoding bitrate
increases. As newer codecs with better compression tools are used, increases. As newer codecs with better compression tools are used,
the encoding bitrate decreases. Similarly, a multi-pass encoding the encoding bitrate decreases. Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass generally produces better quality output compared to single-pass
encoding at the same bitrate or delivers the same quality at a lower encoding at the same bitrate or delivers the same quality at a lower
bitrate. bitrate.
Here are a few common resolutions used for video content, with Here are a few common resolutions used for video content, with
typical ranges of bitrates for the two most popular video codecs typical ranges of bitrates for the two most popular video codecs
[Encodings]. [Encodings].
skipping to change at page 9, line 17 skipping to change at line 358
+============+================+============+============+ +============+================+============+============+
| DVD | 720 x 480 | 1.0 Mbps | 0.5 Mbps | | DVD | 720 x 480 | 1.0 Mbps | 0.5 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps | | 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps | | 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps | | 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
Table 1 Table 1: Typical Resolutions and Bitrate Ranges Used
for Video Encoding
* Note that these codecs do not take the actual "available * Note that these codecs do not take the actual "available
bandwidth" between streaming video servers and streaming video bandwidth" between media servers and media players into account
receivers into account when encoding because the codec does not when encoding because the codec does not have any idea what
have any idea what network paths and network path conditions will network paths and network path conditions will carry the encoded
carry the encoded video at some point in the future. It is common video at some point in the future. It is common for codecs to
for codecs to offer a small number of resource variants, differing offer a small number of resource variants, differing only in the
only in the bandwidth each variant targets. bandwidth each variant targets.
* Note that video receivers attempting to receive encoded video * Note that media players attempting to receive encoded video across
across a network path with insufficient available path bandwidth a network path with insufficient available path bandwidth might
might request the video server to provide video encoded for lower request the media server to provide video encoded for lower
bitrates, at the cost of lower video quality, as described in bitrates, at the cost of lower video quality, as described in
Section 5.3. Section 5.3.
* In order to provide multiple encodings for video resources, the * In order to provide multiple encodings for video resources, the
codec must produce multiple versions of the video resource encoded codec must produce multiple variants (also called renditions) of
at various bitrates, as described in Section 5.2. the video resource encoded at various bitrates, as described in
Section 5.2.
3.1.2. Virtual Reality Bitrates 3.1.2. Virtual Reality Bitrates
The bitrates given in Section 3.1.1 describe video streams that The bitrates given in Section 3.1.1 describe video streams that
provide the user with a single, fixed point of view - so, the user provide the user with a single, fixed point of view -- therefore, the
has no "degrees of freedom," and the user sees all of the video image user has no "degrees of freedom", and the user sees all of the video
that is available. image that is available.
Even basic virtual reality (360-degree) videos that allow users to Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom" or look around freely (referred to as "three degrees of freedom" or
3DoF) require substantially larger bitrates when they are captured 3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the and encoded, as such videos require multiple fields of view of the
scene. Yet, due to smart delivery methods such as viewport-based or scene. Yet, due to smart delivery methods, such as viewport-based or
tile-based streaming, there is no need to send the whole scene to the tile-based streaming, there is no need to send the whole scene to the
user. Instead, the user needs only the portion corresponding to its user. Instead, the user needs only the portion corresponding to its
viewpoint at any given time ([Survey360o]). viewpoint at any given time [Survey360].
In more immersive applications, where limited user movement ("three In more immersive applications, where limited user movement ("three
degrees of freedom plus" or 3DoF+) or full user movement ("six degrees of freedom plus" or 3DoF+) or full user movement ("six
degrees of freedom" or 6DoF) is allowed, the required bitrate grows degrees of freedom" or 6DoF) is allowed, the required bitrate grows
even further. In this case, immersive content is typically referred even further. In this case, immersive content is typically referred
to as volumetric media. One way to represent the volumetric media is to as volumetric media. One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC] require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC]
for more details. for more details.
skipping to change at page 10, line 30 skipping to change at line 421
bottlenecks at many points along a path, whether the bottleneck bottlenecks at many points along a path, whether the bottleneck
happens at a node or at a path segment along the path, and these happens at a node or at a path segment along the path, and these
bottlenecks may involve a lack of processing power, buffering bottlenecks may involve a lack of processing power, buffering
capacity, link speed, or any other exhaustible resource. capacity, link speed, or any other exhaustible resource.
Media servers may react to bandwidth constraints using two Media servers may react to bandwidth constraints using two
independent feedback loops: independent feedback loops:
* Media servers often respond to application-level feedback from the * Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path media player that indicates a bottleneck somewhere along the path
by adjusting the number of media segments that the media server by sending a different media bitrate. This is described in
will send to the media player in a given timeframe. This is greater detail in Section 5.
described in greater detail in Section 5.
* Media servers also typically rely on transport protocols with * Media servers also typically rely on transport protocols with
capacity-seeking congestion controllers that probe for available capacity-seeking congestion controllers that probe for available
path bandwidth and adjust the media segment sending rate based on path bandwidth and adjust the media sending rate based on
transport mechanisms. This is described in greater detail in transport mechanisms. This is described in greater detail in
Section 6. 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 QoE for users that is significantly other, and this can result in QoE for users that is significantly
lower than what could have been achieved. lower than what could have been achieved.
One might wonder why media servers and transport protocols are each One might wonder why media servers and transport protocols are each
unaware of what the other is doing, and there are multiple reasons unaware of what the other is doing, and there are multiple reasons
for that. One reason is that media servers are often implemented as for that. One reason is that media servers are often implemented as
applications executing in user space, relying on a general-purpose applications executing in user space, relying on a general-purpose
operating system that typically has its transport protocols operating system that typically has its transport protocols
implemented in the operating system kernel, making decisions that the implemented in the operating system kernel, making decisions that the
media server never knows about. media server never knows about.
In one example, if a media server overestimates the available As one example, if a media server overestimates the available
bandwidth to the media player, bandwidth to the media player,
* the transport protocol may detect loss due to congestion and * the transport protocol may detect loss due to congestion and
reduce its sending window size per round trip, reduce 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, and/or
* the transport protocol sends media segments at the new, lower rate
and confirms that this new, lower rate is "safe" because no
transport-level loss is occurring, but
* because the media server continues to send at the new, lower rate, * the transport protocol sends media at the new, lower rate and
the transport protocol's maximum sending rate is now limited by confirms that this new, lower rate is "safe" because no transport-
the amount of information the media server queues for level loss is occurring.
transmission, so
* the transport protocol cannot probe for available path bandwidth However, because the media server continues to send at the new, lower
by sending at a higher rate until the media receiver requests rate, the transport protocol's maximum sending rate is now limited by
segments that buffer enough data for the transport to perform the the amount of information the media server queues for transmission.
probing. Therefore, the transport protocol cannot probe for available path
bandwidth by sending at a higher rate until the media player requests
segments that buffer enough data for the transport to perform the
probing.
To avoid these types of situations, which can potentially affect all To avoid these types of situations, which can potentially affect all
the users whose streaming media segments traverse a bottleneck path the users whose streaming media segments traverse a bottleneck path
segment, there are several possible mitigations that streaming segment, there are several possible mitigations that streaming
operators can use. However, the first step toward mitigating a operators can use. However, the first step toward mitigating a
problem is knowing that a problem is occurring. problem is knowing that a problem is occurring.
3.2.1. Recognizing Changes from a Baseline 3.2.1. Recognizing Changes from a Baseline
There are many reasons why path characteristics might change in There are many reasons why path characteristics might change in
normal operation, for example: normal operation. For example:
* If the path topology changes. For example, routing changes, which * If the path topology changes. For example, routing changes, which
can happen in normal operation, may result in traffic being can happen in normal operation, may result in traffic being
carried over a new path topology that that is partially or carried over a new path topology that is partially or entirely
entirely disjoint from the previous path, especially if the new disjointed from the previous path, especially if the new path
path topology includes one or more path segments that are more topology includes one or more path segments that are more heavily
heavily loaded, offer lower total bandwidth, change the overall loaded, offer lower total bandwidth, change the overall Path MTU
Path MTU size, or simply cover more distance between the path size, or simply cover more distance between the path endpoints.
endpoints.
* If cross traffic that also traverses part or all of the same path * If cross traffic that also traverses part or all of the same path
topology increases or decreases, especially if this new cross topology increases or decreases, especially if this new cross
traffic is "inelastic," and does not respond to indications of traffic is "inelastic" and does not respond to indications of path
path congestion. congestion.
* Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to * Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to
capacity from changes in radio interference and signal strength as capacity from changes in radio interference and signal strength as
endpoints move. endpoints move.
To recognize that a path carrying streaming media segments has To recognize that a path carrying streaming media has experienced a
experienced a change, maintaining a baseline that captures its prior change, maintaining a baseline that captures its prior properties is
properties is fundamental. Analytics that aid in that recognition fundamental. Analytics that aid in that recognition can be more or
can be more or less sophisticated and can usefully operate on several less sophisticated and can usefully operate on several different time
different time scales, from milliseconds to hours or days. scales, from milliseconds to hours or days.
Useful properties to monitor for changes can include: Useful properties to monitor for changes can include the following:
* round-trip times * round-trip times
* loss rate (and explicit congestion notification (ECN) ([RFC3168] * loss rate (and explicit congestion notification (ECN) [RFC3168]
when in use) when in use)
* out-of-order packet rate * out-of-order packet rate
* packet and byte receive rate * packet and byte receive rate
* application level goodput * application-level goodput
* properties of other connections carrying competing traffic, in * properties of other connections carrying competing traffic, in
addition to the connections carrying the streaming media segments addition to the connections carrying the streaming media
* externally provided measurements, for example, from network cards * externally provided measurements, for example, from network cards
or metrics collected by the operating system or metrics collected by the operating system
3.3. Path Requirements 3.3. Path Requirements
The bitrate requirements in Section 3.1 are per end user actively The bitrate requirements in Section 3.1 are per end user actively
consuming a media feed, so in the worst case, the bitrate demands can consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the be multiplied by the number of simultaneous users to find the
bandwidth requirements for a delivery path with that number of users bandwidth requirements for a delivery path with that number of users
skipping to change at page 13, line 13 skipping to change at line 544
connections and/or by packet-level replication using multicast. connections and/or by packet-level replication using multicast.
To the extent that replication of popular content can be performed, To the extent that replication of popular content can be performed,
bandwidth requirements at peering or ingest points can be reduced to bandwidth requirements at peering or ingest points can be reduced to
as low as a per-feed requirement instead of a per-user requirement. as low as a per-feed requirement instead of a per-user requirement.
3.4. Caching Systems 3.4. Caching Systems
When demand for content is relatively predictable, and especially When demand for content is relatively predictable, and especially
when that content is relatively static, caching content close to when that content is relatively static, caching content close to
requesters and pre-loading caches to respond quickly to initial requesters and preloading caches to respond quickly to initial
requests is often useful (for example, HTTP/1.1 caching is described requests are often useful (for example, HTTP/1.1 caching is described
in [RFC9111]). This is subject to the usual considerations for in [RFC9111]). This is subject to the usual considerations for
caching - for example, how much data must be cached to make a caching -- for example, how much data must be cached to make a
significant difference to the requester and how the benefit of significant difference to the requester and how the benefit of
caching and pre-loading caches balances against the costs of tracking caching and preloading cache balances against the costs of tracking
stale content in caches and refreshing that content. stale content in caches and refreshing that content.
It is worth noting that not all high-demand content is "live" It is worth noting that not all high-demand content is "live"
content. One relevant example is when popular streaming content can content. One relevant example is when popular streaming content can
be staged close to a significant number of requesters, as can happen be staged close to a significant number of requesters, as can happen
when a new episode of a popular show is released. This content may when a new episode of a popular show is released. This content may
be largely stable, so low-cost to maintain in multiple places be largely stable and is therefore low-cost to maintain in multiple
throughout the Internet. This can reduce demands for high end-to-end places throughout the Internet. This can reduce demands for high
bandwidth without having to use mechanisms like multicast. end-to-end bandwidth without having to use mechanisms like multicast.
Caching and pre-loading can also reduce exposure to peering point Caching and preloading can also reduce exposure to peering point
congestion, since less traffic crosses the peering point exchanges if congestion, since less traffic crosses the peering point exchanges if
the caches are placed in peer networks. This is especially true when the caches are placed in peer networks. This is especially true when
the content can be pre-loaded during off-peak hours, and if the the content can be preloaded during off-peak hours and if the
transfer can make use of "Lower-Effort Per-Hop Behavior (LE PHB) for transfer can make use of "A Lower-Effort Per-Hop Behavior (LE PHB)
Differentiated Services" [RFC8622], "Low Extra Delay Background for Differentiated Services" [RFC8622], "Low Extra Delay Background
Transport (LEDBAT)" [RFC6817], or similar mechanisms. Transport (LEDBAT)" [RFC6817], or similar mechanisms.
All of this depends, of course, on the ability of a streaming media All of this depends, of course, on the ability of a streaming media
operator to predict usage and provision bandwidth, caching, and other operator to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users. In some cases (Section 3.5), mechanisms to meet the needs of users. In some cases (Section 3.5),
this is relatively routine, but in other cases, it is more difficult this is relatively routine, but in other cases, it is more difficult
(Section 3.6). (Section 3.6).
With the emergence of ultra-low-latency streaming, responses have to With the emergence of ultra-low-latency streaming, responses have to
start streaming to the end user while still being transmitted to the start streaming to the end user while still being transmitted to the
cache, and while the cache does not yet know the size of the object. cache and while the cache does not yet know the size of the object.
Some of the popular caching systems were designed around cache Some of the popular caching systems were designed around a cache
footprint and had deeply ingrained assumptions about knowing the size footprint and had deeply ingrained assumptions about knowing the size
of objects that are being stored, so the change in design of objects that are being stored, so the change in design
requirements in long-established systems caused some errors in requirements in long-established systems caused some errors in
production. Incidents occurred where a transmission error in the production. Incidents occurred where a transmission error in the
connection from the upstream source to the cache could result in the connection from the upstream source to the cache could result in the
cache holding a truncated segment and transmitting it to the end cache holding a truncated segment and transmitting it to the end
user's device. In this case, players rendering the stream often had user's device. In this case, players rendering the stream often had
a playback freeze until the player was reset. In some cases, the a playback freeze until the player was reset. In some cases, the
truncated object was even cached that way and served later to other truncated object was even cached that way and served later to other
players as well, causing continued stalls at the same spot in the players as well, causing continued stalls at the same spot in the
media for all players playing the segment delivered from that cache media for all players playing the segment delivered from that cache
node. node.
3.5. Predictable Usage Profiles 3.5. Predictable Usage Profiles
Historical data shows that users consume more videos and these videos Historical data shows that users consume more videos, and these
are encoded at a bitrate higher than they were in the past. videos are encoded at a bitrate higher than they were in the past.
Improvements in the codecs that help reduce the encoding bitrates Improvements in the codecs that help reduce the encoding bitrates
with better compression algorithms have not offset the increase in with better compression algorithms have not offset the increase in
the demand for the higher quality video (higher resolution, higher the demand for the higher quality video (higher resolution, higher
frame rate, better color gamut, better dynamic range, etc.). In frame rate, better color gamut, better dynamic range, etc.). In
particular, mobile data usage in cellular access networks has shown a particular, mobile data usage in cellular access networks has shown a
large jump over the years due to increased consumption of large jump over the years due to increased consumption of
entertainment and conversational video. entertainment and conversational video.
3.6. Unpredictable Usage Profiles 3.6. Unpredictable Usage Profiles
It is also possible for usage profiles to change significantly and It is also possible for usage profiles to change significantly and
suddenly. These changes are more difficult to plan for, but at a suddenly. These changes are more difficult to plan for, but at a
minimum, recognizing that sudden changes are happening is critical. minimum, recognizing that sudden changes are happening is critical.
Two examples are instructive. The two examples that follow are instructive.
3.6.1. Peer-to-peer Applications 3.6.1. Peer-to-Peer Applications
In the first example, described in "Report from the IETF Workshop on In the first example, described in "Report from the IETF Workshop on
Peer-to-Peer (P2P) Infrastructure, May 28, 2008" ([RFC5594]), when Peer-to-Peer (P2P) Infrastructure, May 28, 2008" [RFC5594], when the
the BitTorrent filesharing application came into widespread use in BitTorrent file sharing application came into widespread use in 2005,
2005, sudden and unexpected growth in peer-to-peer traffic led to sudden and unexpected growth in peer-to-peer traffic led to
complaints from ISP customers about the performance of delay- complaints from ISP customers about the performance of delay-
sensitive traffic (VoIP and gaming). These performance issues sensitive traffic (Voice over IP (VoIP) and gaming). These
resulted from at least two causes: performance issues resulted from at least two causes:
* Many access networks for end users used underlying technologies * Many access networks for end users used underlying technologies
that are inherently asymmetric, favoring downstream bandwidth that are inherently asymmetric, favoring downstream bandwidth
(e.g., ADSL, cellular technologies, most IEEE 802.11 variants), (e.g., ADSL, cellular technologies, and most IEEE 802.11
assuming that most users will need more downstream bandwidth than variants), assuming that most users will need more downstream
upstream bandwidth. This is a good assumption for client-server bandwidth than upstream bandwidth. This is a good assumption for
applications such as streaming media or software downloads, but client-server applications, such as streaming media or software
BitTorrent rewarded peers that uploaded as much as they downloads, but BitTorrent rewarded peers that uploaded as much as
downloaded, so BitTorrent users had much more symmetric usage they downloaded, so BitTorrent users had much more symmetric usage
profiles, which interacted badly with these asymetric access profiles, which interacted badly with these asymmetric access
network technologies. network technologies.
* BitTorrent also used distributed hash tables to organize peers * Some P2P systems also used distributed hash tables to organize
into a ring topology, where each peer knew its "next peer" and peers into a ring topology, where each peer knew its "next peer"
"previous peer." There was no connection between the application- and "previous peer". There was no connection between the
level ring topology and the lower-level network topology, so a application-level ring topology and the lower-level network
peer's "next peer" might be anywhere on the reachable Internet. topology, so a peer's "next peer" might be anywhere on the
Traffic models that expected most communication to take place with reachable Internet. Traffic models that expected most
a relatively small number of servers were unable to cope with communication to take place with a relatively small number of
peer-to-peer traffic that was much less predictable. servers were unable to cope with peer-to-peer traffic that was
much less predictable.
Especially, as end users increase the use of video-based social Especially as end users increase the use of video-based social
networking applications, it will be helpful for access network networking applications, it will be helpful for access network
providers to watch for increasing numbers of end users uploading providers to watch for increasing numbers of end users uploading
significant amounts of content. significant amounts of content.
3.6.2. Impact of Global Pandemic 3.6.2. Impact of Global Pandemic
Early in 2020, the COVID-19 pandemic and resulting quarantines and Early in 2020, the COVID-19 pandemic and resulting quarantines and
shutdowns led to significant changes in traffic patterns due to a shutdowns led to significant changes in traffic patterns due to a
large number of people who suddenly started working and attending large number of people who suddenly started working and attending
school remotely and using more interactive applications school remotely and using more interactive applications (e.g.,
(videoconferencing, in addition to streaming media). Subsequently, videoconferencing and streaming media). Subsequently, the Internet
the Internet Architecture Board (IAB) held a COVID-19 Network Impacts Architecture Board (IAB) held a COVID-19 Network Impacts Workshop
Workshop [RFC9075] in November 2020. The following observations from [RFC9075] in November 2020. The following observations from the
the workshop report are worth considering. 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 (IXPs) over just a few weeks were as big as the traffic growth
the course of a typical year, representing a 15-20% surge in over 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 IXP in terms of data * At Deutscher Commercial Internet Exchange (DE-CIX) Frankfurt, the
throughput, the year 2020 has seen the largest increase in peak world's largest IXP in terms of data throughput, the year 2020 has
traffic within a single year since the IXP was founded in 1995. seen the largest increase in peak traffic within a single year
since the IXP was founded in 1995.
* The usage pattern changed significantly as work-from-home and * The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and would have typically been off-peak hours with adults at work and
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 streaming applications. peak hours for 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 (VPNs), 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 physical link utilization * At the IXP level, it was observed that physical link utilization
increased. This phenomenon could probably be explained by a increased. This phenomenon could probably be explained by a
higher level of uncacheable traffic such as videoconferencing and higher level of uncacheable traffic, such as videoconferencing and
VPNs from residential users as they stopped commuting and switched VPNs, from residential users as they stopped commuting and
to work-at-home. switched to working at home.
Again, it will be helpful for streaming operators to monitor traffic Again, it will be helpful for streaming operators to monitor traffic
as described in Section 5.6, watching for sudden changes in as described in Section 5.6, watching for sudden changes in
performance. performance.
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 played 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 media encoding/decoding and another end) because it includes media encoding/decoding and
buffering time, and for most cases also the ingest to an intermediate buffering time and, for most cases, also the ingest to an
service such as a CDN or other media distribution service, rather intermediate service, such as a CDN or other media distribution
than a direct connection to an end user. service, rather than a direct connection to an end user.
The team working on this document found these rough categories to be The team working on this document found these rough categories to be
useful when considering a streaming media application's latency useful when considering a streaming media application's latency
requirements: requirements:
* ultra-low-latency (less than 1 second) * ultra-low-latency (less than 1 second)
* low-latency live (less than 10 seconds) * low-latency live (less than 10 seconds)
* non-low-latency live (10 seconds to a few minutes) * non-low-latency live (10 seconds to a few minutes)
* on-demand (hours or more) * on-demand (hours or more)
4.1. Ultra-Low-Latency 4.1. Ultra-Low-Latency
Ultra-low-latency delivery of media is defined here as having a Ultra-low-latency delivery of media is defined here as having a
glass-to-glass delay target under one second. glass-to-glass delay target under 1 second.
Some media content providers aim to achieve this level of latency for Some media content providers aim to achieve this level of latency for
live media events. This introduces new challenges when compared to live media events. This introduces new challenges when compared to
the other latency categories described in Section 4, because ultra- the other latency categories described in Section 4, because ultra-
low-latency is on the same scale as commonly observed end-to-end low-latency is on the same scale as commonly observed end-to-end
network latency variation, often due to bufferbloat ([CoDel]), Wi-Fi network latency variation, often due to bufferbloat [CoDel], Wi-Fi
error correction, or packet reordering. These effects can make it error correction, or packet reordering. These effects can make it
difficult to achieve ultra-low-latency for many users, and may difficult to achieve ultra-low-latency for many users and may require
require accepting relatively frequent user-visible media artifacts. accepting relatively frequent user-visible media artifacts. However,
However, for controlled environments that provide mitigations against for controlled environments that provide mitigations against such
such effects, ultra-low-latency is potentially achievable with the effects, ultra-low-latency is potentially achievable with the right
right provisioning and the right media transport technologies. provisioning and the right media transport technologies.
Most applications operating over IP networks and requiring latency Most applications operating over IP networks and requiring latency
this low use the Real-time Transport Protocol (RTP) [RFC3550] or this low use the Real-time Transport Protocol (RTP) [RFC3550] or
WebRTC [RFC8825], which uses RTP as its Media Transport Protocol, WebRTC [RFC8825], which uses RTP as its media transport protocol,
along with several other protocols necessary for safe operation in along with several other protocols necessary for safe operation in
browsers. browsers.
Worth noting is that many applications for ultra-low-latency delivery It is worth noting that many applications for ultra-low-latency
do not need to scale to as many users as applications for low-latency delivery do not need to scale to as many users as applications for
and non-low-latency live delivery, which simplifies many delivery low-latency and non-low-latency live delivery, which simplifies many
considerations. delivery considerations.
Recommended reading for applications adopting an RTP-based approach Recommended reading for applications adopting an RTP-based approach
also includes [RFC7656]. For increasing the robustness of the also includes [RFC7656]. For increasing the robustness of the
playback by implementing adaptive playout methods, refer to [RFC4733] playback by implementing adaptive playout methods, refer to [RFC4733]
and [RFC6843]. and [RFC6843].
4.1.1. Near-Realtime Latency 4.1.1. Near-Real-Time Latency
Some Internet applications that incorporate media streaming have Some Internet applications that incorporate media streaming have
specific interactivity or control-feedback requirements that drive specific interactivity or control-feedback requirements that drive
much lower glass-to-glass media latency targets than one second. much lower glass-to-glass media latency targets than 1 second. These
These include videoconferencing or voice calls, remote video include videoconferencing or voice calls; remote video gameplay;
gameplay, remote control of hardware platforms like drones, vehicles, remote control of hardware platforms like drones, vehicles, or
or surgical robots and many other envisioned or deployed interactive surgical robots; and many other envisioned or deployed interactive
applications. applications.
Applications with latency targets in these regimes are out of scope Applications with latency targets in these regimes are out of scope
for this document. for this document.
4.2. Low-Latency Live 4.2. Low-Latency Live
Low-latency live delivery of media is defined here as having a glass- Low-latency live delivery of media is defined here as having a glass-
to-glass delay target under 10 seconds. to-glass delay target under 10 seconds.
This level of latency is targeted to have a user experience similar This level of latency is targeted to have a user experience similar
to broadcast TV delivery. A frequently cited problem with failing to to broadcast TV delivery. A frequently cited problem with failing to
achieve this level of latency for live sporting events is the user achieve this level of latency for live sporting events is the user
experience failure from having crowds within earshot of one another experience failure from having crowds within earshot of one another
who react audibly to an important play, or from users who learn of an who react audibly to an important play or from users who learn of an
event in the match via some other channel, for example, social media, event in the match via some other channel, for example, social media,
before it has happened on the screen showing the sporting event. before it has happened on the screen showing the sporting event.
Applications requiring low-latency live media delivery are generally Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions. This typically requires feasible at scale with some restrictions. This typically requires
the use of a premium service dedicated to the delivery of live media, the use of a premium service dedicated to the delivery of live media,
and some tradeoffs may be necessary relative to what is feasible in a and some trade-offs may be necessary relative to what is feasible in
higher latency service. The tradeoffs may include higher costs, a higher-latency service. The trade-offs may include higher costs,
delivering a lower quality media, reduced flexibility for adaptive delivering a lower quality media, reduced flexibility for adaptive
bitrates or reduced flexibility for available resolutions so that bitrates, or reduced flexibility for available resolutions so that
fewer devices can receive an encoding tuned for their display. Low- fewer devices can receive an encoding tuned for their display. Low-
latency live delivery is also more susceptible to user-visible latency live delivery is also more susceptible to user-visible
disruptions due to transient network conditions than higher latency disruptions due to transient network conditions than higher-latency
services. services.
Implementation of a low-latency live media service can be achieved Implementation of a low-latency live media service can be achieved
with the use of "HTTP Live Streaming (HLS)" [RFC8216] by using its with the use of HTTP Live Streaming (HLS) [RFC8216] by using its low-
low-latency extension (called LL-HLS) latency extension (called LL-HLS) [HLS-RFC8216BIS] or with Dynamic
[I-D.draft-pantos-hls-rfc8216bis] or with "Dynamic Adaptive Streaming Adaptive Streaming over HTTP (DASH) [MPEG-DASH] by using its low-
over HTTP (DASH)" [MPEG-DASH] by using its low-latency extension latency extension (called LL-DASH) [LL-DASH]. These extensions use
(called LL-DASH) [LL-DASH]. These extensions use the Common Media the Common Media Application Format (CMAF) standard [MPEG-CMAF] that
Application Format (CMAF) standard [MPEG-CMAF] that allows the media allows the media to be packaged into and transmitted in units smaller
to be packaged into and transmitted in units smaller than segments, than segments, which are called "chunks" in CMAF language. This way,
which are called chunks in CMAF language. This way, the latency can the latency can be decoupled from the duration of the media segments.
be decoupled from the duration of the media segments. Without a Without a CMAF-like packaging, lower latencies can only be achieved
CMAF-like packaging, lower latencies can only be achieved by using by using very short segment durations. However, using shorter
very short segment durations. However, using shorter segments means segments means using more frequent intra-coded frames, and that is
using more frequent intra-coded frames and that is detrimental to detrimental to video encoding quality. The CMAF standard allows us
video encoding quality. CMAF allows us to still use longer segments to still use longer segments (improving encoding quality) without
(improving encoding quality) without penalizing latency. penalizing latency.
While an LL-HLS client retrieves each chunk with a separate HTTP GET While an LL-HLS client retrieves each chunk with a separate HTTP GET
request, an LL-DASH client uses the chunked transfer encoding feature request, an LL-DASH client uses the chunked transfer encoding feature
of the HTTP [CMAF-CTE], which allows the LL-DASH client to fetch all of the HTTP [CMAF-CTE], which allows the LL-DASH client to fetch all
the chunks belonging to a segment with a single GET request. An HTTP the chunks belonging to a segment with a single GET request. An HTTP
server can transmit the CMAF chunks to the LL-DASH client as they server can transmit the CMAF chunks to the LL-DASH client as they
arrive from the encoder/packager. A detailed comparison of LL-HLS arrive from the encoder/packager. A detailed comparison of LL-HLS
and LL-DASH is given in [MMSP20]. and LL-DASH is given in [MMSP20].
4.3. Non-Low-Latency Live 4.3. Non-Low-Latency Live
Non-low-latency live delivery of media is defined here as a Non-low-latency live delivery of media is defined here as a live
livestream that does not have a latency target shorter than 10 stream that does not have a latency target shorter than 10 seconds.
seconds.
This level of latency is the historically common case for segmented This level of latency is the historically common case for segmented
media delivery using HLS and DASH. This level of latency is often media delivery using HLS and DASH. This level of latency is often
considered adequate for content like news. This level of latency is considered adequate for content like news. This level of latency is
also sometimes achieved as a fallback state when some part of the also sometimes achieved as a fallback state when some part of the
delivery system or the client-side players do not have the necessary delivery system or the client-side players do not support low-latency
support for the features necessary to support low-latency live live streaming.
streaming.
This level of latency can typically be achieved at scale with This level of latency can typically be achieved at scale with
commodity CDN services for HTTP(s) delivery, and in some cases, the commodity CDN services for HTTP(s) delivery, and in some cases, the
increased time window can allow for the production of a wider range increased time window can allow for the production of a wider range
of encoding options relative to the requirements for a lower latency of encoding options relative to the requirements for a lower-latency
service without the need for increasing the hardware footprint, which service without the need for increasing the hardware footprint, which
can allow for wider device interoperability. can allow for wider device interoperability.
4.4. On-Demand 4.4. On-Demand
On-demand media streaming refers to the playback of pre-recorded On-demand media streaming refers to the playback of pre-recorded
media based on a user's action. In some cases, on-demand media is media based on a user's action. In some cases, on-demand media is
produced as a by-product of a live media production, using the same produced as a by-product of a live media production, using the same
segments as the live event, but freezing the manifest that describes segments as the live event but freezing the manifest that describes
the media available from the media server after the live event has the media available from the media server after the live event has
finished. In other cases, on-demand media is constructed out of pre- finished. In other cases, on-demand media is constructed out of pre-
recorded assets with no streaming necessarily involved during the recorded assets with no streaming necessarily involved during the
production of the on-demand content. production of the on-demand content.
On-demand media generally is not subject to latency concerns, but On-demand media generally is not subject to latency concerns, but
other timing-related considerations can still be as important or even other timing-related considerations can still be as important or even
more important to the user experience than the same considerations more important to the user experience than the same considerations
with live events. These considerations include the startup time, the with live events. These considerations include the startup time, the
stability of the media stream's playback quality, and avoidance of stability of the media stream's playback quality, and avoidance of
stalls and other media artifacts during the playback under all but stalls and other media artifacts during the playback under all but
the most severe network conditions. the most severe network conditions.
In some applications, optimizations are available to on-demand media In some applications, optimizations are available to on-demand media
that are not always available to live events, such as pre-loading the but are not always available to live events, such as preloading the
first segment for a startup time that does not have to wait for a first segment for a startup time that does not have to wait for a
network download to begin. network download to begin.
5. Adaptive Encoding, Adaptive Delivery, and Measurement Collection 5. Adaptive Encoding, Adaptive Delivery, and Measurement Collection
This section describes one of the best-known ways to provide a good This section describes one of the best-known ways to provide a good
user experience over a given network path, but one thing to keep in user experience over a given network path, but one thing to keep in
mind is that application-level mechanisms cannot provide a better mind is that application-level mechanisms cannot provide a better
experience than the underlying network path can support. experience than the underlying network path can support.
5.1. Overview 5.1. Overview
A simple model of media playback can be described as a media stream A simple model of media playback can be described as a media stream
consumer, a buffer, and a transport mechanism that fills the buffer. consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the The consumption rate is fairly static and is represented by the
content bitrate. The size of the buffer is also commonly a fixed content bitrate. The size of the buffer is also commonly a fixed
size. The buffer fill process needs to be at least fast enough to size. The buffer fill process needs to be at least fast enough to
ensure that the buffer is never empty, however, it also can have ensure that the buffer is never empty; however, it also can have
significant complexity when things like personalization or significant complexity when things like personalization or
advertising insertion workflows are introduced. advertising insertion workflows are introduced.
The challenges in filling the buffer in a timely way fall into two The challenges in filling the buffer in a timely way fall into two
broad categories: broad categories:
* Content selection comprises all of the steps needed to determine * Content variation (also sometimes called a "bitrate ladder") is
which content variation to offer the client. the set of content renditions that are available at any given
selection point.
* Content variation is the number of content options that exist at * Content selection comprises all of the steps a client uses to
any given selection point. determine which content rendition to play.
The mechanism used to select the bitrate is part of the content The mechanism used to select the bitrate is part of the content
selection, and the content variation are all of the different bitrate selection, and the content variation is all of the different bitrate
renditions. renditions.
Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a Adaptive bitrate streaming ("ABR streaming" or simply "ABR") is a
commonly used technique for dynamically adjusting the compression commonly used technique for dynamically adjusting the media quality
level and media quality of a stream to match bandwidth availability. of a stream to match bandwidth availability. When this goal is
When this goal is achieved, the media server will tend to send enough achieved, the media server will tend to send enough media that the
media that the media player does not "stall", without sending so much media player does not "stall", without sending so much media that the
media that the media player cannot accept it without exhausting all media player cannot accept it.
available receive buffers.
ABR uses an application-level response strategy in which the ABR uses an application-level response strategy in which the
streaming client attempts to detect the available bandwidth of the streaming client attempts to detect the available bandwidth of the
network path by first observing the successful application-layer network path by first observing the successful application-layer
download speed, and then, given the available bandwidth, the client download speed; then, given the available bandwidth, the client
chooses a bitrate for each of the video, audio, subtitles and chooses a bitrate for each of the video, audio, subtitles, and
metadata (among a limited number of available options for each type metadata (among a limited number of available options for each type
of media) that fits within that bandwidth, typically adjusting as of media) that fits within that bandwidth, typically adjusting as
changes in available bandwidth occur in the network or changes in changes in available bandwidth occur in the network or changes in
capabilities occur during the playback (such as available memory, capabilities occur during the playback (such as available memory,
CPU, display size, etc.). CPU, display size, etc.).
5.2. Adaptive Encoding 5.2. Adaptive Encoding
Media servers can provide media streams at various bitrates because Media servers can provide media streams at various bitrates because
the media has been encoded at various bitrates. This is a so-called the media has been encoded at various bitrates. This is a so-called
"ladder" of bitrates that can be offered to media players as part of "ladder" of bitrates that can be offered to media players as part of
the manifest, so that the media player can select among the available the manifest so that the media player can select among the available
bitrate choices. bitrate choices.
The media server may also choose to alter which bitrates are made The media server may also choose to alter which bitrates are made
available to players by adding or removing bitrate options from the available to players by adding or removing bitrate options from the
ladder delivered to the player in subsequent manifests built and sent ladder delivered to the player in subsequent manifests built and sent
to the player. This way, both the player, through its selection of to the player. This way, both the player, through its selection of
bitrate to request from the manifest, and the server, through its bitrate to request from the manifest, and the server, through its
construction of the bitrates offered in the manifest, are able to construction of the bitrates offered in the manifest, are able to
affect network utilization. affect network utilization.
5.3. Adaptive Segmented Delivery 5.3. Adaptive Segmented Delivery
Adaptive Segmented Delivery attempts to optimize its own use of the Adaptive segmented delivery attempts to optimize its own use of the
path between a media server and a media client. ABR playback is path between a media server and a media client. ABR playback is
commonly implemented by streaming clients using HLS [RFC8216] or DASH commonly implemented by streaming clients using HLS [RFC8216] or DASH
[MPEG-DASH] to perform a reliable segmented delivery of media over [MPEG-DASH] to perform a reliable segmented delivery of media over
HTTP. Different implementations use different strategies HTTP. Different implementations use different strategies
[ABRSurvey], often relying on proprietary algorithms (called rate [ABRSurvey], often relying on proprietary algorithms (called rate
adaptation or bitrate selection algorithms) to perform available adaptation or bitrate selection algorithms) to perform available
bandwidth estimation/prediction and the bitrate selection. bandwidth estimation/prediction and the bitrate selection.
Many systems will do an initial probe or a very simple throughput Many systems will do an initial probe or a very simple throughput
speed test at the start of media playback. This is done to get a speed test at the start of media playback. This is done to get a
rough sense of the highest (total) media bitrate that the network rough sense of the highest (total) media bitrate that the network
between the server and player will likely be able to provide under between the server and player will likely be able to provide under
initial network conditions. After the initial testing, clients tend initial network conditions. After the initial testing, clients tend
to rely upon passive network observations and will make use of player to rely upon passive network observations and will make use of
side statistics such as buffer fill rates to monitor and respond to player-side statistics, such as buffer fill rates, to monitor and
changing network conditions. respond to changing network conditions.
The choice of bitrate occurs within the context of optimizing for one The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as the highest or more metrics monitored by the client, such as the highest
achievable audiovisual quality or lowest chances for a rebuffering achievable audiovisual quality or the lowest chances for a
event (playback stall). rebuffering event (playback stall).
5.4. Advertising 5.4. Advertising
The inclusion of advertising alongside or interspersed with streaming The inclusion of advertising alongside or interspersed with streaming
media content is common in today's media landscape. media content is common in today's media landscape.
Some commonly used forms of advertising can introduce potential user Some commonly used forms of advertising can introduce potential user
experience issues for a media stream. This section provides a very experience issues for a media stream. This section provides a very
brief overview of a complex and rapidly evolving space. brief overview of a complex and rapidly evolving space.
The same techniques used to allow a media player to switch between The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can renditions of different bitrates at segment boundaries can also be
also be used to enable the dynamic insertion of advertisements used to enable the dynamic insertion of advertisements (hereafter
(hereafter referred to as "ads"), but this does not mean that the referred to as "ads"), but this does not mean that the insertion of
insertion of ads has no effect on the user's quality of experience. ads has no effect on the user's quality of experience.
Ads may be inserted either with Client-side Ad Insertion (CSAI) or Ads may be inserted with either Client-side Ad Insertion (CSAI) or
Server-side Ad Insertion (SSAI). - In CSAI, the ABR manifest will Server-side Ad Insertion (SSAI). In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same the media stream, while in SSAI, the server will remain the same
during advertisements, but will include media segments that contain during ads but will include media segments that contain the
the advertising. - In SSAI, the media segments may or may not be advertising. In SSAI, the media segments may or may not be sourced
sourced from an external ad server like with CSAI. from an external ad server like with CSAI.
In general, the more targeted the ad request is, the more requests In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently. If the ad service needs to be able to handle concurrently. If
connectivity is poor to the ad service, this can cause rebuffering connectivity is poor to the ad service, this can cause rebuffering
even if the underlying media assets (both content and ads) can be even if the underlying media assets (both content and ads) can be
accessed quickly. The less targeted the ad request is, the more accessed quickly. The less targeted the ad request is, the more
likely that ad requests can be consolidated, and that ads can be likely that ad requests can be consolidated and that ads can be
cached similarly to the media content. cached similarly to the media content.
In some cases, especially with SSAI, advertising space in a stream is In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as video so that the segments share the same encoding properties, such
bitrate, dynamic range and resolution. However, in many cases, ad as bitrate, dynamic range, and resolution. However, in many cases,
servers integrate with a Supply Side Platform (SSP) that offers ad servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs) for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the that collect money from advertisers for delivering the ads. Most
advertisements. Most such Ad Exchanges use application-level such Ad Exchanges use application-level protocol specifications
protocol specifications published by the Interactive Advertising published by the Interactive Advertising Bureau [IAB-ADS], an
Bureau [IAB-ADS], an industry trade organization. industry trade organization.
This ecosystem balances several competing objectives and integrating This ecosystem balances several competing objectives, and integrating
with it naively can produce surprising user experience results. For with it naively can produce surprising user experience results. For
example, ad server provisioning and/or the bitrate of the ad segments example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main content, and either of these might be different from that of the main content, and either of these
differences can result in playback stalls. For another example, differences can result in playback stalls. For another example,
since the inserted ads are often produced independently, they might since the inserted ads are often produced independently, they might
have a different base volume level than the main content, which can have a different base volume level than the main content, which can
make for a jarring user experience. make for a jarring user experience.
Another major source of competing objectives comes from user privacy Another major source of competing objectives comes from user privacy
considerations vs. the advertiser's incentives to target ads to user considerations vs. the advertiser's incentives to target ads to user
segments based on behavioral data. Multiple studies, for example, segments based on behavioral data. Multiple studies, for example,
[BEHAVE] and [BEHAVE2], have reported large improvements in ad [BEHAVE] and [BEHAVE2], have reported large improvements in ad
effectiveness when using behaviorally targeted ads, relative to effectiveness when using behaviorally targeted ads, relative to
untargeted ads. This provides a strong incentive for advertisers to untargeted ads. This provides a strong incentive for advertisers to
gain access to the data necessary to perform behavioral targeting, gain access to the data necessary to perform behavioral targeting,
leading some to engage in what is indistinguishable from a pervasive leading some to engage in what is indistinguishable from a pervasive
monitoring attack ([RFC7258]) based on user tracking in order to monitoring attack [RFC7258] based on user tracking in order to
collect the relevant data, A more complete review of issues in this collect the relevant data. A more complete review of issues in this
space is available in [BALANCING]. space is available in [BALANCING].
On top of these competing objectives, this market historically has On top of these competing objectives, this market historically has
had incidents of misreporting of ad delivery to end users for had incidents of misreporting of ad delivery to end users for
financial gain [ADFRAUD]. As a mitigation for concerns driven by financial gain [ADFRAUD]. As a mitigation for concerns driven by
those incidents, some SSPs have required the use of specific media those incidents, some SSPs have required the use of specific media
players that include features like reporting of ad delivery, or players that include features like reporting of ad delivery or
providing additional user information that can be used for tracking. providing additional user information that can be used for tracking.
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 various
several ways that are affected by networking and transport protocol troubles that are affected by networking and transport protocol
issues. Because adaptive application-level response strategies are issues. Because adaptive application-level response strategies are
often using rates as observed by the application layer, there are often using rates as observed by the application layer, there are
sometimes inscrutable transport-level protocol behaviors that can sometimes inscrutable transport-level protocol behaviors that can
produce surprising measurement values when the application-level produce surprising measurement values when the application-level
feedback loop is 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 that vary 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 QoE, especially where players use naive selection and on user QoE, especially where players use naive
measurement strategies and selection algorithms that don't account measurement strategies and selection algorithms that do not account
for the likelihood of bandwidth measurements that diverge from the for the likelihood of bandwidth measurements that diverge 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:
* TCP slow-start when restarting after idle requires multiple RTTs * TCP slow-start, when restarting after idle, requires multiple RTTs
to re-establish a throughput at the network's available capacity. to re-establish a throughput at the network's available capacity.
When the active transmission time for segments is substantially When the active transmission time for segments is substantially
shorter than the time between segments, leaving an idle gap shorter than the time between segments, leaving an idle gap
between segments that triggers a restart of TCP slow-start, the between segments that triggers a restart of TCP slow-start, the
estimate of the successful download speed coming from the estimate of the successful download speed coming from the
application-visible receive rate on the socket can thus end up application-visible receive rate on the socket can thus end up
much lower than the actual available network capacity. This, in much lower than the actual available network capacity. This, in
turn, can prevent a shift to the most appropriate bitrate. turn, can prevent a shift to the most appropriate bitrate.
[RFC7661] provides some mitigations for this effect at the TCP [RFC7661] provides some mitigations for this effect at the TCP
transport layer for senders who anticipate a high incidence of transport layer for senders who anticipate a high incidence of
this problem. this problem.
* Mobile flow-bandwidth spectrum and timing mapping can be impacted * Mobile flow-bandwidth spectrum and timing mapping can be impacted
by idle time in some networks. The carrier capacity assigned to a by idle time in some networks. The carrier capacity assigned to a
physical or virtual link can vary with activity. Depending on the physical or virtual link can vary with activity. Depending on the
idle time characteristics, this can result in a lower available idle time characteristics, this can result in a lower available
bitrate than would be achievable with a steadier transmission in bitrate than would be achievable with a steadier transmission in
the same network. the same network.
Some receiver-side ABR algorithms such as [ELASTIC] are designed to Some receiver-side ABR algorithms, such as [ELASTIC], are designed to
try to avoid this effect. try to avoid this effect.
Another way to mitigate this effect is by the help of two Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in [MMSys11] for Microsoft simultaneous TCP connections, as explained in [MMSys11] for Microsoft
Smooth Streaming. In some cases, the system-level TCP slow-start Smooth Streaming. In some cases, the system-level TCP slow-start
restart can also be disabled, for example, as described in restart can also be disabled, for example, as described in
[OReilly-HPBN]. [OReilly-HPBN].
5.5.2. Noisy Measurements 5.5.2. Noisy Measurements
skipping to change at page 25, line 42 skipping to change at line 1128
hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth
detection have emerged. detection have emerged.
In most real-world operating environments, wireless links can often In most real-world operating environments, wireless links can often
experience sudden changes in capacity as the end user device moves experience sudden changes in capacity as the end user device moves
from place to place or encounters new sources of interference. from place to place or encounters new sources of interference.
Microwave ovens, for example, can cause a throughput degradation in Microwave ovens, for example, can cause a throughput degradation in
Wi-Fi of more than a factor of 2 while active [Micro]. Wi-Fi of more than a factor of 2 while active [Micro].
These swings in actual transport capacity can result in user These swings in actual transport capacity can result in user
experience issues when interacting with ABR algorithms that aren't experience issues when interacting with ABR algorithms that are not
tuned to handle the capacity variation gracefully. tuned to handle the capacity variation gracefully.
5.6. Measurement Collection 5.6. Measurement Collection
Media players use measurements to guide their segment-by-segment Media players use measurements to guide their segment-by-segment
adaptive streaming requests, but may also provide measurements to adaptive streaming requests but may also provide measurements to
streaming media providers. streaming media providers.
In turn, media providers may base analytics on these measurements to In turn, media providers may base analytics on these measurements to
guide decisions such as whether adaptive encoding bitrates in use are guide decisions, such as whether adaptive encoding bitrates in use
the best ones to provide to media players, or whether current media are the best ones to provide to media players or whether current
content caching is providing the best experience for viewers. media content caching is providing the best experience for viewers.
To that effect, the Consumer Technology Association (CTA), who owns To that effect, the Consumer Technology Association (CTA), who owns
the Web Application Video Ecosystem (WAVE) project, has published two the Web Application Video Ecosystem (WAVE) project, has published two
important specifications. important specifications.
* CTA-2066: Streaming Quality of Experience Events, Properties and * CTA-2066: Streaming Quality of Experience Events, Properties and
Metrics Metrics
[CTA-2066] specifies a set of media player events, properties, QoE [CTA-2066] specifies a set of media player events, properties, QoE
metrics and associated terminology for representing streaming media metrics, and associated terminology for representing streaming media
QoE across systems, media players and analytics vendors. While all QoE across systems, media players, and analytics vendors. While all
these events, properties, metrics and associated terminology are used these events, properties, metrics, and associated terminology are
across a number of proprietary analytics and measurement solutions, used across a number of proprietary analytics and measurement
they were used in slightly (or vastly) different ways that led to solutions, they were used in slightly (or vastly) different ways that
interoperability issues. CTA-2066 attempts to address this issue by led to interoperability issues. CTA-2066 attempts to address this
defining a common terminology as well as how each metric should be issue by defining common terminology and how each metric should be
computed for consistent reporting. computed for consistent reporting.
* CTA-5004: Common Media Client Data (CMCD) * CTA-5004: Web Application Video Ecosystem - Common Media Client
Data (CMCD)
Many assume that the CDNs have a holistic view of the health and Many assume that the CDNs have a holistic view of 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.
6. Transport Protocol Behaviors and Their Implications for Media 6. Transport Protocol Behaviors and Their Implications for Media
Transport Protocols Transport Protocols
Within this document, the term "Media Transport Protocol" is used to Within this document, the term "media transport protocol" is used to
describe any protocol that carries media metadata and media segments describe any protocol that carries media metadata and media segments
in its payload, and the term "Transport Protocol" describes any in its payload, and the term "transport protocol" describes any
protocol that carries a Media Transport Protocol, or another protocol that carries a media transport protocol, or another
Transport Protocol, in its payload. This is easier to understand if transport protocol, in its payload. This is easier to understand if
the reader assumes a protocol stack that looks something like this: the reader assumes a protocol stack that looks something like this:
Media Segments Media Segments
--------------------------- ---------------------------
Media Format Media Format
--------------------------- ---------------------------
Media Transport Protocol Media Transport Protocol
--------------------------- ---------------------------
Transport Protocol(s) Transport Protocol(s)
where where
* "Media Segments" would be something like the output of a codec, or * "Media segments" would be something like the output of a codec or
some other source of media segments, such as closed-captioning, some other source of media segments, such as closed-captioning,
* "Media Format" would be something like an RTP payload format * "Media format" would be something like an RTP payload format
[RFC2736] or an ISOBMFF [ISOBMFF] profile, [RFC2736] or an ISO base media file format (ISOBMFF) profile
[ISOBMFF],
* "Media Transport Protocol" would be something like RTP [RFC3550] * "Media transport protocol" would be something like RTP [RFC3550]
or DASH [MPEG-DASH], and or DASH [MPEG-DASH], and
* "Transport Protocol" would be a protocol that provides appropriate * "Transport protocol" would be a protocol that provides appropriate
transport services, as described in Section 5 of [RFC8095]. transport services, as described in Section 5 of [RFC8095].
Not all possible streaming media applications follow this model, but Not all possible streaming media applications follow this model, but
for the ones that do, it seems useful to distinguish between the for the ones that do, it seems useful to distinguish between the
protocol layer that is aware it is transporting media segments, and protocol layer that is aware it is transporting media segments and
underlying protocol layers that are not aware. underlying protocol layers that are not aware.
As described in the [RFC8095] Abstract, the IETF has standardized a As described in the abstract of [RFC8095], the IETF has standardized
number of protocols that provide transport services. Although these a number of protocols that provide transport services. Although
protocols, taken in total, provide a wide variety of transport these protocols, taken in total, provide a wide variety of transport
services, Section 6 will distinguish between two extremes: services, Section 6 will distinguish between two extremes:
* Transport protocols used to provide reliable, in-order media * transport protocols used to provide reliable, in-order media
delivery to an endpoint, typically providing flow control and delivery to an endpoint, typically providing flow control and
congestion control (Section 6.1) and congestion control (Section 6.1), and
* Transport protocols used to provide unreliable, unordered media * transport protocols used to provide unreliable, unordered media
delivery to an endpoint, without flow control or congestion delivery to an endpoint, without flow control or congestion
control (Section 6.2). control (Section 6.2).
Because newly standardized transport protocols such as QUIC [RFC9000] Because newly standardized transport protocols, such as QUIC
that are typically implemented in userspace can evolve their [RFC9000], that are typically implemented in user space can evolve
transport behavior more rapidly than currently-used transport their transport behavior more rapidly than currently used transport
protocols that are typically implemented in operating system kernel protocols that are typically implemented in operating system kernel
space, this document includes a description of how the path space, this document includes a description of how the path
characteristics that streaming media providers may see are likely to characteristics that streaming media providers may see are likely to
evolve in Section 6.3. evolve; see Section 6.3.
It is worth noting explicitly that the Transport Protocol layer might It is worth noting explicitly that the transport protocol layer might
include more than one protocol. For example, a specific Media include more than one protocol. For example, a specific media
Transport Protocol might run over HTTP, or over WebTransport, which transport protocol might run over HTTP, or over WebTransport, which
in turn runs over HTTP. in turn runs over HTTP.
It is worth noting explicitly that more complex network protocol It is worth noting explicitly that more complex network protocol
stacks are certainly possible - for instance, when packets with this stacks are certainly possible -- for instance, when packets with this
protocol stack are carried in a tunnel or in a VPN, the entire packet protocol stack are carried in a tunnel or in a VPN, the entire packet
would likely appear in the payload of other protocols. If these would likely appear in the payload of other protocols. If these
environments are present, streaming media operators may need to environments are present, streaming media operators may need to
analyze their effects on applications as well. analyze their effects on applications as well.
6.1. Media Transport Over Reliable Transport Protocols 6.1. Media Transport over Reliable Transport Protocols
The HLS [RFC8216] and DASH [MPEG-DASH] media transport protocols are The HLS [RFC8216] and DASH [MPEG-DASH] media transport protocols are
typically carried over HTTP, and HTTP has used TCP as its only typically carried over HTTP, and HTTP has used TCP as its only
standardized transport protocol until HTTP/3 [RFC9114]. These media standardized transport protocol until HTTP/3 [RFC9114]. These media
transport protocols use ABR response strategies as described in transport protocols use ABR response strategies as described in
Section 5 to respond to changing path characteristics, and underlying Section 5 to respond to changing path characteristics, and underlying
transport protocols are also attempting to respond to changing path transport protocols are also attempting to respond to changing path
characteristics. characteristics.
The past success of the largely TCP-based Internet is evidence that The past success of the largely TCP-based Internet is evidence that
the various flow control and congestion control mechanisms TCP has the various flow control and congestion control mechanisms that TCP
used to achieve equilibrium quickly, at a point where TCP senders do has used to achieve equilibrium quickly, at a point where TCP senders
not interfere with other TCP senders for sustained periods of time do not interfere with other TCP senders for sustained periods of time
([RFC5681]), have been largely successful. The Internet has [RFC5681], have been largely successful. The Internet has continued
continued to work even when the specific TCP mechanisms used to reach to work even when the specific TCP mechanisms used to reach
equilibrium changed over time ([RFC7414]). Because TCP provided a equilibrium changed over time [RFC7414]. Because TCP provided a
common tool to avoid contention, even when significant TCP-based common tool to avoid contention, even when significant TCP-based
applications like FTP were largely replaced by other significant TCP- applications like FTP were largely replaced by other significant TCP-
based applications like HTTP, the transport behavior remained safe based applications like HTTP, the transport behavior remained safe
for the Internet. for the Internet.
Modern TCP implementations ([I-D.ietf-tcpm-rfc793bis]) continue to Modern TCP implementations [RFC9293] continue to probe for available
probe for available bandwidth, and "back off" when a network path is bandwidth and "back off" when a network path is saturated but may
saturated, but may also work to avoid growing queues along network also work to avoid growing queues along network paths, which can
paths, which can prevent older TCP senders from detecting quickly prevent older TCP senders from quickly detecting when a network path
when a network path is becoming saturated. Congestion control is becoming saturated. Congestion control mechanisms, such as Copa
mechanisms such as COPA [COPA18] and BBR [COPA18] and Bottleneck Bandwidth and Round-trip propagation time
[I-D.cardwell-iccrg-bbr-congestion-control] make these decisions (BBR) [BBR-CONGESTION-CONTROL], make these decisions based on
based on measured path delays, assuming that if the measured path measured path delays, assuming that if the measured path delay is
delay is increasing, the sender is injecting packets onto the network increasing, the sender is injecting packets onto the network path
path faster than the network can forward them (or the receiver can faster than the network can forward them (or the receiver can accept
accept them) so the sender should adjust its sending rate them), so the sender should adjust its sending rate accordingly.
accordingly.
Although common TCP behavior has changed significantly since the days Although common TCP behavior has changed significantly since the days
of [Jacobson-Karels] and [RFC2001], even adding new congestion of [Jacobson-Karels] and [RFC2001], even with adding new congestion
controllers such as CUBIC [RFC8312], the common practice of controllers such as CUBIC [RFC8312], 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.2. Media Transport Over Unreliable Transport Protocols 6.2. Media Transport over Unreliable Transport Protocols
Because UDP does not provide any feedback mechanism to senders to Because UDP does not provide any feedback mechanism to senders to
help limit impacts on other users, UDP-based application-level help limit impacts on other users, UDP-based application-level
protocols have been responsible for the decisions that TCP-based protocols 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, i.e., what to send, how much to
and when to send it. Because UDP itself has no transport-layer send, and when to send it. Because UDP itself 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, and to respond to the feedback the application feedback mechanisms and to respond to the feedback the application
receives. This expectation is most recently codified as a Best receives. This expectation is most recently codified as a Best
Current Practice [RFC8085]. Current Practice [RFC8085].
In contrast to adaptive segmented delivery over a reliable transport In contrast to adaptive segmented delivery over a reliable transport
as described in Section 5.3, some applications deliver streaming as described in Section 5.3, some applications deliver streaming
media segments using an unreliable transport, and rely on a variety media segments using an unreliable transport and rely on a variety of
of approaches, including: approaches, including:
* raw MPEG Transport Stream ("MPEG-TS")-formatted media [MPEG-TS] * media encapsulated in a raw MPEG Transport Stream (MPEG-TS)
over UDP, which makes no attempt to account for reordering or loss [MPEG-TS] over UDP, which makes no attempt to account for
in the transport, reordering or loss in the transport,
* RTP [RFC3550], which can notice packet loss and repair some * RTP [RFC3550], which can notice packet loss and repair some
limited reordering, limited reordering,
* SCTP [RFC9260], which can use partial reliability [RFC3758] to * the Stream Control Transmission Protocol (SCTP) [RFC9260], which
recover from some loss, but can abandon recovery to limit head-of- can use partial reliability [RFC3758] to recover from some loss
line blocking, and but can abandon recovery to limit head-of-line blocking, and
* SRT [SRT], which can use forward error correction and time-bound * the Secure Reliable Transport (SRT) [SRT], which can use forward
retransmission to recover from loss within certain limits, but can error correction and time-bound retransmission to recover from
abandon recovery to limit head-of-line blocking. loss within certain limits but can abandon recovery to limit head-
of-line blocking.
Under congestion and loss, approaches like the above generally Under congestion and loss, approaches like the above generally
experience transient media artifacts more often and delay of playback experience transient media artifacts more often and delay of playback
effects less often, as compared with reliable segment transport. effects less often, as compared with reliable segment transport.
Often one of the key goals of using a UDP-based transport that allows Often, one of the key goals of using a UDP-based transport that
some unreliability is to reduce latency and better support allows some unreliability is to reduce latency and better support
applications like videoconferencing, or for other live-action video applications like videoconferencing or other live-action video with
with interactive components, such as some sporting events. interactive components, such as some sporting events.
Congestion avoidance strategies for deployments using unreliable Congestion avoidance strategies for deployments using unreliable
transport protocols vary widely in practice, ranging from being transport protocols vary widely in practice, ranging from being
entirely unresponsive to congestion, to using feedback signaling to entirely unresponsive to responding by using strategies, including:
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 to allow less bandwidth-intensive media
such as audio to be delivered.
RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own * feedback signaling to change encoder settings (as in [RFC5762]),
feedback mechanism, and even includes Circuit Breakers for Unicast
RTP Sessions [RFC8083] for situations when normal RTP congestion
control has not been able to react sufficiently to RTP flows sending
at rates that result in sustained packet loss.
The notion of "Circuit Breakers" has also been applied to other UDP * fewer enhancement layers (as in [RFC6190]), and
* proprietary methods to detect QoE issues and turn off video to
allow less bandwidth-intensive media, such as audio, to be
delivered.
RTP relies on RTCP sender and receiver reports [RFC3550] as its own
feedback mechanism and even includes circuit breakers for unicast RTP
sessions [RFC8083] for situations when normal RTP congestion control
has not been able to react sufficiently to RTP flows sending at rates
that result in sustained packet loss.
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,
"Encapsulating MPLS in UDP," as described in [RFC7510]). If "encapsulating MPLS in UDP", as described in [RFC7510]). If
streaming media segments are carried in tunnels encapsulated in UDP, streaming media segments are carried in tunnels encapsulated in UDP,
these media streams may encounter "tripped circuit breakers," with these media streams may encounter "tripped circuit breakers", with
resulting user-visible impacts. resulting user-visible impacts.
6.3. QUIC and Changing Transport Protocol Behavior 6.3. QUIC and Changing Transport Protocol 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], behaves differently than the
in Section 6.1 and Section 6.2 on their heads. transport protocols characterized in Sections 6.1 and 6.2.
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
network operators may be using to troubleshoot HTTP streaming media operators may be using to troubleshoot HTTP streaming media
performance issues, perform analytics, or even intercept exchanges in performance issues, perform analytics, or even intercept exchanges in
current applications will not work for QUIC-based applications current applications will not work for QUIC-based applications
without making changes to their networks. Section 7 describes the without making changes to their networks. Section 7 describes the
implications of media encryption in more detail. implications of media encryption in more detail.
While QUIC is designed as a general-purpose transport protocol, and While QUIC is designed as a general-purpose transport protocol and
can carry different application-layer protocols, the current can carry different application-layer protocols, the current
standardized mapping is for HTTP/3 [RFC9114], which describes how standardized mapping is for HTTP/3 [RFC9114], which describes how
QUIC transport services are used for HTTP. The convention is for QUIC transport services are used for HTTP. The convention is for
HTTP/3 to run over UDP port 443 [Port443] but this is not a strict HTTP/3 to run over UDP port 443 [Port443], but this is not a strict
requirement. requirement.
When HTTP/3 is encapsulated in QUIC, which is then encapsulated in When HTTP/3 is encapsulated in QUIC, which is then encapsulated in
UDP, streaming operators (and network operators) might see UDP UDP, streaming operators (and network operators) might see UDP
traffic patterns that are similar to HTTP(S) over TCP. UDP ports may traffic patterns that are similar to HTTP(S) over TCP. UDP ports may
be blocked for any port numbers that are not commonly used, such as be blocked for any port numbers that are not commonly used, such as
UDP 53 for DNS. Even when UDP ports are not blocked and QUIC packets UDP 53 for DNS. Even when UDP ports are not blocked and QUIC packets
can flow, streaming operators (and network operators) may severely can flow, streaming operators (and network operators) may severely
rate-limit this traffic because they do not expect to see legitimate rate-limit this traffic because they do not expect to see legitimate
high-bandwidth traffic such as streaming media over the UDP ports high-bandwidth traffic, such as streaming media over the UDP ports
that HTTP/3 is using. that HTTP/3 is using.
As noted in Section 5.5.2, because TCP provides a reliable, in-order As noted in Section 5.5.2, because TCP provides a reliable, in-order
delivery service for applications, any packet loss for a TCP delivery service for applications, any packet loss for a TCP
connection causes head-of-line blocking, so that no TCP segments connection causes head-of-line blocking so that no TCP segments
arriving after a packet is lost will be delivered to the receiving arriving after a packet is lost will be delivered to the receiving
application until retransmission of the lost packet has been application until retransmission of the lost packet has been
received, allowing in-order delivery to the application to continue. received, allowing in-order delivery to the application to continue.
As described in [RFC9000], QUIC connections can carry multiple As described in [RFC9000], QUIC connections can carry multiple
streams, and when packet losses do occur, only the streams carried in streams, and when packet losses do occur, only the streams carried in
the lost packet are delayed. the lost packet are delayed.
A QUIC extension currently being specified ([RFC9221]) adds the A QUIC extension currently being specified [RFC9221] adds the
capability for "unreliable" delivery, similar to the service provided capability for "unreliable" delivery, similar to the service provided
by UDP, but these datagrams are still subject to the QUIC by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP does not. congestion avoidance measures, which UDP does not.
As noted in Section 6.1, there is an increasing interest in As noted in Section 6.1, there is an increasing interest in
congestion control algorithms that respond to delay measurements, congestion control algorithms that respond to delay measurements
instead of responding to packet loss. These algorithms may deliver instead of responding to packet loss. These algorithms may deliver
an improved user experience, but in some cases, have not responded to an improved user experience, but in some cases, they have not
sustained packet loss, which exhausts available buffers along the responded to sustained packet loss, which exhausts available buffers
end-to-end path that may affect other users sharing that path. The along the end-to-end path that may affect other users sharing that
QUIC protocol provides a set of congestion control hooks that can be path. The QUIC protocol provides a set of congestion control hooks
used for algorithm agility, and [RFC9002] defines a basic congestion that can be used for algorithm agility, and [RFC9002] defines a basic
control algorithm that is roughly similar to TCP NewReno [RFC6582]. congestion control algorithm that is roughly similar to TCP NewReno
[RFC6582]. However, QUIC senders can and do unilaterally choose to
However, QUIC senders can and do unilaterally choose to use different use different algorithms, such as loss-based CUBIC [RFC8312], delay-
algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or based Copa or BBR, or even something completely different.
BBR, or even something completely different.
The Internet community does have experience with deploying new The Internet community does have experience with deploying new
congestion controllers without causing congestion collapse on the congestion controllers without causing congestion collapse on the
Internet. As noted in [RFC8312], both the CUBIC congestion Internet. As noted in [RFC8312], both the CUBIC congestion
controller and its predecessor BIC have significantly different controller and its predecessor BIC have significantly different
behavior from Reno-style congestion controllers such as TCP NewReno behavior from Reno-style congestion controllers, such as TCP NewReno
[RFC6582], both were added to the Linux kernel to allow [RFC6582]; both were added to the Linux kernel to allow
experimentation and analysis, and both were then selected as the experimentation and analysis, both were then selected as the default
default TCP congestion controllers in Linux, and both were deployed TCP congestion controllers in Linux, and both were deployed globally.
globally.
The point mentioned in Section 6.1 about TCP congestion controllers The point mentioned in Section 6.1 about TCP congestion controllers
being implemented in operating system kernels is different with QUIC. being implemented in operating system kernels is different with QUIC.
Although QUIC can be implemented in operating system kernels, one of Although QUIC can be implemented in operating system kernels, one of
the design goals when this work was chartered was "QUIC is expected the design goals when this work was chartered was "QUIC is expected
to support rapid, distributed development and testing of features," to support rapid, distributed development and testing of features";
and to meet this expectation, many implementers have chosen to to meet this expectation, many implementers have chosen to implement
implement QUIC in user space, outside the operating system kernel, QUIC in user space, outside the operating system kernel, and to even
and to even distribute QUIC libraries with their own applications. distribute QUIC libraries with their own applications. It is worth
It is worth noting that streaming operators using HTTP/3, carried noting that streaming operators using HTTP/3, carried over QUIC, can
over QUIC, can expect more frequent deployment of new congestion expect more frequent deployment of new congestion controller behavior
controller behavior than has been the case with HTTP/1 and HTTP/2, than has been the case with HTTP/1 and HTTP/2, carried over TCP.
carried over TCP.
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.
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 or other object sort of Digital Rights Management (DRM) system or other object
encryption/security mechanism, and typically remaining encrypted encryption/security mechanism and typically remaining encrypted at
at rest, when senders and receivers store it. rest when senders and receivers store it.
* Media encrypted by the sender at the transport layer, and * Media encrypted by the sender at the transport layer and remaining
remaining encrypted until it reaches the ultimate media consumer encrypted until it reaches the ultimate media consumer (in this
(in this document, referred to as end-to-end media encryption). document, it is 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
remaining encrypted until it reaches some intermediary that is encrypted until it reaches some intermediary that is _not_ the
_not_ the ultimate media consumer, but has credentials allowing ultimate media consumer but has credentials allowing decryption of
decryption of the media content. This intermediary may examine the media content. This intermediary may examine and even
and even transform the media content in some way, before transform the media content in some way, before forwarding re-
forwarding re-encrypted media content (in this document referred encrypted media content (in this document, it is referred to as
to as hop-by-hop media encryption). hop-by-hop media encryption).
This document focuses on media encrypted at the transport layer, This document focuses on media encrypted at the transport layer,
whether encryption is performed hop-by-hop or end-to-end. Because whether encryption is performed hop by hop or end to end. Because
media encrypted at the application layer will only be processed by media encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport- application-level entities, this encryption does not have transport-
layer implications. Of course, both hop-by-hop and end-to-end layer implications. Of course, both hop-by-hop and end-to-end
encrypted transport may carry media that is, in addition, encrypted encrypted transport may carry media that is, in addition, encrypted
at the application layer. 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 stream manipulation or to protect may be used to prevent media stream 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.
Both end-to-end and hop-by-hop media encryption have specific 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. Sections 7.2 and 7.3.
7.1. General Considerations for Streaming Media Encryption 7.1. General Considerations for Streaming 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 the ultimate encrypted streaming media, from the sender to either the ultimate
media consumer, or to an intermediary that possesses credentials media consumer or to an intermediary that possesses credentials
allowing decryption. This does prevent Deep Packet Inspection by any allowing decryption. This does prevent deep packet inspection (DPI)
on-path intermediary that does not possess credentials allowing by any on-path intermediary that does not possess credentials
decryption. However, even encrypted content streams may be allowing decryption. However, even encrypted content streams may be
vulnerable to traffic analysis. An on-path observer that can vulnerable to traffic analysis. An on-path observer that can
identify that encrypted traffic contains a media stream, could identify that encrypted traffic contains a media stream could
"fingerprint" this encrypted media steam, and then compare it against "fingerprint" this encrypted media stream and then compare it against
"fingerprints" of known content. The protection provided by strong "fingerprints" of known content. The protection provided by strong
encryption can be further lessened if a streaming media operator is encryption can be further lessened if a streaming media operator is
repeatedly encrypting the same content. "Identifying HTTPS-Protected repeatedly encrypting the same content. "Identifying HTTPS-Protected
Netflix Videos in Real-Time" ([CODASPY17]) is an example of what is Netflix Videos in Real-Time" [CODASPY17] is an example of what is
possible when identifying HTTPS-protected videos over TCP transport, possible when identifying HTTPS-protected videos over TCP transport,
based either on the length of entire resources being transferred, or based either on the length of entire resources being transferred or
on characteristic packet patterns at the beginning of a resource on characteristic packet patterns at the beginning of a resource
being transferred. If traffic analysis is successful at identifying being transferred. If traffic analysis is successful at identifying
encrypted content and associating it with specific users, this tells encrypted content and associating it with specific users, this tells
an on-path observer what resource is being streamed, and by who, an on-path observer what resource is being streamed, and by who,
almost as certainly as examining decrypted traffic. almost as certainly as examining decrypted traffic.
Because HTTPS has historically layered HTTP on top of TLS, which is Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries have historically had in turn layered on top of TCP, intermediaries have historically had
access to unencrypted TCP-level transport information, such as access to unencrypted TCP-level transport information, such as
retransmissions, and some carriers exploited this information in retransmissions, and some carriers exploited this information in
attempts to improve transport-layer performance [RFC3135]. The most attempts to improve transport-layer performance [RFC3135]. The most
recent standardized version of HTTPS, HTTP/3 [RFC9114], uses the QUIC recent standardized version of HTTPS, HTTP/3 [RFC9114], uses the QUIC
protocol [RFC9000] as its transport layer. QUIC relies on the TLS protocol [RFC9000] as its transport layer. QUIC relies on the TLS
1.3 initial handshake [RFC8446] only for key exchange [RFC9001], and 1.3 initial handshake [RFC8446] only for key exchange [RFC9001] and
encrypts almost all transport parameters itself except for a few encrypts almost all transport parameters itself, except for 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 that 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 the manageability of the QUIC [RFC9312] discusses the manageability of the QUIC transport protocol
transport protocol that is used to encapsulate HTTP/3, focusing on that is used to encapsulate HTTP/3, focusing on the implications of
the implications of QUIC's design and wire image on network QUIC's design and wire image on network operations involving QUIC
operations involving QUIC traffic. It discusses what network traffic. It discusses what network operators can consider in some
operators can consider in some detail. detail.
More broadly, RFC 9065 [RFC9065], "Considerations around Transport More broadly, "Considerations around Transport Header
Header Confidentiality, Network Operations, and the Evolution of Confidentiality, Network Operations, and the Evolution of Internet
Internet Transport Protocols" describes the impact of increased Transport Protocols" [RFC9065] describes the impact of increased
encryption of transport headers in general terms. encryption of transport headers in general terms.
It is also worth noting that considerations for heavily-encrypted It is also worth noting that considerations for heavily encrypted
transport protocols also come into play when streaming media is transport protocols also come into play when streaming media is
carried over IP-level VPNs and tunnels, with the additional carried over IP-level VPNs and tunnels, with the additional
consideration that an intermediary that does not possess credentials consideration that an intermediary that does not possess credentials
allowing decryption will not have visibility to the source and allowing decryption will not have visibility to the source and
destination IP addresses of the packets being carried inside the destination IP addresses of the packets being carried inside the
tunnel. tunnel.
7.2. Considerations for Hop-by-Hop Media Encryption 7.2. Considerations for Hop-by-Hop Media Encryption
Hop-by-hop media encryption offers the benefits described in Hop-by-hop media encryption offers the benefits described in
Section 7.1 between the streaming media operator and authorized Section 7.1 between the streaming media operator and authorized
intermediaries, among authorized intermediaries, and between intermediaries, among authorized intermediaries, and between
authorized intermediaries and the ultimate media consumer, but does authorized intermediaries and the ultimate media consumer; however,
not provide these benefits end-to-end. The streaming media operator it does not provide these benefits end to end. The streaming media
and ultimate media consumer must trust the authorized intermediaries, operator and ultimate media consumer must trust the authorized
and if these intermediaries cannot be trusted, the benefits of intermediaries, and if these intermediaries cannot be trusted, the
encryption are lost. benefits of encryption are lost.
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 streaming media operator's perspective, a number of From a streaming media operator's perspective, a number of
considerations are in play. The first question is likely whether the considerations are in play. The first question is likely whether the
streaming media operator intends that intermediaries are explicitly streaming media operator intends that intermediaries are explicitly
addressed from endpoints, or whether the streaming media operator is addressed from endpoints or whether the streaming media operator is
willing to allow intermediaries to "intercept" streaming content willing to allow intermediaries to "intercept" streaming content
transparently, with no awareness or permission from either endpoint. transparently, with no awareness or permission from either endpoint.
If a streaming media operator does not actively work to avoid If a streaming media operator does not actively work to avoid
interception by on-path intermediaries, the effect will be interception by on-path intermediaries, the effect will be
indistinguishable from "impersonation attacks," and endpoints cannot indistinguishable from "impersonation attacks", and endpoints cannot
be assured of any level of confidentiality, and cannot trust that the be assured of any level of confidentiality and cannot trust that the
content received came from the expected sender. content received came from the expected sender.
Assuming that a streaming media operator does intend to allow Assuming that a streaming media operator does intend to allow
intermediaries to participate in content streaming and does intend to intermediaries to participate in content streaming and does intend to
provide some level of privacy for endpoints, there are a number of provide some level of privacy for endpoints, there are a number of
possible tools, either already available or still being specified. possible tools, either already available or still being specified.
These include These include the following:
* Server And Network assisted DASH [MPEG-DASH-SAND] - this Server and Network Assisted DASH [MPEG-DASH-SAND]:
specification introduces explicit messaging between DASH clients This specification introduces explicit messaging between DASH
and DASH-aware network elements or among various DASH-aware clients and DASH-aware network elements or among various DASH-
network elements, for the purpose of improving the efficiency of aware network elements for the purpose of improving the efficiency
streaming sessions by providing information about real-time of streaming sessions by providing information about real-time
operational characteristics of networks, servers, proxies, caches, operational characteristics of networks, servers, proxies, caches,
CDNs, as well as DASH client's performance and status. CDNs, as well as a DASH client's performance and status.
* "Double Encryption Procedures for the Secure Real-Time Transport "Double Encryption Procedures for the Secure Real-Time Transport
Protocol (SRTP)" [RFC8723] - this specification provides a Protocol (SRTP)" [RFC8723]:
cryptographic transform for the Secure Real-time Transport This specification provides a cryptographic transform for the SRTP
Protocol that provides both hop-by-hop and end-to-end security that provides both hop-by-hop and end-to-end security guarantees.
guarantees.
* Secure Media Frames [SFRAME] - [RFC8723] is closely tied to SRTP, Secure Frames [SFRAME]:
and this close association impeded widespread deployment, because [RFC8723] is closely tied to SRTP, and this close association
it could not be used for the most common media content delivery impeded widespread deployment, because it could not be used for
mechanisms. A more recent proposal, Secure Media Frames [SFRAME], the most common media content delivery mechanisms. A more recent
also provides both hop-by-hop and end-to-end security guarantees, proposal, Secure Frames [SFRAME], also provides both hop-by-hop
but can be used with other media transport protocols beyond SRTP. and end-to-end security guarantees but can be used with other
media transport protocols beyond SRTP.
A streaming media operator's choice of whether to involve A streaming media operator's choice of whether to involve
intermediaries requires careful consideration. As an example, when intermediaries requires careful consideration. As an example, when
ABR manifests were commonly sent unencrypted, some access network ABR manifests were commonly sent unencrypted, some access network
operators would modify manifests during peak hours by removing high- operators would modify manifests during peak hours by removing high-
bitrate renditions to prevent players from choosing those renditions, bitrate renditions to prevent players from choosing those renditions,
thus reducing the overall bandwidth consumed for delivering these thus reducing the overall bandwidth consumed for delivering these
media streams and thereby improving the network load and the user media streams and thereby reducing the network load and improving the
experience for their customers. Now that ubiquitous encryption average user experience for their customers. Now that ubiquitous
typically prevents this kind of modification, a streaming media encryption typically prevents this kind of modification, a streaming
operator who used intermediaries in the past, and who now wishes to media operator who used intermediaries in the past, and who now
maintain the same level of network health and user experience, must wishes to maintain the same level of network health and user
choose between adding intermediaries who are authorized to change the experience, must choose between adding intermediaries who are
manifests or adding some other form of complexity to their service. authorized to change the manifests or adding some other form of
complexity to their service.
Some resources that might inform other similar considerations are Some resources that might inform other similar considerations are
further discussed in [RFC8824] (for WebRTC) and further discussed in [RFC8824] (for WebRTC) and [RFC9312] (for HTTP/3
[I-D.ietf-quic-manageability] (for HTTP/3 and QUIC). 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 benefits described in End-to-end media encryption offers the benefits described in
Section 7.1 from the streaming media operator to the ultimate media Section 7.1 from the streaming media operator to the ultimate media
consumer. consumer.
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.
However, as noted in [RFC7258], there is no way to prevent pervasive However, as noted in [RFC7258], there is no way to prevent pervasive
monitoring by an attacker, while allowing monitoring by a more benign monitoring by an attacker while allowing monitoring by a more benign
entity who only wants to use DPI to examine HTTP requests and entity who only wants to use DPI to examine HTTP requests and
responses to provide a better user experience. If a modern encrypted responses to provide a better user experience. If a modern encrypted
transport protocol is used for end-to-end media encryption, transport protocol is used for end-to-end media encryption,
unauthorized on-path intermediaries are unable to examine transport unauthorized on-path intermediaries are unable to examine transport
and application protocol behavior. As described in Section 7.2, only and application protocol behavior. As described in Section 7.2, only
an intermediary explicitly authorized by the streaming media operator an intermediary explicitly authorized by the streaming media operator
who is to examine packet payloads, rather than intercepting packets who is to examine packet payloads, rather than intercepting packets
and examining them without authorization, can continue these and examining them without authorization, can continue these
practices. practices.
[RFC7258] said that "The IETF will strive to produce specifications [RFC7258] states that "[t]he IETF will strive to produce
that mitigate pervasive monitoring attacks," so streaming operators specifications that mitigate pervasive monitoring attacks", so
should expect the IETF's direction toward preventing unauthorized streaming operators should expect the IETF's direction toward
monitoring of IETF protocols to continue for the foreseeable future. preventing unauthorized monitoring of IETF protocols to continue for
the foreseeable future.
8. Further Reading and References
The MOPS community maintains a list of references and resources for
further reading at this location:
* https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- 8. Additional Resources for Streaming Media
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)
Editor's note: The URL above might or might not be changed during The Media Operations (MOPS) community maintains a list of references
IESG Evaluation. See https://github.com/ietf-wg-mops/draft-ietf- and resources; for further reading, see [MOPS-RESOURCES].
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 has no IANA actions.
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
the topic of media encryption was explained in Section 7. This the topic of media encryption was explained in Section 7. This
document itself introduces no new security issues. document itself introduces no new security issues.
11. Acknowledgments 11. Informative References
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,
Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan
Krishna, Roni Even, Sanjay Mishra, Kiran Makhjani, Chris Lemmons,
Tommy Pauly, Will Law, Michael Scharf, Eric Vyncke, Erik Kline, Roman
Danyliw, Valery Smyslov, Robert Wilton, Lars Eggert, Zahed Sarker,
Warren Kumari, John Scudder, Martin Duke, and Nancy Cam-Winget for
very helpful suggestions, reviews and comments.
12. Informative References
[ABRSurvey] [ABRSurvey]
Taani, B., Begen, A. C., Timmerer, C., Zimmermann, R., and Bentaleb, A., Taani, B., Begen, A. C., Timmerer, C., and
A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes R. Zimmermann, "A survey on bitrate adaptation schemes for
for Streaming Media Over HTTP", IEEE Communications streaming media over HTTP", IEEE Communications Surveys &
Surveys & Tutorials , 2019, Tutorials, vol. 21/1, pp. 562-585, Firstquarter 2019,
<https://ieeexplore.ieee.org/abstract/document/8424813>. DOI 10.1109/COMST.2018.2862938,
<https://doi.org/10.1109/COMST.2018.2862938>.
[ADFRAUD] Sadeghpour, S. and N. Vlajic, "Ads and Fraud: A [ADFRAUD] Sadeghpour, S. and N. Vlajic, "Ads and Fraud: A
Comprehensive Survey of Fraud in Online Advertising", Comprehensive Survey of Fraud in Online Advertising",
Journal of Cybersecurity and Privacy 1, no. 4: 804-832. , Journal of Cybersecurity and Privacy 1, no. 4, pp.
16 December 2021, <https://doi.org/10.3390/jcp1040039>. 804-832, DOI 10.3390/jcp1040039, December 2021,
<https://doi.org/10.3390/jcp1040039>.
[BALANCING] [BALANCING]
Berger, D. D., "Balancing Consumer Privacy with Behavioral Berger, D., "Balancing Consumer Privacy with Behavioral
Targeting", 27 Santa Clara High Technology Law Journal, Targeting", Santa Clara High Technology Law Journal, Vol.
Vol. 27 Issue 1 Article 2 , 2010, 27, Issue 1, Article 2, 2010,
<https://digitalcommons.law.scu.edu/chtlj/vol27/iss1/2/>. <https://digitalcommons.law.scu.edu/chtlj/vol27/iss1/2/>.
[BAP] "The Coalition for Better Ads", n.d., [BAP] Coalition for Better Ads, "Making Online Ads Better for
<https://www.betterads.org/>. Everyone", <https://www.betterads.org/>.
[BBR-CONGESTION-CONTROL]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-02, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-02>.
[BEHAVE] Yan, J., Liu, N., Wang, G., Zhang, W., Jiang, Y., and Z. [BEHAVE] Yan, J., Liu, N., Wang, G., Zhang, W., Jiang, Y., and Z.
Chen, "How much can behavioral targeting help online Chen, "How much can behavioral targeting help online
advertising?", WWW '09: Proceedings of the 18th advertising?", WWW '09: Proceedings of the 18th
international conference on World wide webApril 2009 Pages international conference on World wide web, pp. 261-270,
261-270 , 20 April 2009, DOI 10.1145/1526709.1526745, April 2009,
<https://dl.acm.org/doi/abs/10.1145/1526709.1526745>. <https://dl.acm.org/doi/abs/10.1145/1526709.1526745>.
[BEHAVE2] Goldfarb, A. and C. E. Tucker, "Online advertising, [BEHAVE2] Goldfarb, A. and C. E. Tucker, "Online advertising,
behavioral targeting, and privacy", Communications of the behavioral targeting, and privacy", Communications of the
ACMVolume 54Issue 5May 2011 pp 25-27 , 1 May 2011, ACM, Volume 54, Issue 5, pp. 25-27,
DOI 10.1145/1941487.1941498, May 2011,
<https://dl.acm.org/doi/abs/10.1145/1941487.1941498>. <https://dl.acm.org/doi/abs/10.1145/1941487.1941498>.
[CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked- [CMAF-CTE] Bentaleb, A., Akcay, M., Lim, M., Begen, A., and R.
Encoded and Chunked Transferred CMAF", October 2018, Zimmermann, "Catching the Moment With LoL+ in Twitch-Like
<https://www.akamai.com/us/en/multimedia/documents/white- Low-Latency Live Streaming Platforms", IEEE Trans.
paper/low-latency-streaming-cmaf-whitepaper.pdf>. Multimedia, Vol. 24, pp. 2300-2314,
DOI 10.1109/TMM.2021.3079288, May 2021,
<https://doi.org/10.1109/TMM.2021.3079288>.
[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,
DOI 10.1145/3029806.3029821, March 2017,
<https://dl.acm.org/doi/10.1145/3029806.3029821>. <https://dl.acm.org/doi/10.1145/3029806.3029821>.
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", [CoDel] Nichols, K. and V. Jacobson, "Controlling queue delay",
Communications of the ACM, Volume 55, Issue 7, pp. 42-50 , Communications of the ACM, Volume 55, Issue 7, pp. 42-50",
July 2012. DOI 10.1145/2209249.2209264, July 2012,
<https://doi.org/10.1145/2209249.2209264>.
[COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based [COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based
Congestion Control for the Internet", USENIX NSDI , April Congestion Control for the Internet", USENIX NSDI, April
2018, <https://web.mit.edu/copa/>. 2018, <https://web.mit.edu/copa/>.
[CTA-2066] Consumer Technology Association, "Streaming Quality of [CTA-2066] Consumer Technology Association, "Streaming Quality of
Experience Events, Properties and Metrics", March 2020, Experience Events, Properties and Metrics", CTA-2066,
<https://shop.cta.tech/products/streaming-quality-of- March 2020, <https://shop.cta.tech/products/streaming-
experience-events-properties-and-metrics>. quality-of-experience-events-properties-and-metrics>.
[CTA-5004] CTA, "Common Media Client Data (CMCD)", September 2020, [CTA-5004] Consumer Technology Association, "Web Application Video
<https://shop.cta.tech/products/web-application-video- Ecosystem - Common Media Client Data", CTA-5004, September
ecosystem-common-media-client-data-cta-5004>. 2020, <https://shop.cta.tech/products/web-application-
video-ecosystem-common-media-client-data-cta-5004>.
[CVNI] "Cisco VNI Forecast update", June 2019, [CVNI] Cisco, "Cisco Visual Networking Index: Forecast and
<https://www.ieee802.org/3/ad_hoc/bwa2/public/ Trends, 2017–2022", 2018.
calls/19_0624/nowell_bwa_01_190624.pdf>.
[ELASTIC] De Cicco, L., Caldaralo, V., Palmisano, V., and S. [ELASTIC] De Cicco, L., Caldaralo, V., Palmisano, V., and S.
Mascolo, "ELASTIC: A client-side controller for dynamic Mascolo, "ELASTIC: A Client-Side Controller for Dynamic
adaptive streaming over HTTP (DASH)", Packet Video Adaptive Streaming over HTTP (DASH)", Packet Video
Workshop , December 2013, Workshop, DOI 10.1109/PV.2013.6691442, December 2013,
<https://ieeexplore.ieee.org/document/6691442>. <https://ieeexplore.ieee.org/document/6691442>.
[Encodings] [Encodings]
Apple, Inc, "HLS Authoring Specification for Apple Apple Developer, "HTTP Live Streaming (HLS) Authoring
Devices", June 2020, Specification for Apple 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] [HLS-RFC8216BIS]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V. Pantos, R., Ed., "HTTP Live Streaming 2nd Edition", Work
Jacobson, "BBR Congestion Control", Work in Progress, in Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-
Internet-Draft, draft-cardwell-iccrg-bbr-congestion- 11, 11 May 2022, <https://www.ietf.org/archive/id/draft-
control-02, 7 March 2022, pantos-hls-rfc8216bis-11.txt>.
<https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-02>.
[I-D.draft-pantos-hls-rfc8216bis]
Pantos, R., "HTTP Live Streaming 2nd Edition", Work in
Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-11,
11 May 2022, <https://datatracker.ietf.org/doc/html/draft-
pantos-hls-rfc8216bis-11>.
[I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-18, 15 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-18>.
[I-D.ietf-tcpm-rfc793bis]
Eddy, W. M., "Transmission Control Protocol (TCP)
Specification", Work in Progress, Internet-Draft, draft-
ietf-tcpm-rfc793bis-28, 7 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-
rfc793bis-28>.
[IAB-ADS] "IAB", n.d., <https://www.iab.com/>. [IAB-ADS] "IAB", <https://www.iab.com/>.
[ISOBMFF] "ISO/IEC 14496-12:2022 Information technology - Coding of [ISOBMFF] ISO, "Information technology - Coding of audio-visual
audio-visual objects - Part 12: ISO base media file objects - Part 12: ISO base media file format", ISO/
format", January 2022, IEC 14496-12:2022, January 2022,
<https://www.iso.org/standard/83102.html>. <https://www.iso.org/standard/83102.html>.
[Jacobson-Karels] [Jacobson-Karels]
Jacobson, V. and M. Karels, "Congestion Avoidance and Jacobson, V. and M. Karels, "Congestion Avoidance and
Control", November 1988, Control", November 1988,
<https://ee.lbl.gov/papers/congavoid.pdf>. <https://ee.lbl.gov/papers/congavoid.pdf>.
[LL-DASH] DASH-IF, "Low-latency Modes for DASH", March 2020, [LL-DASH] DASH-IF, "Low-latency Modes for DASH", March 2020,
<https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>. <https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>.
[Micro] Taher, T. M., Misurac, M. J., LoCicero, J. L., and D. R. [Micro] Taher, T. M., Misurac, M. J., LoCicero, J. L., and D. R.
Ucci, "Microwave Oven Signal Interference Mitigation For Ucci, "Microwave Oven Signal Interference Mitigation For
Wi-Fi Communication Systems", 2008 5th IEEE Consumer Wi-Fi Communication Systems", 2008 5th IEEE Consumer
Communications and Networking Conference 5th IEEE, pp. Communications and Networking Conference, pp. 67-68,
67-68 , 2008. DOI 10.1109/ccnc08.2007.21, January 2008,
<https://doi.org/10.1109/ccnc08.2007.21>.
[MMSP20] Durak, K. and et al, "Evaluating the performance of [MMSP20] Durak, K. et al., "Evaluating the Performance of Apple's
Apple's low-latency HLS", IEEE MMSP , September 2020, Low-Latency HLS", IEEE MMSP,
DOI 10.1109/MMSP48831.2020.9287117, September 2020,
<https://ieeexplore.ieee.org/document/9287117>. <https://ieeexplore.ieee.org/document/9287117>.
[MMSys11] Akhshabi, S., Begen, A. C., and C. Dovrolis, "An [MMSys11] Akhshabi, S., Begen, A. C., and C. Dovrolis, "An
experimental evaluation of rate-adaptation algorithms in experimental evaluation of rate-adaptation algorithms in
adaptive streaming over HTTP", ACM MMSys , February 2011, adaptive streaming over HTTP", ACM MMSys,
DOI 10.1145/1943552.1943574, February 2011,
<https://dl.acm.org/doi/10.1145/1943552.1943574>. <https://dl.acm.org/doi/10.1145/1943552.1943574>.
[MOPS-RESOURCES]
"rfc9317-additional-resources", September 2022,
<https://wiki.ietf.org/group/mops/rfc9317-additional-
resources>.
[MPEG-CMAF] [MPEG-CMAF]
"ISO/IEC 23000-19:2020 Multimedia application format ISO, "Information technology - Multimedia application
(MPEG-A) - Part 19: Common media application format (CMAF) format (MPEG-A) - Part 19: Common media application format
for segmented media", March 2020, (CMAF) for segmented media", ISO/IEC 23000-19:2020, March
<https://www.iso.org/standard/79106.html>. 2020, <https://www.iso.org/standard/79106.html>.
[MPEG-DASH] [MPEG-DASH]
"ISO/IEC 23009-1:2019 Dynamic adaptive streaming over HTTP ISO, "Information technology - Dynamic adaptive streaming
(DASH) - Part 1: Media presentation description and over HTTP (DASH) - Part 1: Media presentation description
segment formats", December 2019, and segment formats", ISO/IEC 23009-1:2022, August 2022,
<https://www.iso.org/standard/79329.html>. <https://www.iso.org/standard/83314.html>.
[MPEG-DASH-SAND] [MPEG-DASH-SAND]
"ISO/IEC 23009-5:2017 Dynamic adaptive streaming over HTTP ISO, "Information technology - Dynamic adaptive streaming
(DASH) - Part 5: Server and network assisted DASH (SAND)", over HTTP (DASH) - Part 5: Server and network assisted
February 2017, <https://www.iso.org/standard/69079.html>. DASH (SAND)", ISO/IEC 23009-5:2017, February 2017,
<https://www.iso.org/standard/69079.html>.
[MPEG-TS] "H.222.0 : Information technology - Generic coding of [MPEG-TS] ITU-T, "Information technology - Generic coding of moving
moving pictures and associated audio information: pictures and associated audio information: Systems", ITU-T
Systems", 29 August 2018, Recommendation H.222.0, June 2021,
<https://www.itu.int/rec/T-REC-H.222.0>. <https://www.itu.int/rec/T-REC-H.222.0>.
[MPEGI] Boyce, J. M. and et al, "MPEG Immersive Video Coding [MPEGI] Boyce, J. M. et al., "MPEG Immersive Video Coding
Standard", Proceedings of the IEEE , n.d., Standard", Proceedings of the IEEE, Vol. 109, Issue 9, pp.
1521-1536, DOI 10.1109/JPROC.2021.3062590,
<https://ieeexplore.ieee.org/document/9374648>. <https://ieeexplore.ieee.org/document/9374648>.
[OReilly-HPBN] [OReilly-HPBN]
"High Performance Browser Networking (Chapter 2: Building Grigorik, I., "High Performance Browser Networking -
Blocks of TCP)", May 2021, Chapter 2: Building Blocks of TCP", May 2021,
<https://hpbn.co/building-blocks-of-tcp/>. <https://hpbn.co/building-blocks-of-tcp/>.
[PCC] Schwarz, S. and et al, "Emerging MPEG Standards for Point [PCC] Schwarz, S. et al., "Emerging MPEG Standards for Point
Cloud Compression", IEEE Journal on Emerging and Selected Cloud Compression", IEEE Journal on Emerging and Selected
Topics in Circuits and Systems , March 2019, Topics in Circuits and Systems,
DOI 10.1109/JETCAS.2018.2885981, March 2019,
<https://ieeexplore.ieee.org/document/8571288>. <https://ieeexplore.ieee.org/document/8571288>.
[Port443] "Service Name and Transport Protocol Port Number [Port443] IANA, "Service Name and Transport Protocol Port Number
Registry", April 2021, <https://www.iana.org/assignments/ Registry", <https://www.iana.org/assignments/service-
service-names-port-numbers/service-names-port- names-port-numbers>.
numbers.txt>.
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001, Retransmit, and Fast Recovery Algorithms", RFC 2001,
DOI 10.17487/RFC2001, January 1997, DOI 10.17487/RFC2001, January 1997,
<https://www.rfc-editor.org/rfc/rfc2001>. <https://www.rfc-editor.org/info/rfc2001>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, Payload Format Specifications", BCP 36, RFC 2736,
DOI 10.17487/RFC2736, December 1999, DOI 10.17487/RFC2736, December 1999,
<https://www.rfc-editor.org/rfc/rfc2736>. <https://www.rfc-editor.org/info/rfc2736>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001, DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/rfc/rfc3135>. <https://www.rfc-editor.org/info/rfc3135>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/rfc/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/rfc/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
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/info/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/info/rfc4733>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/rfc/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[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/info/rfc5594>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/rfc/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[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/info/rfc5762>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<https://www.rfc-editor.org/rfc/rfc6190>. <https://www.rfc-editor.org/info/rfc6190>.
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
NewReno Modification to TCP's Fast Recovery Algorithm", NewReno Modification to TCP's Fast Recovery Algorithm",
RFC 6582, DOI 10.17487/RFC6582, April 2012, RFC 6582, DOI 10.17487/RFC6582, April 2012,
<https://www.rfc-editor.org/rfc/rfc6582>. <https://www.rfc-editor.org/info/rfc6582>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/rfc/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Delay Metric (RTCP) Extended Report (XR) Block for Delay Metric
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
<https://www.rfc-editor.org/rfc/rfc6843>. <https://www.rfc-editor.org/info/rfc6843>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/rfc/rfc7414>. <https://www.rfc-editor.org/info/rfc7414>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/rfc/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<https://www.rfc-editor.org/rfc/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661, TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015, DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/rfc/rfc7661>. <https://www.rfc-editor.org/info/rfc7661>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/rfc/rfc8083>. <https://www.rfc-editor.org/info/rfc8083>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/rfc/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/rfc/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017, RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/rfc/rfc8216>. <https://www.rfc-editor.org/info/rfc8216>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018, RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/rfc/rfc8312>. <https://www.rfc-editor.org/info/rfc8312>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404, Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, DOI 10.17487/RFC8404, July 2018,
<https://www.rfc-editor.org/rfc/rfc8404>. <https://www.rfc-editor.org/info/rfc8404>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[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/info/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/info/rfc8723>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824, Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021, DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/rfc/rfc8824>. <https://www.rfc-editor.org/info/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/info/rfc8825>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/rfc/rfc8834>. January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835,
DOI 10.17487/RFC8835, January 2021, DOI 10.17487/RFC8835, January 2021,
<https://www.rfc-editor.org/rfc/rfc8835>. <https://www.rfc-editor.org/info/rfc8835>.
[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/info/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
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/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/info/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/info/rfc9002>.
[RFC9065] Fairhurst, G. and C. Perkins, "Considerations around [RFC9065] Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", RFC 9065, the Evolution of Internet Transport Protocols", RFC 9065,
DOI 10.17487/RFC9065, July 2021, DOI 10.17487/RFC9065, July 2021,
<https://www.rfc-editor.org/rfc/rfc9065>. <https://www.rfc-editor.org/info/rfc9065>.
[RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins, [RFC9075] Arkko, J., Farrell, 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", RFC 9075, DOI 10.17487/RFC9075, July 2021, 2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
<https://www.rfc-editor.org/rfc/rfc9075>. <https://www.rfc-editor.org/info/rfc9075>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>. <https://www.rfc-editor.org/info/rfc9111>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", RFC 9221, Datagram Extension to QUIC", RFC 9221,
DOI 10.17487/RFC9221, March 2022, DOI 10.17487/RFC9221, March 2022,
<https://www.rfc-editor.org/rfc/rfc9221>. <https://www.rfc-editor.org/info/rfc9221>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control [RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/rfc/rfc9260>. June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[SFRAME] "Secure Media Frames Working Group (Home Page)", n.d., [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
<https://datatracker.ietf.org/doc/charter-ietf-sframe/>. STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol [RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Overview", 15 April 2020, Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/info/rfc9312>.
[SFRAME] IETF, "Secure Frame (sframe)",
<https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/>.
[SRT] Sharabayko, M., "SRT Protocol Overview", 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-srt-
15-2020-mops-interim-an-update-on-streaming-video- protocol-overview-00>.
alliance>.
[Survey360o] [Survey360]
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>. Volume 22, Issue 4, DOI 10.1109/COMST.2020.3006999, July
2020, <https://ieeexplore.ieee.org/document/9133103>.
Acknowledgments
Thanks to Nancy Cam-Winget, Leslie Daigle, Roman Danyliw, Glenn Deen,
Martin Duke, Linda Dunbar, Lars Eggert, Mike English, Roni Even,
Aaron Falk, Alexandre Gouaillard, Erik Kline, Renan Krishna, Warren
Kumari, Will Law, Chris Lemmons, Kiran Makhjani, Sanjay Mishra, Mark
Nottingham, Dave Oran, Lucas Pardue, Tommy Pauly, Kyle Rose, Zahed
Sarker, Michael Scharf, John Scudder, Valery Smyslov, Matt Stock,
Éric Vyncke, and Robert Wilton for very helpful suggestions, reviews,
and comments.
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
Networked Media Networked Media
Turkey Turkey
Email: ali.begen@networked.media Email: ali.begen@networked.media
Spencer Dawkins Spencer Dawkins
Tencent America LLC Tencent America LLC
United States of America United States of America
Email: spencerdawkins.ietf@gmail.com Email: spencerdawkins.ietf@gmail.com
 End of changes. 296 change blocks. 
759 lines changed or deleted 732 lines changed or added

This html diff was produced by rfcdiff 1.48.