< draft-ietf-mops-streaming-opcons-07.txt   draft-ietf-mops-streaming-opcons-08.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: 19 March 2022 Networked Media Expires: 15 July 2022 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
15 September 2021 11 January 2022
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-07 draft-ietf-mops-streaming-opcons-08
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 in streaming of 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 19 March 2022. This Internet-Draft will expire on 15 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 . . . . . . . 5
1.1.2. History of Public Discussion . . . . . . . . . . . . 5 2. Our Focus on Streaming Video . . . . . . . . . . . . . . . . 5
2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6 3. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6
2.1. Scaling Requirements for Media Delivery . . . . . . . . . 6 3.1. Scaling Requirements for Media Delivery . . . . . . . . . 6
2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6 3.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6
2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6 3.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 7
2.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7 3.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7
2.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8 3.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8
2.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9 3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9
2.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 9 3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 10
2.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 10 3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11
2.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11 3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11
2.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12 3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12
3. Latency Considerations . . . . . . . . . . . . . . . . . . . 13 4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14
3.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14 4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14
3.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15 4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15
3.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16 4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16
3.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Adaptive Encoding, Adaptive Delivery, and Measurement 5. Adaptive Encoding, Adaptive Delivery, and Measurement
Collection . . . . . . . . . . . . . . . . . . . . . . . 16 Collection . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 17 5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18
4.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18 5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18
4.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20 5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20
4.5.1. Idle Time between Segments . . . . . . . . . . . . . 20 5.5.1. Idle Time between Segments . . . . . . . . . . . . . 20
4.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21 5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21
4.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22 5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22
4.6. Measurement Collection . . . . . . . . . . . . . . . . . 22 5.6. Measurement Collection . . . . . . . . . . . . . . . . . 22
4.6.1. CTA-2066: Streaming Quality of Experience Events, 5.6.1. CTA-2066: Streaming Quality of Experience Events,
Properties and Metrics . . . . . . . . . . . . . . . 23 Properties and Metrics . . . . . . . . . . . . . . . 22
4.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23 5.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23
4.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 23 5.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 23
5. Evolution of Transport Protocols and Transport Protocol 6. Evolution of Transport Protocols and Transport Protocol
Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24 6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24
5.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25 6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25
5.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 26 6.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 26
6. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28 7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28
6.1. General Considerations for Media Encryption . . . . . . . 29 7.1. General Considerations for Media Encryption . . . . . . . 29
6.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30 7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30
6.3. Considerations for "End-to-End" Media Encryption . . . . 31 7.3. Considerations for "End-to-End" Media Encryption . . . . 31
7. Further Reading and References . . . . . . . . . . . . . . . 32 8. Further Reading and References . . . . . . . . . . . . . . . 32
7.1. Industry Terminology . . . . . . . . . . . . . . . . . . 32 8.1. Industry Terminology . . . . . . . . . . . . . . . . . . 32
7.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 32 8.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 32
7.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 32 8.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 32
7.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33 8.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33
7.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 33 8.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 33
7.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 33 8.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 33
7.2.5. Server/Client/Network Collaboration . . . . . . . . . 34 8.2.5. Low-Latency Live Adaptive Streaming . . . . . . . . . 34
7.2.6. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35 8.2.6. Server/Client/Network Collaboration . . . . . . . . . 34
7.2.7. Point Clouds and Immersive Media . . . . . . . . . . 35 8.2.7. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35
7.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36 8.2.8. Point Clouds and Immersive Media . . . . . . . . . . 35
7.4. Technical Events . . . . . . . . . . . . . . . . . . . . 36 8.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36
7.5. List of Organizations Working on Streaming Media . . . . 37 8.4. Technical Events . . . . . . . . . . . . . . . . . . . . 36
7.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38 8.5. List of Organizations Working on Streaming Media . . . . 37
7.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38 8.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38
7.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 38 8.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38
7.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 39 8.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 38
7.6.4. Synchronized Encoding and Packaging . . . . . . . . . 39 8.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 39
7.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 39 8.6.4. Synchronized Encoding and Packaging . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . . . . 40 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
12. Informative References . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
As the internet has grown, an increasingly large share of the traffic This document examines networking issues as they relate to quality of
delivered to end users has become video. Estimates put the total experience in Internet media delivery, especially focusing on
share of internet video traffic at 75% in 2019, expected to grow to capturing characteristics of streaming video delivery that have
82% by 2022. This estimate projects the gross volume of video surprised network designers or transport experts who lack specific
traffic will more than double during this time, based on a compound video expertise, since streaming media highlights key differences
annual growth rate continuing at 34% (from Appendix D of [CVNI]). between common assumptions in existing networking practices and
observations of video delivery issues encountered when streaming
A substantial part of this growth is due to increased use of media over those existing networks.
streaming video, although the amount of video traffic in real-time
communications (for example, online videoconferencing) has also grown
significantly. While both streaming video and videoconferencing have
real-time delivery and latency requirements, these requirements vary
from one application to another. For example, videoconferencing
demands an end-to-end (one-way) latency of a few hundreds of
milliseconds whereas live streaming can tolerate latencies of several
seconds.
This document specifically focuses on the 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 such * Here, "continuous media" refers to media and associated streams
as video, audio, metadata, etc. In this definition, the critical such as video, audio, metadata, etc. In this definition, the
term is "simultaneous", as it is not considered streaming if one critical term is "simultaneous", as it is not considered streaming
downloads a video file and plays it after the download is if one downloads a video file and plays it after the download is
completed, which would be called download-and-play. completed, which would be called download-and-play.
This has two implications. This has two implications.
* First, the server's transmission rate must (loosely or tightly) * First, the server's transmission rate must (loosely or tightly)
match to client's consumption rate in order to provide match to client's consumption rate in order to provide
uninterrupted playback. That is, the client must not run out of uninterrupted playback. That is, the client must not run out of
data (buffer underrun) or accept more data than it can buffer data (buffer underrun) or accept more data than it can buffer
before playback (buffer overrun) as any excess media is simply before playback (buffer overrun) as any excess media that cannot
discarded. be buffered is simply discarded.
* Second, the client's consumption rate is limited not only by * Second, the client's consumption rate is limited not only by
bandwidth availability but also real-time constraints. That is, bandwidth availability,but also media availability. The client
the client cannot fetch media that is not available from a server cannot fetch media that is not available from a server yet.
yet.
In many contexts, video traffic can be handled transparently as This document contains
generic application-level traffic. However, as the volume of video
traffic continues to grow, it's becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery.
This document examines networking issues as they relate to quality of * A short description of streaming video characteristics in
experience in internet video delivery. The focus is on capturing Section 2, to set the stage for the rest of the document,
characteristics of video delivery that have surprised network
designers or transport experts without specific video expertise, * General guidance on bandwidth provisioning (Section 3) and latency
since these highlight key differences between common assumptions in considerations (Section 4) for streaming video delivery,
existing networking documents and observations of video delivery
issues in practice. * A description of adaptive encoding and adaptive delivery
techniques in common use for streaming video, along with a
description of the challenges media senders face in detecting the
bitrate available between the media sender and media receiver, and
collection of measurements by a third party for use in analytics
(Section 5),
* A description of existing transport protocols used for video
streaming, and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol [RFC9000]
that we expect to be used for streaming media (Section 6),
* A description of implications when streaming encrypted media
(Section 7), and
* A number of useful pointers for further reading on this rapidly
changing subject (Section 8).
Making specific recommendations on operational practices aimed at Making specific recommendations on operational practices aimed at
mitigating these issues is out of scope, though some existing mitigating the issues described in this document is out of scope,
mitigations are mentioned in passing. The intent is to provide a though some existing mitigations are mentioned in passing. The
point of reference for future solution proposals to use in describing intent is to provide a point of reference for future solution
how new technologies address or avoid these existing observed proposals to use in describing how new technologies address or avoid
problems. existing observed problems.
1.1. Notes for Contributors and Reviewers 1.1. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section and its subsections Note to RFC Editor: Please remove this section and its subsections
before publication. before publication.
This section is to provide references to make it easier to review the This section is to provide references to make it easier to review the
development and discussion on the draft so far. development and discussion on the draft so far.
1.1.1. Venues for Contribution and Discussion 1.1.1. Venues for Contribution and Discussion
skipping to change at page 5, line 24 skipping to change at page 5, line 27
Substantial discussion of this document should take place on the MOPS Substantial discussion of this document should take place on the MOPS
working group mailing list (mops@ietf.org). working group mailing list (mops@ietf.org).
* 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/)
1.1.2. History of Public Discussion 2. Our Focus on Streaming Video
Presentations:
* IETF 105 BOF: As the internet has grown, an increasingly large share of the traffic
https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s delivered to end users has become video. Estimates put the total
(https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s) share of internet video traffic at 75% in 2019, expected to grow to
82% by 2022. This estimate projects the gross volume of video
traffic will more than double during this time, based on a compound
annual growth rate continuing at 34% (from Appendix D of [CVNI]).
* IETF 106 meeting: A substantial part of this growth is due to increased use of
https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s streaming video, although the amount of video traffic in real-time
(https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s) communications (for example, online videoconferencing) has also grown
significantly. While both streaming video and videoconferencing have
real-time delivery and latency requirements, these requirements vary
from one application to another. For example, videoconferencing
demands an end-to-end (one-way) latency of a few hundreds of
milliseconds whereas live streaming can tolerate latencies of several
seconds.
* MOPS Interim Meeting 2020-04-15: In many contexts, video traffic can be handled transparently as
https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s generic application-level traffic. However, as the volume of video
(https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s) traffic continues to grow, it's becoming increasingly important to
consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery.
* IETF 108 meeting: Much of the focus of this document is on reliable media using HTTP
https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s over TCP. which is widely used because support for HTTP is widely
(https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s) available in a wide range of operating systems, is also used in a
wide variety of other applications, has been demonstrated to provide
acceptable performance over the open Internet, includes state of the
art standardized security mechanisms, and can make use of already-
deployed caching infrastructure.
* MOPS 2020-10-30 Interim meeting: Some mentions of unreliable media delivery using RTP and other UDP-
https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s based protocols appear in Section 4.1, Section 5.7, Section 6.1, and
(https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s) Section 7.2, but it's difficult to give general guidance for these
applications. For instance, when loss occurs, the most appropriate
response may depend on the type of codec being used.
2. Bandwidth Provisioning 3. Bandwidth Provisioning
2.1. Scaling Requirements for Media Delivery 3.1. Scaling Requirements for Media Delivery
2.1.1. Video Bitrates 3.1.1. Video Bitrates
Video bitrate selection depends on many variables including the Video bitrate selection depends on many variables including the
resolution (height and width), frame rate, color depth, codec, resolution (height and width), frame rate, color depth, codec,
encoding parameters, scene complexity and amount of motion. encoding parameters, scene complexity and amount of motion.
Generally speaking, as the resolution, frame rate, color depth, scene Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate complexity and amount of motion increase, the encoding bitrate
increases. As newer codecs with better compression tools are used, increases. As newer codecs with better compression tools are used,
the encoding bitrate decreases. Similarly, a multi-pass encoding the encoding bitrate decreases. Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass generally produces better quality output compared to single-pass
encoding at the same bitrate, or delivers the same quality at a lower encoding at the same bitrate, or delivers the same quality at a lower
skipping to change at page 6, line 40 skipping to change at page 7, line 5
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps | | 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps | | 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps | | 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
Table 1 Table 1
2.1.2. Virtual Reality Bitrates 3.1.2. Virtual Reality Bitrates
The bitrates given in Section 2.1.1 describe video streams that The bitrates given in Section 3.1.1 describe video streams that
provide the user with a single, fixed, point of view - so, the user provide the user with a single, fixed, point of view - so, the user
has no "degrees of freedom", and the user sees all of the video image has no "degrees of freedom", and the user sees all of the video image
that is available. that is available.
Even basic virtual reality (360-degree) videos that allow users to Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom", or look around freely (referred to as "three degrees of freedom", or
3DoF) require substantially larger bitrates when they are captured 3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the and encoded as such videos require multiple fields of view of the
scene. The typical multiplication factor is 8 to 10. Yet, due to scene. Yet, due to smart delivery methods such as viewport-based or
smart delivery methods such as viewport-based or tiled-based tiled-based streaming, we do not need to send the whole scene to the
streaming, we do not need to send the whole scene to the user. user. Instead, the user needs only the portion corresponding to its
Instead, the user needs only the portion corresponding to its viewpoint at any given time ([Survey360o]).
viewpoint at any given time.
In more immersive applications, where limited user movement ("three In more immersive applications, where limited user movement ("three
degrees of freedom plus", or 3DoF+) or full user movement ("six degrees of freedom plus", or 3DoF+) or full user movement ("six
degrees of freedom", or 6DoF) is allowed, the required bitrate grows degrees of freedom", or 6DoF) is allowed, the required bitrate grows
even further. In this case, immersive content is typically referred even further. In this case, immersive content is typically referred
to as volumetric media. One way to represent the volumetric media is to as volumetric media. One way to represent the volumetric media is
to use point clouds, where streaming a single object may easily to use point clouds, where streaming a single object may easily
require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC] require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC]
for more details. for more details.
2.2. Path Bandwidth Constraints 3.2. Path Bandwidth Constraints
Even when the bandwidth requirements for video streams along a path Even when the bandwidth requirements for video streams along a path
are well understood, additional analysis is required to understand are well understood, additional analysis is required to understand
the contraints on bandwidth at various points in the network. This the contraints on bandwidth at various points in the network. This
analysis is necessary because media servers may react to bandwith analysis is necessary because media servers may react to bandwith
constraints using two independent feedback loops: constraints using two independent feedback loops:
* Media servers often respond to application-level feedback from the * Media servers often respond to application-level feedback from the
media player that indicates a bottleneck link somewhere along the media player that indicates a bottleneck link somewhere along the
path, by adjusting the amount of media that the media server will path, by adjusting the amount of media that the media server will
send to the media player in a given timeframe. This is described send to the media player in a given timeframe. This is described
in greater detail in Section 4. 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 5. 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 a quality of experience for users that
is significantly lower than what could have been achieved. is significantly 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
handwidth 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,
* the transport protocol sends media at the new, lower rate, and * the transport protocol sends media at the new, lower rate, and
confirms that this new, lower rate is "safe", because no confirms that this new, lower rate is "safe", because no
transport-level loss is occuring, but transport-level loss is occuring, but
skipping to change at page 8, line 23 skipping to change at page 8, line 38
* 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.
2.2.1. Know Your Network Traffic 3.2.1. Know Your Network Traffic
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
skipping to change at page 8, line 46 skipping to change at page 9, line 14
Recognizing that a path carrying streaming media is "not behaving the Recognizing that a path carrying streaming media is "not behaving the
way it normally does" is fundamental. Analytics that aid in that way it normally does" is fundamental. Analytics that aid in that
recognition can be more or less sophisticated, and can be as simple recognition can be more or less sophisticated, and can be as simple
as noticing that the apparent round trip times for media traffic as noticing that the apparent round trip times for media traffic
carried over TCP transport on some paths are suddenly and 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 5.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])
that was possible with the older transport protocols (UDP, described that was possible with the older transport protocols (UDP, described
in Section 5.1 and TCP, described in Section 5.2) is no longer in Section 6.1 and TCP, described in Section 6.2) is no longer
possible with newer transport protocols such as QUIC (described in possible with newer transport protocols such as QUIC (described in
Section 5.3). The IETF has specified a "latency spin bit" mechanism Section 6.3). The IETF has specified a "latency spin bit" mechanism
in Section 17.4 of [RFC9000] to allow passive latency monitoring from in Section 17.4 of [RFC9000] to allow passive latency monitoring from
observation points on the network path throughout the duration of a observation points on the network path throughout the duration of a
connection, but currently chartered work in the IETF is focusing on connection, but currently chartered work in the IETF is focusing on
end-point monitoring and reporting, rather than on passive end-point monitoring and reporting, rather than on passive
monitoring. monitoring.
One example is the "qlog" mechanism [I-D.ietf-quic-qlog-main-schema], One example is the "qlog" mechanism [I-D.ietf-quic-qlog-main-schema],
a protocol-agnostic mechanism used to provide better visibility for a protocol-agnostic mechanism used to provide better visibility for
encrypted protocols such as QUIC ([I-D.ietf-quic-qlog-quic-events]) encrypted protocols such as QUIC ([I-D.ietf-quic-qlog-quic-events])
and for HTTP/3 ([I-D.ietf-quic-qlog-h3-events]). and for HTTP/3 ([I-D.ietf-quic-qlog-h3-events]).
2.3. Path Requirements 3.3. Path Requirements
The bitrate requirements in Section 2.1 are per end-user actively The bitrate requirements in Section 3.1 are per end-user actively
consuming a media feed, so in the worst case, the bitrate demands can consuming a media feed, so in the worst case, the bitrate demands can
be multiplied by the number of simultaneous users to find the be multiplied by the number of simultaneous users to find the
bandwidth requirements for a router on the delivery path with that bandwidth requirements for a router on the delivery path with that
number of users downstream. For example, at a node with 10,000 number of users downstream. For example, at a node with 10,000
downstream users simultaneously consuming video streams, downstream users simultaneously consuming video streams,
approximately 80 Gbps might be necessary in order for all of them to approximately 80 Gbps might be necessary in order for all of them to
get typical content at 1080p resolution. get typical content at 1080p resolution.
However, when there is some overlap in the feeds being consumed by However, when there is some overlap in the feeds being consumed by
end users, it is sometimes possible to reduce the bandwidth end users, it is sometimes possible to reduce the bandwidth
provisioning requirements for the network by performing some kind of provisioning requirements for the network by performing some kind of
replication within the network. This can be achieved via object replication within the network. This can be achieved via object
caching with delivery of replicated objects over individual caching with delivery of replicated objects over individual
connections, and/or by packet-level replication using multicast. connections, and/or by packet-level replication using multicast.
To the extent that replication of popular content can be performed, To the extent that replication of popular content can be performed,
bandwidth requirements at peering or ingest points can be reduced to bandwidth requirements at peering or ingest points can be reduced to
as low as a per-feed requirement instead of a per-user requirement. as low as a per-feed requirement instead of a per-user requirement.
2.4. Caching Systems 3.4. Caching Systems
When demand for content is relatively predictable, and especially When demand for content is relatively predictable, and especially
when that content is relatively static, caching content close to when that content is relatively static, caching content close to
requesters, and pre-loading caches to respond quickly to initial requesters, and pre-loading caches to respond quickly to initial
requests is often useful (for example, HTTP/1.1 caching is described requests is often useful (for example, HTTP/1.1 caching is described
in [RFC7234]). This is subject to the usual considerations for in [I-D.ietf-httpbis-cache]). This is subject to the usual
caching - for example, how much data must be cached to make a considerations for caching - for example, how much data must be
significant difference to the requester, and how the benefits of cached to make a significant difference to the requester, and how the
caching and pre-loading caches balances against the costs of tracking benefits of caching and pre-loading caches balances against the costs
"stale" content in caches and refreshing that content. of tracking "stale" content in caches and refreshing that content.
It is worth noting that not all high-demand content is "live" It is worth noting that not all high-demand content is "live"
content. One popular example is when popular streaming content can content. One popular example is when popular streaming content can
be staged close to a significant number of requesters, as can happen be staged close to a significant number of requesters, as can happen
when a new episode of a popular show is released. This content may when a new episode of a popular show is released. This content may
be largely stable, so low-cost to maintain in multiple places be largely stable, so low-cost to maintain in multiple places
throughout the Internet. This can reduce demands for high end-to-end throughout the Internet. This can reduce demands for high end-to-end
bandwidth without having to use mechanisms like multicast. bandwidth without having to use mechanisms like multicast.
Caching and pre-loading can also reduce exposure to peering point Caching and pre-loading can also reduce exposure to peering point
congestion, since less traffic crosses the peering point exchanges if congestion, since less traffic crosses the peering point exchanges if
the caches are placed in peer networks, especially when the content the caches are placed in peer networks, especially when the content
can be pre-loaded during off-peak hours, and especially if the can be pre-loaded during off-peak hours, and especially if the
transfer can make use of "Lower-Effort Per-Hop Behavior (LE PHB) for transfer can make use of "Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services" [RFC8622], "Low Extra Delay Background Differentiated Services" [RFC8622], "Low Extra Delay Background
Transport (LEDBAT)" [RFC6817], or similar mechanisms. Transport (LEDBAT)" [RFC6817], or similar mechanisms.
All of this depends, of course, on the ability of a content provider All of this depends, of course, on the ability of a content provider
to predict usage and provision bandwidth, caching, and other to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users. In some cases (Section 2.5), mechanisms to meet the needs of users. In some cases (Section 3.5),
this is relatively routine, but in other cases, it is more difficult this is relatively routine, but in other cases, it is more difficult
(Section 2.6, Section 2.7). (Section 3.6, Section 3.7).
And as with other parts of the ecosystem, new technology brings new And as with other parts of the ecosystem, new technology brings new
challenges. For example, with the emergence of ultra-low-latency challenges. For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not still being transmitted to the cache, and while the cache does not
yet know the size of the object. Some of the popular caching systems yet know the size of the object. Some of the popular caching systems
were designed around cache footprint and had deeply ingrained were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects that are being stored, assumptions about knowing the size of objects that are being stored,
so the change in design requirements in long-established systems so the change in design requirements in long-established systems
caused some errors in production. Incidents occurred where a caused some errors in production. Incidents occurred where a
transmission error in the connection from the upstream source to the transmission error in the connection from the upstream source to the
cache could result in the cache holding a truncated segment and cache could result in the cache holding a truncated segment and
transmitting it to the end user's device. In this case, players transmitting it to the end user's device. In this case, players
rendering the stream often had the video freeze until the player was rendering the stream often had the video freeze until the player was
reset. In some cases the truncated object was even cached that way reset. In some cases the truncated object was even cached that way
and served later to other players as well, causing continued stalls and served later to other players as well, causing continued stalls
at the same spot in the video for all players playing the segment at the same spot in the video for all players playing the segment
delivered from that cache node. delivered from that cache node.
2.5. Predictable Usage Profiles 3.5. Predictable Usage Profiles
Historical data shows that users consume more video and videos at Historical data shows that users consume more video and videos at
higher bitrates than they did in the past on their connected devices. higher bitrates than they did in the past on their connected devices.
Improvements in the codecs that help with reducing the encoding Improvements in the codecs that help with reducing the encoding
bitrates with better compression algorithms could not have offset the bitrates with better compression algorithms could not have offset the
increase in the demand for the higher quality video (higher increase in the demand for the higher quality video (higher
resolution, higher frame rate, better color gamut, better dynamic resolution, higher frame rate, better color gamut, better dynamic
range, etc.). In particular, mobile data usage has shown a large range, etc.). In particular, mobile data usage has shown a large
jump over the years due to increased consumption of entertainment as jump over the years due to increased consumption of entertainment as
well as conversational video. well as conversational video.
2.6. Unpredictable Usage Profiles 3.6. Unpredictable Usage Profiles
Although TCP/IP has been used with a number of widely used Although TCP/IP has been used with a number of widely used
applications that have symmetric bandwidth requirements (similar applications that have symmetric bandwidth requirements (similar
bandwidth requirements in each direction between endpoints), many bandwidth requirements in each direction between endpoints), many
widely-used Internet applications operate in client-server roles, widely-used Internet applications operate in client-server roles,
with asymmetric bandwidth requirements. A common example might be an with asymmetric bandwidth requirements. A common example might be an
HTTP GET operation, where a client sends a relatively small HTTP GET HTTP GET operation, where a client sends a relatively small HTTP GET
request for a resource to an HTTP server, and often receives a request for a resource to an HTTP server, and often receives a
significantly larger response carrying the requested resource. When significantly larger response carrying the requested resource. When
HTTP is commonly used to stream movie-length video, the ratio between HTTP is commonly used to stream movie-length video, the ratio between
response size and request size can become arbitrarily large. response size and request size can become arbitrarily large.
For this reason, operators may pay more attention to downstream For this reason, operators may pay more attention to downstream
bandwidth utilization when planning and managing capacity. In bandwidth utilization when planning and managing capacity. In
addition, operators have been able to deploy access networks for end addition, operators have been able to deploy access networks for end
users using underlying technologies that are inherently asymmetric, users using underlying technologies that are inherently asymmetric,
favoring downstream bandwidth (e.g. ADSL, cellular technologies, favoring downstream bandwidth (e.g. ADSL, cellular technologies,
most IEEE 802.11 variants), assuming that users will need less most IEEE 802.11 variants), assuming that users will need less
upstream bandwidth than downstream bandwidth. This strategy usually upstream bandwidth than downstream bandwidth. This strategy usually
works, except when it faiis because application bandwidth usage works, except when it fails because application bandwidth usage
patterns have changed in ways that were not predicted. patterns have changed in ways that were not predicted.
One example of this type of change was when peer-to-peer file sharing One example of this type of change was when peer-to-peer file sharing
applications gained popularity in the early 2000s. To take one well- applications gained popularity in the early 2000s. To take one well-
documented case ([RFC5594]), the Bittorrent application created documented case ([RFC5594]), the Bittorrent application created
"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
ISP to attempt to "throttle" these transfers, to mitigate the load internet service provider (ISP) to attempt to "throttle" these
that these hosts placed on their network. These efforts were met by transfers, to mitigate the load that these hosts placed on their
increased use of encryption in Bittorrent, similar to an arms race, network. These efforts were met by increased use of encryption in
and set off discussions about "Net Neutrality" and calls for Bittorrent, similar to an arms race, and set off discussions about
regulatory action. "Net Neutrality" and calls for regulatory action.
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.
2.7. Extremely Unpredictable Usage Profiles 3.7. Extremely Unpredictable Usage Profiles
The causes of unpredictable usage described in Section 2.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
post-IETF 107 meeting that humans are not always in control, and post-IETF 107 meeting that humans are not always in control, and
forces of nature can cause enormous fluctuations in traffic patterns. forces of nature can cause enormous fluctuations in traffic patterns.
In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19 In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19
pandemic broke out in early 2020, pandemic broke out in early 2020,
* Comcast's streaming and web video consumption rose by 38%, with * Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to their reported peak traffic up 32% overall between March 1 to
March 30, March 30,
skipping to change at page 13, line 11 skipping to change at page 13, line 24
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 IXPs over just a few * Reported traffic increases from ISPs and internet exchange points
weeks were as big as the traffic growth over the course of a (IXP) over just a few weeks were as big as the traffic growth over
typical year, representing a 15-20% surge in growth to land at a the course of a typical year, representing a 15-20% surge in
new normal that was much higher than anticipated. growth to land at a new normal that was much higher than
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.
* The usage pattern changed significantly as work-from-home and * The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and would have typically been off-peak hours with adults at work and
children at school. One might expect that the peak would have had children at school. One might expect that the peak would have had
more impact on networks if it had happened during typical evening more impact on networks if it had happened during typical evening
peak hours for 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 VPNs, and entertainment applications as videoconferencing and virtual private networks (VPN), and
people watched videos or played games. entertainment applications as people watched videos or played
games.
* At the IXP-level, it was observed that port utilization increased. * At the IXP-level, it was observed that port utilization increased.
This phenomenon is mostly explained by a higher traffic demand This phenomenon is mostly explained by a higher traffic demand
from residential users. from residential users.
3. 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
service such as a CDN or other video distribution service, rather service such as a CDN or other video distribution service, rather
than a direct connection to an end user. than a direct connection to an end user.
skipping to change at page 14, line 4 skipping to change at page 14, line 21
(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
service such as a CDN or other video distribution service, rather service such as a CDN or other video distribution service, rather
than a direct connection to an end user. than a direct connection to an end user.
Streaming media can be usefully categorized according to the Streaming media can be usefully categorized according to the
application's latency requirements into a few rough categories: application's latency requirements into a few rough categories:
* ultra low-latency (less than 1 second) * ultra low-latency (less than 1 second)
* low-latency live (less than 10 seconds) * low-latency live (less than 10 seconds)
* non-low-latency live (10 seconds to a few minutes) * non-low-latency live (10 seconds to a few minutes)
* on-demand (hours or more) * on-demand (hours or more)
3.1. Ultra Low-Latency 4.1. Ultra Low-Latency
Ultra low-latency delivery of media is defined here as having a Ultra low-latency delivery of media is defined here as having a
glass-to-glass delay target under one second. glass-to-glass delay target under one second.
Some media content providers aim to achieve this level of latency for Some media content providers aim to achieve this level of latency for
live media events. This introduces new challenges relative to less- live media events. This introduces new challenges relative to less-
restricted levels of latency requirements because this latency is the restricted levels of latency requirements because this latency is the
same scale as commonly observed end-to-end network latency variation same scale as commonly observed end-to-end network latency variation
(for example, due to effects such as bufferbloat ([CoDel]), Wi-Fi (for example, due to effects such as bufferbloat ([CoDel]), Wi-Fi
error correction, or packet reordering). These effects can make it error correction, or packet reordering). These effects can make it
skipping to change at page 15, line 5 skipping to change at page 15, line 22
simplifies many delivery considerations relative to other use cases. simplifies many delivery considerations relative to other use cases.
Recommended reading for applications adopting an RTP-based approach Recommended reading for applications adopting an RTP-based approach
also includes [RFC7656]. For increasing the robustness of the also includes [RFC7656]. For increasing the robustness of the
playback by implementing adaptive playout methods, refer to [RFC4733] playback by implementing adaptive playout methods, refer to [RFC4733]
and [RFC6843]. and [RFC6843].
Applications with further-specialized latency requirements are out of Applications with further-specialized latency requirements are out of
scope for this document. scope for this document.
3.2. Low-Latency Live 4.2. Low-Latency Live
Low-latency live delivery of media is defined here as having a glass- Low-latency live delivery of media is defined here as having a glass-
to-glass delay target under 10 seconds. to-glass delay target under 10 seconds.
This level of latency is targeted to have a user experience similar This level of latency is targeted to have a user experience similar
to traditional broadcast TV delivery. A frequently cited problem to traditional broadcast TV delivery. A frequently cited problem
with failing to achieve this level of latency for live sporting with failing to achieve this level of latency for live sporting
events is the user experience failure from having crowds within events is the user experience failure from having crowds within
earshot of one another who react audibly to an important play, or earshot of one another who react audibly to an important play, or
from users who learn of an event in the match via some other channel, from users who learn of an event in the match via some other channel,
skipping to change at page 16, line 5 skipping to change at page 16, line 21
without penalizing latency. without penalizing latency.
While an LL-HLS client retrieves each chunk with a separate HTTP GET While an LL-HLS client retrieves each chunk with a separate HTTP GET
request, an LL-DASH client uses the chunked transfer encoding feature request, an LL-DASH client uses the chunked transfer encoding feature
of the HTTP [CMAF-CTE] which allows the LL-DASH client to fetch all of the HTTP [CMAF-CTE] which allows the LL-DASH client to fetch all
the chunks belonging to a segment with a single GET request. An HTTP the chunks belonging to a segment with a single GET request. An HTTP
server can transmit the CMAF chunks to the LL-DASH client as they server can transmit the CMAF chunks to the LL-DASH client as they
arrive from the encoder/packager. A detailed comparison of LL-HLS arrive from the encoder/packager. A detailed comparison of LL-HLS
and LL-DASH is given in [MMSP20]. and LL-DASH is given in [MMSP20].
3.3. Non-Low-Latency Live 4.3. Non-Low-Latency Live
Non-low-latency live delivery of media is defined here as a live Non-low-latency live delivery of media is defined here as a live
stream that does not have a latency target shorter than 10 seconds. stream that does not have a latency target shorter than 10 seconds.
This level of latency is the historically common case for segmented This level of latency is the historically common case for segmented
video delivery using HLS [RFC8216] and DASH [MPEG-DASH]. This level video delivery using HLS [RFC8216] and DASH [MPEG-DASH]. This level
of latency is often considered adequate for content like news or pre- of latency is often considered adequate for content like news or pre-
recorded content. This level of latency is also sometimes achieved recorded content. This level of latency is also sometimes achieved
as a fallback state when some part of the delivery system or the as a fallback state when some part of the delivery system or the
client-side players do not have the necessary support for the client-side players do not have the necessary support for the
features necessary to support low-latency live streaming. features necessary to support low-latency live streaming.
This level of latency can typically be achieved at scale with This level of latency can typically be achieved at scale with
commodity CDN services for HTTP(s) delivery, and in some cases the commodity CDN services for HTTP(s) delivery, and in some cases the
increased time window can allow for production of a wider range of increased time window can allow for production of a wider range of
encoding options relative to the requirements for a lower latency encoding options relative to the requirements for a lower latency
service without the need for increasing the hardware footprint, which service without the need for increasing the hardware footprint, which
can allow for wider device interoperability. can allow for wider device interoperability.
3.4. On-Demand 4.4. On-Demand
On-Demand media streaming refers to playback of pre-recorded media On-Demand media streaming refers to playback of pre-recorded media
based on a user's action. In some cases on-demand media is produced based on a user's action. In some cases on-demand media is produced
as a by-product of a live media production, using the same segments as a by-product of a live media production, using the same segments
as the live event, but freezing the manifest after the live event has as the live event, but freezing the manifest after the live event has
finished. In other cases, on-demand media is constructed out of pre- finished. In other cases, on-demand media is constructed out of pre-
recorded assets with no streaming necessarily involved during the recorded assets with no streaming necessarily involved during the
production of the on-demand content. production of the on-demand content.
On-demand media generally is not subject to latency concerns, but On-demand media generally is not subject to latency concerns, but
skipping to change at page 16, line 48 skipping to change at page 17, line 18
with live events. These considerations include the startup time, the with live events. These considerations include the startup time, the
stability of the media stream's playback quality, and avoidance of stability of the media stream's playback quality, and avoidance of
stalls and video artifacts during the playback under all but the most stalls and video artifacts during the playback under all but the most
severe network conditions. severe network conditions.
In some applications, optimizations are available to on-demand video In some applications, optimizations are available to on-demand video
that are not always available to live events, such as pre-loading the that are not always available to live events, such as pre-loading the
first segment for a startup time that doesn't have to wait for a first segment for a startup time that doesn't have to wait for a
network download to begin. network download to begin.
4. Adaptive Encoding, Adaptive Delivery, and Measurement Collection 5. Adaptive Encoding, Adaptive Delivery, and Measurement Collection
4.1. Overview
5.1. Overview
A simple model of video playback can be described as a video stream A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer. consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the The consumption rate is fairly static and is represented by the
content bitrate. The size of the buffer is also commonly a fixed content bitrate. The size of the buffer is also commonly a fixed
size. The fill process needs to be at least fast enough to ensure size. The fill process needs to be at least fast enough to ensure
that the buffer is never empty, however it also can have significant that the buffer is never empty, however it also can have significant
complexity when things like personalization or ad workflows are complexity when things like personalization or ad workflows are
introduced. introduced.
The challenges in filling the buffer in a timely way fall into two The challenges in filling the buffer in a timely way fall into two
broad categories: 1. content selection and 2. content variation. broad categories: 1. content selection and 2. content variation.
Content selection comprises all of the steps needed to determine Content selection comprises all of the steps needed to determine
which content variation to offer the client. Content variation is which content variation to offer the client. Content variation is
the number of content options that exist at any given selection the number of content options that exist at any given selection
point. A common example, easily visualized, is Adaptive BitRate point. A common example, easily visualized, is Adaptive BitRate
(ABR), described in more detail below. The mechanism used to select (ABR), described in more detail below. The mechanism used to select
the bitrate is part of the content selection, and the content the bitrate is part of the content selection, and the content
variation are all of the different bitrate renditions. variation are all of the different bitrate renditions.
Adaptive BitRate (ABR) is a sort of application-level response ABR is a sort of application-level response strategy in which the
strategy in which the streaming client attempts to detect the streaming client attempts to detect the available bandwidth of the
available bandwidth of the network path by observing the successful network path by observing the successful application-layer download
application-layer download speed, then chooses a bitrate for each of speed, then chooses a bitrate for each of the video, audio, subtitles
the video, audio, subtitles and metadata (among the limited number of and metadata (among the limited number of available options) that
available options) that fits within that bandwidth, typically fits within that bandwidth, typically adjusting as changes in
adjusting as changes in available bandwidth occur in the network or available bandwidth occur in the network or changes in capabilities
changes in capabilities occur during the playback (such as available occur during the playback (such as available memory, CPU, display
memory, CPU, display size, etc.). size, etc.).
4.2. Adaptive Encoding 5.2. Adaptive Encoding
Media servers can provide media streams at various bitrates because Media servers can provide media streams at various bitrates because
the media has been encoded at various bitrates. This is a so-called the media has been encoded at various bitrates. This is a so-called
"ladder" of bitrates, that can be offered to media players as part of "ladder" of bitrates, that can be offered to media players as part of
the manifest that describes the media being requested by the media the manifest that describes the media being requested by the media
player, so that the media player can select among the available player, so that the media player can select among the available
bitrate choices. bitrate choices.
The media server may also choose to alter which bitrates are made The media server may also choose to alter which bitrates are made
available to players by adding or removing bitrate options from the available to players by adding or removing bitrate options from the
ladder delivered to the player in subsequent manifests built and sent ladder delivered to the player in subsequent manifests built and sent
to the player. This way, both the player, through its selection of to the player. This way, both the player, through its selection of
bitrate to request from the manifest, and the server, through its bitrate to request from the manifest, and the server, through its
construction of the bitrates offered in the manifest, are able to construction of the bitrates offered in the manifest, are able to
affect network utilization. affect network utilization.
4.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 server-player systems will do an initial probe or a very simple
throughput speed test at the start of a video playback. This is done throughput speed test at the start of a video playback. This is done
skipping to change at page 18, line 27 skipping to change at page 18, line 44
that the network between the server and player will likely be able to that the network between the server and player will likely be able to
provide under initial network conditions. After the initial testing, provide under initial network conditions. After the initial testing,
clients tend to rely upon passive network observations and will make clients tend to rely upon passive network observations and will make
use of player side statistics such as buffer fill rates to monitor use of player side statistics such as buffer fill rates to monitor
and respond to changing network conditions. and 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
some metric monitored by the client, such as highest achievable video some metric monitored by the client, such as highest achievable video
quality or lowest chances for a rebuffering event (playback stall). quality or lowest chances for a rebuffering event (playback stall).
4.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
media content is therefore common in today's media landscape. media content is therefore common in today's media landscape.
skipping to change at page 20, line 8 skipping to change at page 20, line 20
tracking. Some of these and other measures have raised privacy tracking. Some of these and other measures have raised privacy
concerns for end users. concerns for end users.
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.
4.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 issues. Because
adaptive application-level response strategies are often using rates adaptive application-level response strategies are often using rates
as observed by the application layer, there are sometimes inscrutable as observed by the application layer, there are sometimes inscrutable
transport-level protocol behaviors that can produce surprising transport-level protocol behaviors that can produce surprising
measurement values when the application-level feedback loop is measurement values when the application-level feedback loop is
interacting with a transport-level feedback loop. 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's common to encounter cases As these examples will demonstrate, it's 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 ABR from lab modeling can sometimes have a significant impact on bitrate
bitrate selection and on user quality of experience, especially where selection and on user quality of experience, especially where players
players use naive measurement strategies and selection algorithms use naive measurement strategies and selection algorithms that don't
that don't account for the likelihood of bandwidth measurements that account for the likelihood of bandwidth measurements that diverge
diverge from the true path capacity. from the true path capacity.
4.5.1. Idle Time between Segments 5.5.1. Idle Time between Segments
When the bitrate selection is chosen substantially below the When the bitrate selection is chosen substantially below the
available capacity of the network path, the response to a segment available capacity of the network path, the response to a segment
request will typically complete in much less absolute time than the request will typically complete in much less absolute time than the
duration of the requested segment, leaving significant idle time duration of the requested segment, leaving significant idle time
between segment downloads. This can have a few surprising between segment downloads. This can have a few surprising
consequences: consequences:
* TCP slow-start when restarting after idle requires multiple RTTs * TCP slow-start when restarting after idle requires multiple RTTs
to re-establish a throughput at the network's available capacity. to re-establish a throughput at the network's available capacity.
skipping to change at page 21, line 34 skipping to change at page 21, line 34
Some receiver-side ABR algorithms such as [ELASTIC] are designed to Some receiver-side ABR algorithms such as [ELASTIC] are designed to
try to avoid this effect. try to avoid this effect.
Another way to mitigate this effect is by the help of two Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in [MMSys11] for Microsoft simultaneous TCP connections, as explained in [MMSys11] for Microsoft
Smooth Streaming. In some cases, the system-level TCP slow-start Smooth Streaming. In some cases, the system-level TCP slow-start
restart can also be disabled, for example as described in restart can also be disabled, for example as described in
[OReilly-HPBN]. [OReilly-HPBN].
4.5.2. Head-of-Line Blocking 5.5.2. Head-of-Line Blocking
In the event of a lost packet on a TCP connection with SACK support In the event of a lost packet on a TCP connection with SACK support
(a common case for segmented delivery in practice), loss of a packet (a common case for segmented delivery in practice), loss of a packet
can provide a confusing bandwidth signal to the receiving can provide a confusing bandwidth signal to the receiving
application. Because of the sliding window in TCP, many packets may application. Because of the sliding window in TCP, many packets may
be accepted by the receiver without being available to the be accepted by the receiver without being available to the
application until the missing packet arrives. Upon arrival of the application until the missing packet arrives. Upon arrival of the
one missing packet after retransmit, the receiver will suddenly get one missing packet after retransmit, the receiver will suddenly get
access to a lot of data at the same time. access to a lot of data at the same time.
To a receiver measuring bytes received per unit time at the To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the available network bandwidth, this appears as a high jitter in the
goodput measurement. This can appear as a stall of some time, goodput measurement, presenting as a stall, followed by a sudden leap
followed by a sudden leap that can far exceed the actual capacity of that can far exceed the actual capacity of the transport path from
the transport path from the server when the hole in the received data the server when the hole in the received data is filled by a later
is filled by a later retransmission. retransmission.
It's worth noting that more modern transport protocols such as QUIC It's worth noting that more modern transport protocols such as QUIC
have mitigation of head-of-line blocking as a protocol design goal. have mitigation of head-of-line blocking as a protocol design goal.
See Section 5.3 for more details. See Section 6.3 for more details.
4.5.3. Wide and Rapid Variation in Path Capacity 5.5.3. Wide and Rapid Variation in Path Capacity
As many end devices have moved to wireless connectivity for the final As many end devices have moved to wireless connectivity for the final
hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
emerged from radio interference and signal strength effects. emerged from radio interference and signal strength effects.
Each of these technologies can experience sudden changes in capacity Each of these technologies can experience sudden changes in capacity
as the end user device moves from place to place and encounters new as the end user device moves from place to place and encounters new
sources of interference. Microwave ovens, for example, can cause a sources of interference. Microwave ovens, for example, can cause a
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.
4.6. Measurement Collection 5.6. Measurement Collection
In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide
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.
In addition to measurements media players use to guide their segment- In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide also rely on measurements collected from media players to provide
analytics that can be used for decisions such as whether the adaptive analytics that can be used for decisions such as whether the adaptive
encoding bitrates in use are the best ones to provide to media encoding bitrates in use are the best ones to provide to media
players, or whether current media content caching is providing the players, or whether current media content caching is providing the
best experience for viewers. To that effect, the Consumer Technology best experience for viewers. To that effect, the Consumer Technology
Association (CTA) who owns the Web Application Video Ecosystem (WAVE) Association (CTA) who owns the Web Application Video Ecosystem (WAVE)
project has published two important specifications. project has published two important specifications.
4.6.1. CTA-2066: Streaming Quality of Experience Events, Properties and 5.6.1. CTA-2066: Streaming Quality of Experience Events, Properties and
Metrics Metrics
[CTA-2066] specifies a set of media player events, properties, [CTA-2066] specifies a set of media player events, properties,
quality of experience (QoE) metrics and associated terminology for quality of experience (QoE) metrics and associated terminology for
representing streaming media quality of experience across systems, representing streaming media quality of experience across systems,
media players and analytics vendors. While all these events, media players and analytics vendors. While all these events,
properties, metrics and associated terminology is used across a properties, metrics and associated terminology is used across a
number of proprietary analytics and measurement solutions, they were number of proprietary analytics and measurement solutions, they were
used in slightly (or vastly) different ways that led to 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.
4.6.2. CTA-5004: Common Media Client Data (CMCD) 5.6.2. CTA-5004: Common Media Client Data (CMCD)
Many assumes 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.
4.7. Unreliable Transport 5.7. Unreliable Transport
In contrast to segmented delivery, several applications use In contrast to segmented delivery, several applications use
unreliable UDP or SCTP with its "partial reliability" extension unreliable UDP or SCTP with its "partial reliability" extension
[RFC3758] to deliver Media encapsulated in RTP [RFC3550] or raw MPEG [RFC3758] to deliver Media encapsulated in RTP [RFC3550] or raw MPEG
Transport Stream ("MPEG-TS")-formatted video [MPEG-TS], when the Transport Stream ("MPEG-TS")-formatted video [MPEG-TS], when the
media is being delivered in situations such as broadcast and live media is being delivered in situations such as broadcast and live
streaming, that better tolerate occasional packet loss without streaming, that better tolerate occasional packet loss without
retransmission. retransmission.
Under congestion and loss, this approach generally experiences more Under congestion and loss, this approach generally experiences more
skipping to change at page 24, line 18 skipping to change at page 23, line 52
Congestion avoidance strategies for deployments using unreliable Congestion avoidance strategies for deployments using unreliable
transport protocols vary widely in practice, ranging from being transport protocols vary widely in practice, ranging from being
entirely unresponsive to congestion, to using feedback signaling to entirely unresponsive to congestion, to using feedback signaling to
change encoder settings (as in [RFC5762]), to using fewer enhancement change encoder settings (as in [RFC5762]), to using fewer enhancement
layers (as in [RFC6190]), to using proprietary methods to detect layers (as in [RFC6190]), to using proprietary methods to detect
"quality of experience" issues and turn off video in order to allow "quality of experience" issues and turn off video in order to allow
less bandwidth-intensive media such as audio to be delivered. less bandwidth-intensive media such as audio to be delivered.
More details about congestion avoidance strategies used with More details about congestion avoidance strategies used with
unreliable transport protocols are included in Section 5.1. unreliable transport protocols are included in Section 6.1.
5. 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 4, Adaptive Bitrate response strategies such as As noted in Section 5, ABR response strategies such as HLS [RFC8216]
HLS [RFC8216] or DASH [MPEG-DASH] are attempting to respond to or DASH [MPEG-DASH] are attempting to respond to changing path
changing path characteristics, and underlying transport protocols are characteristics, and underlying transport protocols are also
also attempting to respond to changing path characteristics. attempting to respond to changing path characteristics.
For most of the history of the Internet, these transport protocols, For most of the history of the Internet, these transport protocols,
described in Section 5.1 and Section 5.2, have had relatively described in Section 6.1 and Section 6.2, have had relatively
consistent behaviors that have changed slowly, if at all, over time. consistent behaviors that have changed slowly, if at all, over time.
Newly standardized transport protocols like QUIC [RFC9000] can behave Newly standardized transport protocols like QUIC [RFC9000] can behave
differently from existing transport protocols, and these behaviors differently from existing transport protocols, and these behaviors
may evolve over time more rapidly than currently-used transport may evolve over time more rapidly than currently-used transport
protocols. protocols.
For this reason, we have included a description of how the path For this reason, we have included a description of how the path
characteristics that streaming media providers may see are likely to characteristics that streaming media providers may see are likely to
evolve over time. evolve over time.
5.1. UDP and Its Behavior 6.1. UDP and Its Behavior
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
skipping to change at page 25, line 39 skipping to change at page 25, line 25
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,
"Encapsulating MPLS in UDP", as described in [RFC7510]). If "Encapsulating MPLS in UDP", as described in [RFC7510]). If
streaming media is carried in tunnels encapsulated in UDP, these streaming media is carried in tunnels encapsulated in UDP, these
media streams may encounter "tripped circuit breakers", with media streams may encounter "tripped circuit breakers", with
resulting user-visible impacts. resulting user-visible impacts.
5.2. TCP and Its Behavior 6.2. TCP and Its Behavior
For most of the history of the Internet, we have trusted the TCP For most of the history of the Internet, we have trusted TCP to limit
protocol to limit the impact of applications that sent a significant the impact of applications that sent a significant number of packets,
number of packets, in either or both directions, on other users. in either or both directions, on other users. Although early
Although early versions of TCP were not particularly good at limiting versions of TCP were not particularly good at limiting this impact
this impact [RFC0793], the addition of Slow Start and Congestion [RFC0793], the addition of Slow Start and Congestion Avoidance, as
Avoidance, as described in [RFC2001], were critical in allowing TCP- described in [RFC2001], were critical in allowing TCP-based
based applications to "use as much bandwidth as possible, but to applications to "use as much bandwidth as possible, but to avoid
avoid using more bandwidth than was possible". Although dozens of using more bandwidth than was possible". Although dozens of RFCs
RFCs have been written refining TCP decisions about what to send, how have been written refining TCP decisions about what to send, how much
much to send, and when to send it, since 1988 [Jacobson-Karels] the to send, and when to send it, since 1988 [Jacobson-Karels] the
signals available for TCP senders remained unchanged - end-to-end signals available for TCP senders remained unchanged - end-to-end
acknowledgements for packets that were successfully sent and acknowledgements for packets that were successfully sent and
received, and packet timeouts for packets that were not. received, and packet timeouts for packets that were not.
The success of the largely TCP-based Internet is evidence that the The success of the largely TCP-based Internet is evidence that the
mechanisms TCP used to achieve equilibrium quickly, at a point where mechanisms TCP used to achieve equilibrium quickly, at a point where
TCP senders do not interfere with other TCP senders for sustained TCP senders do not interfere with other TCP senders for sustained
periods of time, have been largely successful. The Internet periods of time, have been largely successful. The Internet
continued to work even when the specific mechanisms used to reach continued to work even when the specific mechanisms used to reach
equilibrium changed over time. Because TCP provides a common tool to equilibrium changed over time. Because TCP provides a common tool to
skipping to change at page 26, line 28 skipping to change at page 26, line 16
"backing off" when a network path is saturated, has been supplanted "backing off" when a network path is saturated, has been supplanted
by the goal of avoiding growing queues along network paths, which by the goal of avoiding growing queues along network paths, which
prevent TCP senders from reacting quickly when a network path is prevent TCP senders from reacting quickly when a network path is
saturated. Congestion control mechanisms such as COPA [COPA18] and saturated. Congestion control mechanisms such as COPA [COPA18] and
BBR [I-D.cardwell-iccrg-bbr-congestion-control] make these decisions BBR [I-D.cardwell-iccrg-bbr-congestion-control] make these decisions
based on measured path delays, assuming that if the measured path based on measured path delays, assuming that if the measured path
delay is increasing, the sender is injecting packets onto the network delay is increasing, the sender is injecting packets onto the network
path faster than the receiver can accept them, so the sender should path faster than the receiver can accept them, so the sender should
adjust its sending rate accordingly. adjust its sending rate accordingly.
Although TCP protocol behavior has changed over time, the common Although TCP behavior has changed over time, the common practice of
practice of implementing TCP as part of an operating system kernel implementing TCP as part of an operating system kernel has acted to
has acted to limit how quickly TCP behavior can change. Even with limit how quickly TCP behavior can change. Even with the widespread
the widespread use of automated operating system update installation use of automated operating system update installation on many end-
on many end-user systems, streaming media providers could have a user systems, streaming media providers could have a reasonable
reasonable expectation that they could understand TCP transport expectation that they could understand TCP transport protocol
protocol behaviors, and that those behaviors would remain relatively behaviors, and that those behaviors would remain relatively stable in
stable in the short term. the short term.
5.3. The QUIC Protocol and Its Behavior 6.3. The QUIC Protocol 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 5.1 and Section 5.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 6.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
performance issues, perform analytics, or even intercept exchanges in performance issues, perform analytics, or even intercept exchanges in
current applications will not work for QUIC-based applications current applications will not work for QUIC-based applications
without making changes to their networks. Section 6 describes the without making changes to their networks. Section 7 describes the
implications of media encryption in more detail. implications of media encryption in more detail.
While QUIC is designed as a general-purpose transport protocol, and While QUIC is designed as a general-purpose transport protocol, and
can carry different application-layer protocols, the current can carry different application-layer protocols, the current
standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which
describes how QUIC transport features are used for HTTP. The describes how QUIC transport features are used for HTTP. The
convention is for HTTP/3 to run over UDP port 443 [Port443] but this convention is for HTTP/3 to run over UDP port 443 [Port443] but this
is not a strict requirement. is not a strict requirement.
When HTTP/3 is encapsulated in QUIC, which is then encapsulated in When HTTP/3 is encapsulated in QUIC, which is then encapsulated in
skipping to change at page 27, line 17 skipping to change at page 27, line 4
standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which
describes how QUIC transport features are used for HTTP. The describes how QUIC transport features are used for HTTP. The
convention is for HTTP/3 to run over UDP port 443 [Port443] but this convention is for HTTP/3 to run over UDP port 443 [Port443] but this
is not a strict requirement. is not a strict requirement.
When HTTP/3 is encapsulated in QUIC, which is then encapsulated in When HTTP/3 is encapsulated in QUIC, which is then encapsulated in
UDP, streaming operators (and network operators) might see UDP UDP, streaming operators (and network operators) might see UDP
traffic patterns that are similar to HTTP(S) over TCP. Since earlier traffic patterns that are similar to HTTP(S) over TCP. Since earlier
versions of HTTP(S) rely on TCP, UDP ports may be blocked for any versions of HTTP(S) rely on TCP, UDP ports may be blocked for any
port numbers that are not commonly used, such as UDP 53 for DNS. port numbers that are not commonly used, such as UDP 53 for DNS.
Even when UDP ports are not blocked and HTTP/3 can flow, streaming Even when UDP ports are not blocked and HTTP/3 can flow, streaming
operators (and network operators) may severely rate-limit this operators (and network operators) may severely rate-limit this
traffic because they do not expect to see legitimate high-bandwidth traffic because they do not expect to see legitimate high-bandwidth
traffic such as streaming media over the UDP ports that HTTP/3 is traffic such as streaming media over the UDP ports that HTTP/3 is
using. using.
As noted in Section 4.5.2, because TCP provides a reliable, in-order As noted in Section 5.5.2, because TCP provides a reliable, in-order
delivery service for applications, any packet loss for a TCP delivery service for applications, any packet loss for a TCP
connection causes "head-of-line blocking", so that no TCP segments connection causes "head-of-line blocking", so that no TCP segments
arriving after a packet is lost will be delivered to the receiving arriving after a packet is lost will be delivered to the receiving
application until the lost packet is retransmitted, allowing in-order application until the lost packet is retransmitted, allowing in-order
delivery to the application to continue. As described in [RFC9000], delivery to the application to continue. As described in [RFC9000],
QUIC connections can carry multiple streams, and when packet losses QUIC connections can carry multiple streams, and when packet losses
do occur, only the streams carried in the lost packet are delayed. do occur, only the streams carried in the lost packet are delayed.
A QUIC extension currently being specified ([I-D.ietf-quic-datagram]) A QUIC extension currently being specified ([I-D.ietf-quic-datagram])
adds the capability for "unreliable" delivery, similar to the service adds the capability for "unreliable" delivery, similar to the service
provided by UDP, but these datagrams are still subject to the QUIC provided by UDP, but these datagrams are still subject to the QUIC
connection's congestion controller, providing some transport-level connection's congestion controller, providing some transport-level
congestion avoidance measures, which UDP does not. congestion avoidance measures, which UDP does not.
As noted in Section 5.2, there is increasing interest in transport As noted in Section 6.2, there is increasing interest in transport
protocol behaviors that responds to delay measurements, instead of protocol behaviors that respond to delay measurements, instead of
responding to packet loss. These behaviors may deliver improved user responding to packet loss. These behaviors may deliver improved user
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 use 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 chose 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 We do have experience with deploying new congestion controllers
without melting the Internet (CUBIC is one example), but the point without melting the Internet (CUBIC is one example), but the point
mentioned in Section 5.2 about TCP being implemented in operating mentioned in Section 6.2 about TCP being implemented in operating
system kernels is also different with QUIC. Although QUIC can be system kernels is also different with QUIC. Although QUIC can be
implemented in operating system kernels, one of the design goals when implemented in operating system kernels, one of the design goals when
this work was chartered was "QUIC is expected to support rapid, this work was chartered was "QUIC is expected to support rapid,
distributed development and testing of features", and to meet this distributed development and testing of features", and to meet this
expectation, many implementers have chosen to implement QUIC in user expectation, many implementers have chosen to implement QUIC in user
space, outside the operating system kernel, and to even distribute space, outside the operating system kernel, and to even distribute
QUIC libraries with their own applications. QUIC libraries with their own applications.
The decision to deploy a new version of QUIC is relatively The decision to deploy a new version of QUIC is relatively
uncontrolled, compared to other widely used transport protocols, and uncontrolled, compared to other widely used transport protocols, and
skipping to change at page 28, line 33 skipping to change at page 28, line 19
include. The sense of the room at IETF 105 was that the current include. The sense of the room at IETF 105 was that the current
major content providers understood what is at stake when they deploy major content providers understood what is at stake when they deploy
new congestion controllers, but this presentation, and the related new congestion controllers, but this presentation, and the related
discussion in TSVAREA minutes from IETF 105 ([tsvarea-105], are still discussion in TSVAREA minutes from IETF 105 ([tsvarea-105], are still
worth a look for new and rapidly growing content providers. 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-base 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 More broadly, [I-D.ietf-quic-manageability] discusses manageability
of the QUIC transport protocol, focusing on the implications of of the QUIC transport protocol, focusing on the implications of
QUIC's design and wire image on network operations involving QUIC QUIC's design and wire image on network operations involving QUIC
traffic. It discusses what network operators can consider in some traffic. It discusses what network operators can consider in some
detail. detail.
6. 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
remaining encrypted until it reaches the ultimate media consumer remaining encrypted until it reaches the ultimate media consumer
(in this document, referred to as "end-to-end media encryption"), (in this document, referred to as "end-to-end media encryption"),
and and
* 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 Both "hop-by-hop" and "end-to-end" encrypted transport may carry
media that is, in addition, encrypted at the application layer. 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.
skipping to change at page 29, line 39 skipping to change at page 29, line 23
"valid" (whatever that might mean). "valid" (whatever that might mean).
In this document, we will focus on media encrypted at the transport In this document, we will focus on media encrypted at the transport
layer, whether encrypted "hop-by-hop" or "end-to-end". Because media layer, whether encrypted "hop-by-hop" or "end-to-end". Because media
encrypted at the application layer will only be processed by encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport- application-level entities, this encryption does not have transport-
layer implications. layer implications.
Both "End-to-End" and "Hop-by-Hop" media encryption have specific Both "End-to-End" and "Hop-by-Hop" media encryption have specific
implications for streaming operators. These are described in implications for streaming operators. These are described in
Section 6.2 and Section 6.3. Section 7.2 and Section 7.3.
6.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
vulnerable to traffic analysis. An intermediary that can identify an vulnerable to traffic analysis. An intermediary that can identify an
encrypted media stream without decrypting it, may be able to encrypted media stream without decrypting it, may be able to
"fingerprint" the encrypted media stream of known content, and then "fingerprint" the encrypted media stream of known content, and then
match the targeted media stream against the fingerprints of known match the targeted media stream against the fingerprints of known
skipping to change at page 30, line 20 skipping to change at page 30, line 4
If traffic analysis is successful at identifying encrypted content If traffic analysis is successful at identifying encrypted content
and associating it with specific users, this breaks privacy as and associating it with specific users, this breaks privacy as
certainly as examining decrypted traffic. certainly as examining decrypted traffic.
Because HTTPS has historically layered HTTP on top of TLS, which is Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries do have access to in turn layered on top of TCP, intermediaries do have access to
unencrypted TCP-level transport information, such as retransmissions, unencrypted TCP-level transport information, such as retransmissions,
and some carriers exploited this information in attempts to improve and some carriers exploited this information in attempts to improve
transport-layer performance [RFC3135]. The most recent standardized transport-layer performance [RFC3135]. The most recent standardized
version of HTTPS, HTTP/3 [I-D.ietf-quic-http], uses the QUIC protocol version of HTTPS, HTTP/3 [I-D.ietf-quic-http], uses the QUIC protocol
[RFC9000] as its transport layer. QUIC relies on the TLS 1.3 initial [RFC9000] as its transport layer. QUIC relies on the TLS 1.3 initial
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.
6.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
in play. The first question is likely whether the content provider in play. The first question is likely whether the content provider
skipping to change at page 31, line 39 skipping to change at page 31, line 26
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 If a content provider chooses not to involve intermediaries, this
choice should be carefully considered. As an example, if media choice should be carefully considered. As an example, if media
manifests are encrypted end-to-end, network providers who had been manifests are encrypted end-to-end, network providers who had been
able to lower offered quality and reduce on their networks will no able to lower offered quality and reduce on their networks will no
longer be able to do that. Some resources that might inform this longer be able to do that. Some resources that might inform this
consideration are in [RFC8825] (for WebRTC) and consideration are in [RFC8825] (for WebRTC) and
[I-D.ietf-quic-manageability] (for HTTP/3 and QUIC). [I-D.ietf-quic-manageability] (for HTTP/3 and QUIC).
6.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 (DPI) to examine HTTP
request and response headers and identify the media content being request 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"
skipping to change at page 32, line 15 skipping to change at page 32, line 12
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".
Unfortunately, as noted in [RFC7258], there is no way to prevent Unfortunately, as noted in [RFC7258], there is no way to prevent
pervasive monitoring by an "attacker", while allowing monitoring by a pervasive monitoring by an "attacker", while allowing monitoring by a
more benign entity who "only" wants to use DPI to examine HTTP more benign entity who "only" wants to use DPI to examine HTTP
requests and responses in order to provide a better user experience. requests and responses in order to provide a better user experience.
If a modern encrypted transport protocol is used for end-to-end media If a modern encrypted transport protocol is used for end-to-end media
encryption, intermediary streaming operators are unable to examine encryption, intermediary streaming operators are unable to examine
transport and application protocol behavior. As described in transport and application protocol behavior. As described in
Section 6.2, only an intermediary streaming operator who is Section 7.2, only an intermediary streaming operator who is
explicitly authorized to examine packet payloads, rather than explicitly authorized to examine packet payloads, rather than
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.
7. Further Reading and References 8. Further Reading and References
Editor's note: This section is to be kept in a living document where Editor's note: This section is to be kept in a living document where
future references, links and/or updates to the existing references future references, links and/or updates to the existing references
will be reflected. That living document is likely to be an IETF- will be reflected. That living document is likely to be an IETF-
owned Wiki: https://tinyurl.com/streaming-opcons-reading owned Wiki: https://tinyurl.com/streaming-opcons-reading
7.1. Industry Terminology 8.1. Industry Terminology
* SVA Glossary: https://glossary.streamingvideoalliance.org/ * SVA Glossary: https://glossary.streamingvideoalliance.org/
* Datazoom Video Player Data Dictionary: * Datazoom Video Player Data Dictionary:
https://help.datazoom.io/hc/en-us/articles/360031323311 https://help.datazoom.io/hc/en-us/articles/360031323311
* Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/ * Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/
en-us/articles/360046177191 en-us/articles/360046177191
7.2. Surveys and Tutorials 8.2. Surveys and Tutorials
7.2.1. Encoding 8.2.1. Encoding
The following papers describe how video is encoded, different video The following papers describe how video is encoded, different video
encoding standards and tradeoffs in selecting encoding parameters. encoding standards and tradeoffs in selecting encoding parameters.
* Overview of the Versatile Video Coding (VVC) Standard and its * Overview of the Versatile Video Coding (VVC) Standard and its
Applications (https://ieeexplore.ieee.org/document/9503377) Applications (https://ieeexplore.ieee.org/document/9503377)
* Video Compression - From Concepts to the H.264/AVC Standard * Video Compression - From Concepts to the H.264/AVC Standard
(https://ieeexplore.ieee.org/document/1369695) (https://ieeexplore.ieee.org/document/1369695)
* Developments in International Video Coding Standardization After * Developments in International Video Coding Standardization After
AVC, With an Overview of Versatile Video Coding (VVC) AVC, With an Overview of Versatile Video Coding (VVC)
(https://ieeexplore.ieee.org/document/9328514) (https://ieeexplore.ieee.org/document/9328514)
* A Technical Overview of AV1 (https://ieeexplore.ieee.org/ * A Technical Overview of AV1 (https://ieeexplore.ieee.org/
document/9363937) document/9363937)
* CTU Depth Decision Algorithms for HEVC: A Survey * CTU Depth Decision Algorithms for HEVC: A Survey
(https://arxiv.org/abs/2104.08328) (https://arxiv.org/abs/2104.08328)
7.2.2. Packaging 8.2.2. Packaging
The following papers summarize the methods for selecting packaging The following papers summarize the methods for selecting packaging
configurations such as the resolution-bitrate pairs, segment configurations such as the resolution-bitrate pairs, segment
durations, use of constant vs. variable-duration segments, etc. durations, use of constant vs. variable-duration segments, etc.
* Deep Reinforced Bitrate Ladders for Adaptive Video Streaming * Deep Reinforced Bitrate Ladders for Adaptive Video Streaming
(https://dl.acm.org/doi/10.1145/3458306.3458873) (https://dl.acm.org/doi/10.1145/3458306.3458873)
* Comparing Fixed and Variable Segment Durations for Adaptive Video * Comparing Fixed and Variable Segment Durations for Adaptive Video
Streaming: a Holistic Analysis (https://dl.acm.org/ Streaming: a Holistic Analysis (https://dl.acm.org/
doi/10.1145/3339825.3391858) doi/10.1145/3339825.3391858)
7.2.3. Content Delivery 8.2.3. Content Delivery
The following links describe some of the issues and solutions The following links describe some of the issues and solutions
regarding the interconnecting of the content delivery networks. regarding the interconnecting of the content delivery networks.
* Open Caching: Open standards for Caching in ISP Networks: * Open Caching: Open standards for Caching in ISP Networks:
https://www.streamingvideoalliance.org/working-group/open-caching/ https://www.streamingvideoalliance.org/working-group/open-caching/
* Netflix Open Connect: https://openconnect.netflix.com * Netflix Open Connect: https://openconnect.netflix.com
7.2.4. ABR Algorithms 8.2.4. ABR Algorithms
The two surveys describe and compare different rate-adaptation The two surveys describe and compare different rate-adaptation
algorithms in terms of different metrics like achieved bitrate/ algorithms in terms of different metrics like achieved bitrate/
quality, stall rate/duration, bitrate switching frequency, fairness, quality, stall rate/duration, bitrate switching frequency, fairness,
network utilization, etc. network utilization, etc.
* A Survey on Bitrate Adaptation Schemes for Streaming Media Over * A Survey on Bitrate Adaptation Schemes for Streaming Media Over
HTTP (https://ieeexplore.ieee.org/document/8424813) HTTP (https://ieeexplore.ieee.org/document/8424813)
* A Survey of Rate Adaptation Techniques for Dynamic Adaptive * A Survey of Rate Adaptation Techniques for Dynamic Adaptive
Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970) Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970)
* Low-Latency Live Streaming: The following papers describe the 8.2.5. Low-Latency Live Adaptive Streaming
peculiarities of adaptive streaming in low-latency live streaming
scenarios. 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 * Catching the Moment with LoL+ in Twitch-like Low-latency Live
Streaming Platforms (https://ieeexplore.ieee.org/document/9429986) Streaming Platforms (https://ieeexplore.ieee.org/document/9429986)
* Data-driven Bandwidth Prediction Models and Automated Model * Data-driven Bandwidth Prediction Models and Automated Model
Selection for Low Latency (https://ieeexplore.ieee.org/ Selection for Low Latency (https://ieeexplore.ieee.org/
document/9154522) document/9154522)
* Performance Analysis of ACTE: A Bandwidth Prediction Method for * Performance Analysis of ACTE: A Bandwidth Prediction Method for
Low-latency Chunked Streaming (https://dl.acm.org/ Low-latency Chunked Streaming (https://dl.acm.org/
skipping to change at page 34, line 31 skipping to change at page 34, line 32
(https://dl.acm.org/doi/10.1145/3339825.3397042) (https://dl.acm.org/doi/10.1145/3339825.3397042)
* Tightrope Walking in Low-latency Live Streaming: Optimal Joint * Tightrope Walking in Low-latency Live Streaming: Optimal Joint
Adaptation of Video Rate and Playback Speed (https://dl.acm.org/ Adaptation of Video Rate and Playback Speed (https://dl.acm.org/
doi/10.1145/3458305.3463382) doi/10.1145/3458305.3463382)
* Content-aware Playback Speed Control for Low-latency Live * Content-aware Playback Speed Control for Low-latency Live
Streaming of Sports (https://dl.acm.org/ Streaming of Sports (https://dl.acm.org/
doi/10.1145/3458305.3478437) doi/10.1145/3458305.3478437)
7.2.5. Server/Client/Network Collaboration 8.2.6. Server/Client/Network Collaboration
The following papers explain the benefits of server and network The following papers explain the benefits of server and network
assistance in client-driven streaming systems. There is also a good assistance in client-driven streaming systems. There is also a good
reference about how congestion affects video quality and how rate reference about how congestion affects video quality and how rate
control works in streaming applications. control works in streaming applications.
* Manus Manum Lavat: Media Clients and Servers Cooperating with * Manus Manum Lavat: Media Clients and Servers Cooperating with
Common Media Client/Server Data (https://dl.acm.org/ Common Media Client/Server Data (https://dl.acm.org/
doi/10.1145/3472305.3472886) doi/10.1145/3472305.3472886)
skipping to change at page 35, line 12 skipping to change at page 35, line 12
* Caching in HTTP Adaptive Streaming: Friend or Foe? * Caching in HTTP Adaptive Streaming: Friend or Foe?
(https://dl.acm.org/doi/10.1145/2578260.2578270) (https://dl.acm.org/doi/10.1145/2578260.2578270)
* A Survey on Multi-Access Edge Computing Applied to Video * A Survey on Multi-Access Edge Computing Applied to Video
Streaming: Some Research Issues and Challenges Streaming: Some Research Issues and Challenges
(https://ieeexplore.ieee.org/document/9374553) (https://ieeexplore.ieee.org/document/9374553)
* The Ultimate Guide to Internet Congestion Control * The Ultimate Guide to Internet Congestion Control
(https://www.compiralabs.com/ultimate-guide-congestion-control) (https://www.compiralabs.com/ultimate-guide-congestion-control)
7.2.6. QoE Metrics 8.2.7. QoE Metrics
The following papers describe various QoE metrics one can use in The following papers describe various QoE metrics one can use in
streaming applications. streaming applications.
* QoE Management of Multimedia Streaming Services in Future * QoE Management of Multimedia Streaming Services in Future
Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/ Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/
document/8930519) document/8930519)
* A Survey on Quality of Experience of HTTP Adaptive Streaming * A Survey on Quality of Experience of HTTP Adaptive Streaming
(https://ieeexplore.ieee.org/document/6913491) (https://ieeexplore.ieee.org/document/6913491)
* QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open * QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open
Challenges (https://ieeexplore.ieee.org/document/8666971) Challenges (https://ieeexplore.ieee.org/document/8666971)
7.2.7. Point Clouds and Immersive Media 8.2.8. Point Clouds and Immersive Media
The following papers explain the latest developments in the immersive The following papers explain the latest developments in the immersive
media domain (for video and audio) and the developing standards for media domain (for video and audio) and the developing standards for
such media. such media.
* A Survey on Adaptive 360o Video Streaming: Solutions, Challenges * A Survey on Adaptive 360o Video Streaming: Solutions, Challenges
and Opportunities (https://ieeexplore.ieee.org/document/9133103) and Opportunities (https://ieeexplore.ieee.org/document/9133103)
* MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/ * MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/
document/9374648) document/9374648)
skipping to change at page 36, line 5 skipping to change at page 36, line 5
* MPEG Standards for Compressed Representation of Immersive Audio * MPEG Standards for Compressed Representation of Immersive Audio
(https://ieeexplore.ieee.org/document/9444109) (https://ieeexplore.ieee.org/document/9444109)
* An Overview of Omnidirectional MediA Format (OMAF) * An Overview of Omnidirectional MediA Format (OMAF)
(https://ieeexplore.ieee.org/document/9380215) (https://ieeexplore.ieee.org/document/9380215)
* From Capturing to Rendering: Volumetric Media Delivery with Six * From Capturing to Rendering: Volumetric Media Delivery with Six
Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522) Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522)
7.3. Open-Source Tools 8.3. Open-Source Tools
* 5G-MA: https://www.5g-mag.com/reference-tools * 5G-MA: https://www.5g-mag.com/reference-tools
* dash.js: http://reference.dashif.org/dash.js/latest/samples/ * dash.js: http://reference.dashif.org/dash.js/latest/samples/
* DASH-IF Conformance: https://conformance.dashif.org * DASH-IF Conformance: https://conformance.dashif.org
* ExoPlayer: https://github.com/google/ExoPlayer * ExoPlayer: https://github.com/google/ExoPlayer
* FFmpeg: https://www.ffmpeg.org/ * FFmpeg: https://www.ffmpeg.org/
skipping to change at page 36, line 27 skipping to change at page 36, line 27
* GPAC: https://gpac.wp.imt.fr/ * GPAC: https://gpac.wp.imt.fr/
* hls.js: https://github.com/video-dev/hls.js * hls.js: https://github.com/video-dev/hls.js
* OBS Studio: https://obsproject.com/ * OBS Studio: https://obsproject.com/
* Shaka Player: https://github.com/google/shaka-player * Shaka Player: https://github.com/google/shaka-player
* Shaka Packager: https://github.com/google/shaka-packager * Shaka Packager: https://github.com/google/shaka-packager
* Traffic Control CDN: https://trafficcontrol.incubator.apache.org * Traffic Control CDN: https://trafficcontrol.apache.org/
* VideoLAN: https://www.videolan.org/projects/ * VideoLAN: https://www.videolan.org/projects/
* video.js: https://github.com/videojs/video.js * video.js: https://github.com/videojs/video.js
7.4. Technical Events 8.4. Technical Events
* ACM Mile High Video (MHV): https://mile-high.video/ * ACM Mile High Video (MHV): https://mile-high.video/
* ACM Multimedia Systems (MMSys): https://acmmmsys.org * ACM Multimedia Systems (MMSys): https://acmmmsys.org
* ACM Multimedia (MM): https://acmmm.org * ACM Multimedia (MM): https://acmmm.org
* ACM NOSSDAV: https://www.nossdav.org/ * ACM NOSSDAV: https://www.nossdav.org/
* ACM Packet Video: https://packet.video/ * ACM Packet Video: https://packet.video/
skipping to change at page 37, line 14 skipping to change at page 37, line 14
* IEEE Int. Conf. on Multimedia and Expo (ICME) * IEEE Int. Conf. on Multimedia and Expo (ICME)
* Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws * Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws
* Live Video Stack: https://sh2021.livevideostack.com * Live Video Stack: https://sh2021.livevideostack.com
* Picture Coding Symp. (PCS) * Picture Coding Symp. (PCS)
* SCTE Expo: https://expo.scte.org/ * SCTE Expo: https://expo.scte.org/
7.5. List of Organizations Working on Streaming Media 8.5. List of Organizations Working on Streaming Media
* 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/ * 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/
sa4-codec sa4-codec
* 5G-MAG: https://www.5g-mag.com/ * 5G-MAG: https://www.5g-mag.com/
* AOM: http://aomedia.org/ * AOM: http://aomedia.org/
* ATSC: https://www.atsc.org/ * ATSC: https://www.atsc.org/
skipping to change at page 38, line 5 skipping to change at page 38, line 5
* SMPTE: https://www.smpte.org/ * SMPTE: https://www.smpte.org/
* SRT Alliance: https://www.srtalliance.org/ * SRT Alliance: https://www.srtalliance.org/
* Video Services Forum: https://vsf.tv/ * Video Services Forum: https://vsf.tv/
* VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx * VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx
* W3C: https://www.w3.org/ * W3C: https://www.w3.org/
7.6. Topics to Keep an Eye on 8.6. Topics to Keep an Eye on
7.6.1. 5G and Media 8.6.1. 5G and Media
5G new radio and systems technologies provide new functionalities for 5G new radio and systems technologies provide new functionalities for
video distribution. 5G targets not only smartphones, but also new video distribution. 5G targets not only smartphones, but also new
devices such as augmented reality glasses or automotive receivers. devices such as augmented reality glasses or automotive receivers.
Higher bandwidth, lower latencies, edge and cloud computing Higher bandwidth, lower latencies, edge and cloud computing
functionalities, service-based architectures, low power consumption, functionalities, service-based architectures, low power consumption,
broadcast/multicast functionalities and other network functions come broadcast/multicast functionalities and other network functions come
hand in hand with new media formats and processing capabilities hand in hand with new media formats and processing capabilities
promising better and more consistent quality for traditional video promising better and more consistent quality for traditional video
streaming services as well as enabling new experiences such as streaming services as well as enabling new experiences such as
immersive media and augmented realities. immersive media and augmented realities.
* 5G Multimedia Standardization (https://www.riverpublishers.com/ * 5G Multimedia Standardization (https://www.riverpublishers.com/
journal_read_html_article.php?j=JICTS/6/1/8) journal_read_html_article.php?j=JICTS/6/1/8)
7.6.2. Ad Insertion 8.6.2. Ad Insertion
Ads can be inserted at different stages in the streaming workflow, on Ads can be inserted at different stages in the streaming workflow, on
the server side or client side. The DASH-IF guidelines detail the server side or client side. The DASH-IF guidelines detail
server-side ad-insertion with period replacements based on server-side ad-insertion with period replacements based on
manipulating the manifest. HLS interstitials provide a similar manipulating the manifest. HLS interstitials provide a similar
approach. The idea is that the manifest can be changed and point to approach. The idea is that the manifest can be changed and point to
a sub-playlist of segments, possibly located on a different location. a sub-playlist of segments, possibly located on a different location.
This approach results in efficient resource usage in the network, as This approach results in efficient resource usage in the network, as
duplicate caching is avoided, but some intelligence at the player is duplicate caching is avoided, but some intelligence at the player is
needed to deal with content transitions (e.g., codec changes, needed to deal with content transitions (e.g., codec changes,
skipping to change at page 39, line 12 skipping to change at page 39, line 12
* SCTE-214-1: https://www.scte.org/standards-development/library/ * SCTE-214-1: https://www.scte.org/standards-development/library/
standards-catalog/ansiscte-214-1-2016/ standards-catalog/ansiscte-214-1-2016/
* RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital * RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital
Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/ Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/
document/7291518 document/7291518
* IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio- * IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio-
video/tech-lab-digital-video-suite/ video/tech-lab-digital-video-suite/
7.6.3. Contribution and Ingest 8.6.3. Contribution and Ingest
There are different contribution and ingest specifications dealing There are different contribution and ingest specifications dealing
with different use cases. A common case is contribution that with different use cases. A common case is contribution that
previously happened over satellite to a broadcast or streaming previously happened over satellite to a broadcast or streaming
headend. RIST and SRT are examples of such contribution protocols. headend. RIST and SRT are examples of such contribution protocols.
Within a streaming headend the encoder and packager/CDN may have an Within a streaming headend the encoder and packager/CDN may have an
ingest/contribution interface as well. This is specified by the ingest/contribution interface as well. This is specified by the
DASH-IF Ingest. DASH-IF Ingest.
* DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest * DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest
* RIST: https://www.rist.tv/ * RIST: https://www.rist.tv/
* SRT: https://github.com/Haivision/srt * SRT: https://github.com/Haivision/srt
7.6.4. Synchronized Encoding and Packaging 8.6.4. Synchronized Encoding and Packaging
Practical streaming headends need redundant encoders and packagers to Practical streaming headends need redundant encoders and packagers to
operate without glitches and blackouts. The redundant operation operate without glitches and blackouts. The redundant operation
requires synchronization between two or more encoders and also requires synchronization between two or more encoders and also
between two or more packagers that possibly handle different inputs between two or more packagers that possibly handle different inputs
and outputs, generating compatible inter-changeable output and outputs, generating compatible inter-changeable output
representations. This problem is important for anyone developing a representations. This problem is important for anyone developing a
streaming headend at scale, and the synchronization problem is streaming headend at scale, and the synchronization problem is
currently under discussion in the wider community. Follow the currently under discussion in the wider community. Follow the
developments at: https://sites.google.com/view/encodersyncworkshop/ developments at: https://sites.google.com/view/encodersyncworkshop/
home home
7.6.5. WebRTC-Based Streaming 8.6.5. WebRTC-Based Streaming
WebRTC is increasingly being used for streaming of time-sensitive WebRTC is increasingly being used for streaming of time-sensitive
content such as live sporting events. Innovations in cloud computing content such as live sporting events. Innovations in cloud computing
allow implementers to efficiently scale delivery of content using allow implementers to efficiently scale delivery of content using
WebRTC. Support for WebRTC communication is available on all modern WebRTC. Support for WebRTC communication is available on all modern
web browsers and is available on native clients for all major web browsers and is available on native clients for all major
platforms. platforms.
* DASH-IF WebRTC Discussions: https://dashif.org/webRTC/ * DASH-IF WebRTC Discussions: https://dashif.org/webRTC/
* Overview of WebRTC: https://webrtc.org/ * Overview of WebRTC: https://webrtc.org/
8. IANA Considerations 9. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
9. Security Considerations 10. Security Considerations
This document introduces no new security issues. Security is an important matter for streaming media applications and
it was briefly touched on in Section 7.1. This document itself
introduces no new security issues.
10. Acknowledgments 11. Acknowledgments
Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen, Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,
Mike English, Roni Even, and Will Law for very helpful suggestions, Matt Stock, Mike English, Renan Krishna, Roni Even, and Will Law for
reviews and comments. very helpful suggestions, reviews and comments.
(If we missed your name, please let us know!) (If we missed your name, please let us know!)
11. 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/>.
skipping to change at page 41, line 38 skipping to change at page 41, line 42
<https://ieeexplore.ieee.org/document/6691442>. <https://ieeexplore.ieee.org/document/6691442>.
[Encodings] [Encodings]
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., and V. Jacobson, Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
"BBR Congestion Control", Work in Progress, Internet- Jacobson, "BBR Congestion Control", Work in Progress,
Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
July 2017, <https://datatracker.ietf.org/doc/html/draft- control-01, 7 November 2021,
cardwell-iccrg-bbr-congestion-control-00>. <https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-01>.
[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-09, Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-10,
27 April 2021, <https://datatracker.ietf.org/doc/html/ 8 November 2021, <https://datatracker.ietf.org/doc/html/
draft-pantos-hls-rfc8216bis-09>. draft-pantos-hls-rfc8216bis-10>.
[I-D.ietf-httpbis-cache]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Caching", Work in Progress, Internet-Draft, draft-ietf-
httpbis-cache-19, 12 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-19>.
[I-D.ietf-quic-datagram] [I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet- Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-04, 8 September 2021, Draft, draft-ietf-quic-datagram-07, 8 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-04>. datagram-07>.
[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
skipping to change at page 42, line 32 skipping to change at page 42, line 49
[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- event definitions for qlog", Work in Progress, Internet-
Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021, Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021,
<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-00>.
[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-00, 10 June 2021, ietf-quic-qlog-main-schema-01, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
qlog-main-schema-00>. qlog-main-schema-01>.
[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-00, 10 June 2021,
<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-00>.
[IAB-ADS] "IAB", n.d., <https://www.iab.com/>. [IAB-ADS] "IAB", n.d., <https://www.iab.com/>.
skipping to change at page 46, line 10 skipping to change at page 46, line 25
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/rfc/rfc6817>. <https://www.rfc-editor.org/rfc/rfc6817>.
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Delay Metric (RTCP) Extended Report (XR) Block for Delay Metric
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
<https://www.rfc-editor.org/rfc/rfc6843>. <https://www.rfc-editor.org/rfc/rfc6843>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/rfc/rfc7234>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>. 2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/rfc/rfc7510>. <https://www.rfc-editor.org/rfc/rfc7510>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
skipping to change at page 48, line 12 skipping to change at page 48, line 15
[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]
Yaqoob, A., Bi, T., and G.-M. Muntean, "A Survey on
Adaptive 360° Video Streaming: Solutions, Challenges and
Opportunities", IEEE Communications Surveys & Tutorials ,
July 2020, <https://ieeexplore.ieee.org/document/9133103>.
[tsvarea-105] [tsvarea-105]
"TSVAREA Minutes - IETF 105", July 2019, "TSVAREA Minutes - IETF 105", July 2019,
<https://datatracker.ietf.org/meeting/105/materials/ <https://datatracker.ietf.org/meeting/105/materials/
minutes-105-tsvarea-00>. minutes-105-tsvarea-00>.
Authors' Addresses Authors' Addresses
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
 End of changes. 137 change blocks. 
318 lines changed or deleted 347 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/