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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/