< draft-ietf-mops-streaming-opcons-06.txt   draft-ietf-mops-streaming-opcons-07.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: 13 January 2022 Networked Media Expires: 19 March 2022 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
12 July 2021 15 September 2021
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-06 draft-ietf-mops-streaming-opcons-07
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 in streaming of video and other
high-bitrate media over the Internet. high-bitrate media over the Internet.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 January 2022. This Internet-Draft will expire on 19 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified 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 . . . . . . . 4 1.1.1. Venues for Contribution and Discussion . . . . . . . 5
1.1.2. History of Public Discussion . . . . . . . . . . . . 5 1.1.2. History of Public Discussion . . . . . . . . . . . . 5
2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 5 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 6
2.1. Scaling Requirements for Media Delivery . . . . . . . . . 5 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 6
2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 5 2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 6
2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6
2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 7 2.2. Path Bandwidth Constraints . . . . . . . . . . . . . . . 7
2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8
2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8 2.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9
2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 9 2.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 9
2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 10 2.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 10
3. Latency Considerations . . . . . . . . . . . . . . . . . . . 11 2.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11
3.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 12 2.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12
3.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 12 3. Latency Considerations . . . . . . . . . . . . . . . . . . . 13
3.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 13 3.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14
3.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15
3.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16
3.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Adaptive Encoding, Adaptive Delivery, and Measurement 4. Adaptive Encoding, Adaptive Delivery, and Measurement
Collection . . . . . . . . . . . . . . . . . . . . . . . 14 Collection . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 15 4.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 17
4.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 15 4.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18
4.4. Bitrate Detection Challenges . . . . . . . . . . . . . . 16 4.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Idle Time between Segments . . . . . . . . . . . . . 16 4.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20
4.4.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 17 4.5.1. Idle Time between Segments . . . . . . . . . . . . . 20
4.4.3. Wide and Rapid Variation in Path Capacity . . . . . . 17 4.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21
4.5. Measurement Collection . . . . . . . . . . . . . . . . . 18 4.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22
4.5.1. CTA-2066: Streaming Quality of Experience Events, 4.6. Measurement Collection . . . . . . . . . . . . . . . . . 22
Properties and Metrics . . . . . . . . . . . . . . . 18 4.6.1. CTA-2066: Streaming Quality of Experience Events,
4.5.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 19 Properties and Metrics . . . . . . . . . . . . . . . 23
4.6. Unreliable Transport . . . . . . . . . . . . . . . . . . 19 4.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23
4.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 23
5. Evolution of Transport Protocols and Transport Protocol 5. Evolution of Transport Protocols and Transport Protocol
Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 20 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 20 5.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24
5.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 21 5.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25
5.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 22 5.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 26
6. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 24 6. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28
6.1. General Considerations for Media Encryption . . . . . . . 25 6.1. General Considerations for Media Encryption . . . . . . . 29
6.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 26 6.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30
6.3. Considerations for "End-to-End" Media Encryption . . . . 27 6.3. Considerations for "End-to-End" Media Encryption . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Further Reading and References . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.1. Industry Terminology . . . . . . . . . . . . . . . . . . 32
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 7.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 32
10. Informative References . . . . . . . . . . . . . . . . . . . 28 7.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 7.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33
7.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 33
7.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 33
7.2.5. Server/Client/Network Collaboration . . . . . . . . . 34
7.2.6. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35
7.2.7. Point Clouds and Immersive Media . . . . . . . . . . 35
7.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36
7.4. Technical Events . . . . . . . . . . . . . . . . . . . . 36
7.5. List of Organizations Working on Streaming Media . . . . 37
7.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38
7.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38
7.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 38
7.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 39
7.6.4. Synchronized Encoding and Packaging . . . . . . . . . 39
7.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
As the internet has grown, an increasingly large share of the traffic As the internet has grown, an increasingly large share of the traffic
delivered to end users has become video. Estimates put the total delivered to end users has become video. Estimates put the total
share of internet video traffic at 75% in 2019, expected to grow to share of internet video traffic at 75% in 2019, expected to grow to
82% by 2022. This estimate projects the gross volume of video 82% by 2022. This estimate projects the gross volume of video
traffic will more than double during this time, based on a compound traffic will more than double during this time, based on a compound
annual growth rate continuing at 34% (from Appendix D of [CVNI]). annual growth rate continuing at 34% (from Appendix D of [CVNI]).
skipping to change at page 7, line 5 skipping to change at page 7, line 17
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 Requirements 2.2. Path Bandwidth Constraints
Even when the bandwidth requirements for video streams along a path
are well understood, additional analysis is required to understand
the contraints on bandwidth at various points in the network. This
analysis is necessary because media servers may react to bandwith
constraints using two independent feedback loops:
* Media servers often respond to application-level feedback from the
media player that indicates a bottleneck link somewhere along the
path, by adjusting the amount of media that the media server will
send to the media player in a given timeframe. This is described
in greater detail in Section 4.
* Media servers also typically implement transport protocols with
capacity-seeking congestion controllers that probe for bandwidth,
and adjust the sending rate based on transport mechanisms. This
is described in greater detail in Section 5.
The result is that these two (potentially competing) "helpful"
mechanisms each respond to the same bottleneck with no coordination
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
is significantly lower than what could have been achieved.
In one example, if a media server overestimates the available
handwidth to the media player,
* the transport protocol detects loss due to congestion, and reduces
its sending window size per round trip,
* the media server adapts to application-level feedback from the
media player, and reduces its own sending rate,
* the transport protocol sends media at the new, lower rate, and
confirms that this new, lower rate is "safe", because no
transport-level loss is occuring, but
* because the media server continues to send at the new, lower rate,
the transport protocol's maximum sending rate is now limited by
the amount of information the media server queues for
transmission, so
* the transport protocol can't probe for available path bandwidth by
sending at a higher rate.
In order to avoid these types of situations, which can potentially
affect all the users whose streaming media traverses a bottleneck
link, there are several possible mitigations that streaming operators
can use, but the first step toward mitigating a problem is knowing
when that problem occurs.
2.2.1. Know Your Network Traffic
There are many reasons why path characteristics might change
suddenly, for example,
* "cross traffic" that traverses part of the path, especially if
this traffic is "inelastic", and does not, itself, respond to
indications of path congestion.
* routing changes, which can happen in normal operation, especially
if the new path now includes path segments that are more heavily
loaded, offer lower total bandwidth, or simply cover more
distance.
Recognizing that a path carrying streaming media is "not behaving the
way it normally does" is fundamental. Analytics that aid in that
recognition can be more or less sophisticated, and can be as simple
as noticing that the apparent round trip times for media traffic
carried over TCP transport on some paths are suddenly and
significantly longer than usual. Passive monitors can detect changes
in the elapsed time between the acknowledgements for specific TCP
segments from a TCP receiver, since TCP octet sequence numbers and
acknowledgements for those sequence numbers are "carried in the
clear", even if the TCP payload itself is encrypted. See Section 5.2
for more information.
As transport protocols evolve to encrypt their transport header
fields, one side effect of increasing encryption is that the kind of
passive monitoring, or even "performance enhancement" ([RFC3135])
that was possible with the older transport protocols (UDP, described
in Section 5.1 and TCP, described in Section 5.2) is no longer
possible with newer transport protocols such as QUIC (described in
Section 5.3). The IETF has specified a "latency spin bit" mechanism
in Section 17.4 of [RFC9000] to allow passive latency monitoring from
observation points on the network path throughout the duration of a
connection, but currently chartered work in the IETF is focusing on
end-point monitoring and reporting, rather than on passive
monitoring.
One example is the "qlog" mechanism [I-D.ietf-quic-qlog-main-schema],
a protocol-agnostic mechanism used to provide better visibility for
encrypted protocols such as QUIC ([I-D.ietf-quic-qlog-quic-events])
and for HTTP/3 ([I-D.ietf-quic-qlog-h3-events]).
2.3. Path Requirements
The bitrate requirements in Section 2.1 are per end-user actively The bitrate requirements in Section 2.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.
skipping to change at page 7, line 27 skipping to change at page 9, line 40
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.3. Caching Systems 2.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 [RFC7234]). This is subject to the usual considerations for
caching - for example, how much data must be cached to make a caching - for example, how much data must be cached to make a
significant difference to the requester, and how the benefits of significant difference to the requester, and how the benefits of
caching and pre-loading caches balances against the costs of tracking caching and pre-loading caches balances against the costs of tracking
"stale" content in caches and refreshing that content. "stale" content in caches and refreshing that content.
skipping to change at page 8, line 15 skipping to change at page 10, line 23
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.4), mechanisms to meet the needs of users. In some cases (Section 2.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.5, Section 2.6). (Section 2.6, Section 2.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.4. Predictable Usage Profiles 2.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.5. Unpredictable Usage Profiles 2.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
skipping to change at page 10, line 5 skipping to change at page 12, line 10
that these hosts placed on their network. These efforts were met by that these hosts placed on their network. These efforts were met by
increased use of encryption in Bittorrent, similar to an arms race, increased use of encryption in Bittorrent, similar to an arms race,
and set off discussions about "Net Neutrality" and calls for and set off discussions about "Net Neutrality" and calls for
regulatory action. 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.6. Extremely Unpredictable Usage Profiles 2.7. Extremely Unpredictable Usage Profiles
The causes of unpredictable usage described in Section 2.5 were more The causes of unpredictable usage described in Section 2.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 11, line 47 skipping to change at page 14, line 4
(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 3.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.
This level of latency is sometimes necessary for real-time Some media content providers aim to achieve this level of latency for
interactive applications such as video conferencing, operation of live media events. This introduces new challenges relative to less-
remote control devices or vehicles, or remotely hosted real-time restricted levels of latency requirements because this latency is the
gaming systems. Some media content providers aim to achieve this same scale as commonly observed end-to-end network latency variation
level of latency for live media events involving sports, but have (for example, due to effects such as bufferbloat ([CoDel]), Wi-Fi
usually so far been unsuccessful over the internet at scale, though error correction, or packet reordering). These effects can make it
it is often possible within a localized environment with a controlled difficult to achieve this level of latency for the general case, and
network, such as inside a specific venue connected to the event. may require tradeoffs in relatively frequent user-visible media
Applications operating in this domain that encounter transient artifacts. However, for controlled environments or targeted networks
network events such as loss or reordering of some packets often that provide mitigations against such effects, this level of latency
experience user-visible artifacts in the media. is potentially achievable with the right provisioning.
Applications requiring ultra low latency for media delivery are Applications requiring ultra low latency for media delivery are
usually tightly constrained on the available choices for media usually tightly constrained on the available choices for media
transport technologies, and sometimes may need to operate in transport technologies, and sometimes may need to operate in
controlled environments to reliably achieve their latency and quality controlled environments to reliably achieve their latency and quality
goals. goals.
Most applications operating over IP networks and requiring latency Most applications operating over IP networks and requiring latency
this low use the Real-time Transport Protocol (RTP) [RFC3550] or this low use the Real-time Transport Protocol (RTP) [RFC3550] or
WebRTC [RFC8825], which uses RTP for the media transport as well as WebRTC [RFC8825], which uses RTP for the media transport as well as
several other protocols necessary for safe operation in browsers. several other protocols necessary for safe operation in browsers.
Worth noting is that many applications for ultra low-latency delivery Worth noting is that many applications for ultra low-latency delivery
do not need to scale to more than one user at a time, which do not need to scale to more than a few users at a time, which
simplifies many delivery considerations relative to other use cases. simplifies many delivery considerations relative to other use cases.
For applications that need to replicate streams to multiple users,
especially at a scale exceeding tens of users, this level of latency
has historically been nearly impossible to achieve except with the
use of multicast or planned provisioning in controlled networks.
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 3.2. Low-Latency Live
skipping to change at page 14, line 44 skipping to change at page 17, line 4
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 4. Adaptive Encoding, Adaptive Delivery, and Measurement Collection
4.1. Overview 4.1. Overview
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
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
that the buffer is never empty, however it also can have significant
complexity when things like personalization or ad workflows are
introduced.
The challenges in filling the buffer in a timely way fall into two
broad categories: 1. content selection and 2. content variation.
Content selection comprises all of the steps needed to determine
which content variation to offer the client. Content variation is
the number of content options that exist at any given selection
point. A common example, easily visualized, is Adaptive BitRate
(ABR), described in more detail below. The mechanism used to select
the bitrate is part of the content selection, and the content
variation are all of the different bitrate renditions.
Adaptive BitRate (ABR) is a sort of application-level response Adaptive BitRate (ABR) is a sort of application-level response
strategy in which the streaming client attempts to detect the strategy in which the streaming client attempts to detect the
available bandwidth of the network path by observing the successful available bandwidth of the network path by observing the successful
application-layer download speed, then chooses a bitrate for each of application-layer download speed, then chooses a bitrate for each of
the video, audio, subtitles and metadata (among the limited number of the video, audio, subtitles and metadata (among the limited number of
available options) that fits within that bandwidth, typically available options) that fits within that bandwidth, typically
adjusting as changes in available bandwidth occur in the network or adjusting as changes in available bandwidth occur in the network or
changes in capabilities occur during the playback (such as available changes in capabilities occur during the playback (such as available
memory, CPU, display size, etc.). memory, CPU, display size, etc.).
skipping to change at page 16, line 5 skipping to change at page 18, line 27
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. Bitrate Detection Challenges 4.4. Advertising
A variety of business models exist for producers of streaming media.
Some content providers derive the majority of the revenue associated
with streaming media directly from consumer subscriptions or one-time
purchases. Others derive the majority of their streaming media
associated revenue from advertising. Many content providers derive
income from a mix of these and other sources of funding. The
inclusion of advertising alongside or interspersed with streaming
media content is therefore common in today's media landscape.
Some commonly used forms of advertising can introduce potential user
experience issues for a media stream. This section provides a very
brief overview of a complex and evolving space, but a complete
coverage of the potential issues is out of scope for this document.
The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can
also be used to enable the dynamic insertion of advertisements.
Ads may be inserted either with Client Side Ad Insertion (CSAI) or
Server Side Ad Insertion (SSAI). In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same
during advertisements, but will include media segments that contain
the advertising. In SSAI, the media segments may or may not be
sourced from an external ad server like with CSAI.
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently. If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) are able
to be accessed quickly. The less targeted, the more likely the ad
requests can be consolidated and can leverage the same caching
techniques as the video content.
In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the
video so that the segments share the same encoding properties such as
bitrate, dynamic range, and resolution. However, in many cases ad
servers integrate with a Supply Side Platform (SSP) that offers
advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs)
that collect money from advertisers for delivering the
advertisements. Most such Ad Exchanges use application-level
protocol specifications published by the Interactive Advertising
Bureau [IAB-ADS], an industry trade organization.
This ecosystem balances several competing objectives, and integrating
with it naively can produce surprising user experience results. For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, either of which can
sometimes result in video stalls. For another example, since the
inserted ads are often produced independently they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Additionally, this market historically has had incidents of ad fraud
(misreporting of ad delivery to end users for financial gain). As a
mitigation for concerns driven by those incidents, some SSPs have
required the use of players with features like reporting of ad
delivery, or providing information that can be used for user
tracking. Some of these and other measures have raised privacy
concerns for end users.
In general this is a rapidly developing space with many
considerations, and media streaming operators engaged in advertising
may need to research these and other concerns to find solutions that
meet their user experience, user privacy, and financial goals. For
further reading on mitigations, [BAP] has published some standards
and best practices based on user experience research.
4.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
skipping to change at page 16, line 29 skipping to change at page 20, line 32
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 ABR
bitrate selection and on user quality of experience, especially where bitrate selection and on user quality of experience, especially where
players use naive measurement strategies and selection algorithms players use naive measurement strategies and selection algorithms
that don't account for the likelihood of bandwidth measurements that that don't account for the likelihood of bandwidth measurements that
diverge from the true path capacity. diverge from the true path capacity.
4.4.1. Idle Time between Segments 4.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 17, line 21 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.4.2. Head-of-Line Blocking 4.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.
skipping to change at page 17, line 44 skipping to change at page 22, line 9
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. This can appear as a stall of some time,
followed by a sudden leap that can far exceed the actual capacity of followed by a sudden leap that can far exceed the actual capacity of
the transport path from the server when the hole in the received data the transport path from the server when the hole in the received data
is filled by a later retransmission. is filled by a later 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 5.3 for more details.
4.4.3. Wide and Rapid Variation in Path Capacity 4.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.5. Measurement Collection 4.6. Measurement Collection
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. 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.5.1. CTA-2066: Streaming Quality of Experience Events, Properties and 4.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.5.2. CTA-5004: Common Media Client Data (CMCD) 4.6.2. CTA-5004: Common Media Client Data (CMCD)
Many assumes that the CDNs have a holistic view into the health and Many assumes 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.6. Unreliable Transport 4.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 21, line 38 skipping to change at page 26, line 4
protocol to limit the impact of applications that sent a significant protocol to limit the impact of applications that sent a significant
number of packets, in either or both directions, on other users. number of packets, in either or both directions, on other users.
Although early versions of TCP were not particularly good at limiting Although early versions of TCP were not particularly good at limiting
this impact [RFC0793], the addition of Slow Start and Congestion this impact [RFC0793], the addition of Slow Start and Congestion
Avoidance, as described in [RFC2001], were critical in allowing TCP- Avoidance, as described in [RFC2001], were critical in allowing TCP-
based applications to "use as much bandwidth as possible, but to based applications to "use as much bandwidth as possible, but to
avoid using more bandwidth than was possible". Although dozens of avoid using more bandwidth than was possible". Although dozens of
RFCs have been written refining TCP decisions about what to send, how RFCs have been written refining TCP decisions about what to send, how
much to send, and when to send it, since 1988 [Jacobson-Karels] the much 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
acknowledgments for packets that were successfully sent and received, acknowledgements for packets that were successfully sent and
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
avoid contention, as some TCP-based applications like FTP were avoid contention, as some TCP-based applications like FTP were
largely replaced by other TCP-based applications like HTTP, the largely replaced by other TCP-based applications like HTTP, the
transport behavior remained consistent. transport behavior remained consistent.
skipping to change at page 23, line 4 skipping to change at page 27, line 17
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.4.2, because TCP provides a reliable, in-order As noted in Section 4.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
skipping to change at page 28, line 22 skipping to change at page 32, line 25
Section 6.2, only an intermediary streaming operator who is Section 6.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. IANA Considerations 7. Further Reading and References
Editor's note: This section is to be kept in a living document where
future references, links and/or updates to the existing references
will be reflected. That living document is likely to be an IETF-
owned Wiki: https://tinyurl.com/streaming-opcons-reading
7.1. Industry Terminology
* SVA Glossary: https://glossary.streamingvideoalliance.org/
* Datazoom Video Player Data Dictionary:
https://help.datazoom.io/hc/en-us/articles/360031323311
* Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/
en-us/articles/360046177191
7.2. Surveys and Tutorials
7.2.1. Encoding
The following papers describe how video is encoded, different video
encoding standards and tradeoffs in selecting encoding parameters.
* Overview of the Versatile Video Coding (VVC) Standard and its
Applications (https://ieeexplore.ieee.org/document/9503377)
* Video Compression - From Concepts to the H.264/AVC Standard
(https://ieeexplore.ieee.org/document/1369695)
* Developments in International Video Coding Standardization After
AVC, With an Overview of Versatile Video Coding (VVC)
(https://ieeexplore.ieee.org/document/9328514)
* A Technical Overview of AV1 (https://ieeexplore.ieee.org/
document/9363937)
* CTU Depth Decision Algorithms for HEVC: A Survey
(https://arxiv.org/abs/2104.08328)
7.2.2. Packaging
The following papers summarize the methods for selecting packaging
configurations such as the resolution-bitrate pairs, segment
durations, use of constant vs. variable-duration segments, etc.
* Deep Reinforced Bitrate Ladders for Adaptive Video Streaming
(https://dl.acm.org/doi/10.1145/3458306.3458873)
* Comparing Fixed and Variable Segment Durations for Adaptive Video
Streaming: a Holistic Analysis (https://dl.acm.org/
doi/10.1145/3339825.3391858)
7.2.3. Content Delivery
The following links describe some of the issues and solutions
regarding the interconnecting of the content delivery networks.
* Open Caching: Open standards for Caching in ISP Networks:
https://www.streamingvideoalliance.org/working-group/open-caching/
* Netflix Open Connect: https://openconnect.netflix.com
7.2.4. ABR Algorithms
The two surveys describe and compare different rate-adaptation
algorithms in terms of different metrics like achieved bitrate/
quality, stall rate/duration, bitrate switching frequency, fairness,
network utilization, etc.
* A Survey on Bitrate Adaptation Schemes for Streaming Media Over
HTTP (https://ieeexplore.ieee.org/document/8424813)
* A Survey of Rate Adaptation Techniques for Dynamic Adaptive
Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970)
* Low-Latency Live Streaming: The following papers describe the
peculiarities of adaptive streaming in low-latency live streaming
scenarios.
* Catching the Moment with LoL+ in Twitch-like Low-latency Live
Streaming Platforms (https://ieeexplore.ieee.org/document/9429986)
* Data-driven Bandwidth Prediction Models and Automated Model
Selection for Low Latency (https://ieeexplore.ieee.org/
document/9154522)
* Performance Analysis of ACTE: A Bandwidth Prediction Method for
Low-latency Chunked Streaming (https://dl.acm.org/
doi/10.1145/3387921)
* Online Learning for Low-latency Adaptive Streaming
(https://dl.acm.org/doi/10.1145/3339825.3397042)
* Tightrope Walking in Low-latency Live Streaming: Optimal Joint
Adaptation of Video Rate and Playback Speed (https://dl.acm.org/
doi/10.1145/3458305.3463382)
* Content-aware Playback Speed Control for Low-latency Live
Streaming of Sports (https://dl.acm.org/
doi/10.1145/3458305.3478437)
7.2.5. Server/Client/Network Collaboration
The following papers explain the benefits of server and network
assistance in client-driven streaming systems. There is also a good
reference about how congestion affects video quality and how rate
control works in streaming applications.
* Manus Manum Lavat: Media Clients and Servers Cooperating with
Common Media Client/Server Data (https://dl.acm.org/
doi/10.1145/3472305.3472886)
* Common media client data (CMCD): initial findings
(https://dl.acm.org/doi/10.1145/3458306.3461444)
* SDNDASH: Improving QoE of HTTP Adaptive Streaming Using Software
Defined Networking (https://dl.acm.org/
doi/10.1145/2964284.2964332)
* Caching in HTTP Adaptive Streaming: Friend or Foe?
(https://dl.acm.org/doi/10.1145/2578260.2578270)
* A Survey on Multi-Access Edge Computing Applied to Video
Streaming: Some Research Issues and Challenges
(https://ieeexplore.ieee.org/document/9374553)
* The Ultimate Guide to Internet Congestion Control
(https://www.compiralabs.com/ultimate-guide-congestion-control)
7.2.6. QoE Metrics
The following papers describe various QoE metrics one can use in
streaming applications.
* QoE Management of Multimedia Streaming Services in Future
Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/
document/8930519)
* A Survey on Quality of Experience of HTTP Adaptive Streaming
(https://ieeexplore.ieee.org/document/6913491)
* QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open
Challenges (https://ieeexplore.ieee.org/document/8666971)
7.2.7. Point Clouds and Immersive Media
The following papers explain the latest developments in the immersive
media domain (for video and audio) and the developing standards for
such media.
* A Survey on Adaptive 360o Video Streaming: Solutions, Challenges
and Opportunities (https://ieeexplore.ieee.org/document/9133103)
* MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/
document/9374648)
* Emerging MPEG Standards for Point Cloud Compression
(https://ieeexplore.ieee.org/document/8571288)
* Compression of Sparse and Dense Dynamic Point Clouds--Methods and
Standards (https://ieeexplore.ieee.org/document/9457097)
* MPEG Standards for Compressed Representation of Immersive Audio
(https://ieeexplore.ieee.org/document/9444109)
* An Overview of Omnidirectional MediA Format (OMAF)
(https://ieeexplore.ieee.org/document/9380215)
* From Capturing to Rendering: Volumetric Media Delivery with Six
Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522)
7.3. Open-Source Tools
* 5G-MA: https://www.5g-mag.com/reference-tools
* dash.js: http://reference.dashif.org/dash.js/latest/samples/
* DASH-IF Conformance: https://conformance.dashif.org
* ExoPlayer: https://github.com/google/ExoPlayer
* FFmpeg: https://www.ffmpeg.org/
* GPAC: https://gpac.wp.imt.fr/
* hls.js: https://github.com/video-dev/hls.js
* OBS Studio: https://obsproject.com/
* Shaka Player: https://github.com/google/shaka-player
* Shaka Packager: https://github.com/google/shaka-packager
* Traffic Control CDN: https://trafficcontrol.incubator.apache.org
* VideoLAN: https://www.videolan.org/projects/
* video.js: https://github.com/videojs/video.js
7.4. Technical Events
* ACM Mile High Video (MHV): https://mile-high.video/
* ACM Multimedia Systems (MMSys): https://acmmmsys.org
* ACM Multimedia (MM): https://acmmm.org
* ACM NOSSDAV: https://www.nossdav.org/
* ACM Packet Video: https://packet.video/
* Demuxed and meetups: https://demuxed.com/ and https://demuxed.com/
events/
* DVB World: https://www.dvbworld.org
* EBU BroadThinking: https://tech.ebu.ch/events/broadthinking2021
* IBC Conference: https://show.ibc.org/conference/ibc-conference
* IEEE Int. Conf. on Multimedia and Expo (ICME)
* Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws
* Live Video Stack: https://sh2021.livevideostack.com
* Picture Coding Symp. (PCS)
* SCTE Expo: https://expo.scte.org/
7.5. List of Organizations Working on Streaming Media
* 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/
sa4-codec
* 5G-MAG: https://www.5g-mag.com/
* AOM: http://aomedia.org/
* ATSC: https://www.atsc.org/
* CTA WAVE: https://cta.tech/Resources/Standards/WAVE-Project
* DASH Industry Forum: https://dashif.org/
* DVB: https://dvb.org/
* HbbTV: https://www.hbbtv.org/
* HESP Alliance: https://www.hespalliance.org/
* IAB: https://www.iab.com/
* MPEG: https://www.mpegstandards.org/
* Streaming Video Alliance: https://www.streamingvideoalliance.org/
* SCTE: https://www.scte.org/
* SMPTE: https://www.smpte.org/
* SRT Alliance: https://www.srtalliance.org/
* Video Services Forum: https://vsf.tv/
* VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx
* W3C: https://www.w3.org/
7.6. Topics to Keep an Eye on
7.6.1. 5G and Media
5G new radio and systems technologies provide new functionalities for
video distribution. 5G targets not only smartphones, but also new
devices such as augmented reality glasses or automotive receivers.
Higher bandwidth, lower latencies, edge and cloud computing
functionalities, service-based architectures, low power consumption,
broadcast/multicast functionalities and other network functions come
hand in hand with new media formats and processing capabilities
promising better and more consistent quality for traditional video
streaming services as well as enabling new experiences such as
immersive media and augmented realities.
* 5G Multimedia Standardization (https://www.riverpublishers.com/
journal_read_html_article.php?j=JICTS/6/1/8)
7.6.2. Ad Insertion
Ads can be inserted at different stages in the streaming workflow, on
the server side or client side. The DASH-IF guidelines detail
server-side ad-insertion with period replacements based on
manipulating the manifest. HLS interstitials provide a similar
approach. The idea is that the manifest can be changed and point to
a sub-playlist of segments, possibly located on a different location.
This approach results in efficient resource usage in the network, as
duplicate caching is avoided, but some intelligence at the player is
needed to deal with content transitions (e.g., codec changes,
timeline gaps, etc.). Player support for such content is gradually
maturing. Other important technologies for ad insertion include
signalling of ads and breaks that is still typically based on SCTE-35
for HLS and SCTE-214 for DASH. Such signals provide useful
information for scheduling the ads and contacting ad servers. The
usage of SCTE-35 for ad insertion is popular in the broadcast
industry, while the exact usage in the OTT space is still being
discussed in SCTE. Another important technology is identification of
ads, such as based on ad-id or other commercial entities that provide
such services. The identification of the ad in a manifest or stream
is usually standardized by SMPTE. Other key technologies for ad
insertion include tracking of viewer impressions, usually based on
Video Ad Serving Template (VAST) defined by IAB.
* DASH-IF Ad Insertion Guidelines: https://dashif.org/docs/CR-Ad-
Insertion-r7.pdf
* SCTE-214-1: https://www.scte.org/standards-development/library/
standards-catalog/ansiscte-214-1-2016/
* RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital
Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/
document/7291518
* IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio-
video/tech-lab-digital-video-suite/
7.6.3. Contribution and Ingest
There are different contribution and ingest specifications dealing
with different use cases. A common case is contribution that
previously happened over satellite to a broadcast or streaming
headend. RIST and SRT are examples of such contribution protocols.
Within a streaming headend the encoder and packager/CDN may have an
ingest/contribution interface as well. This is specified by the
DASH-IF Ingest.
* DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest
* RIST: https://www.rist.tv/
* SRT: https://github.com/Haivision/srt
7.6.4. Synchronized Encoding and Packaging
Practical streaming headends need redundant encoders and packagers to
operate without glitches and blackouts. The redundant operation
requires synchronization between two or more encoders and also
between two or more packagers that possibly handle different inputs
and outputs, generating compatible inter-changeable output
representations. This problem is important for anyone developing a
streaming headend at scale, and the synchronization problem is
currently under discussion in the wider community. Follow the
developments at: https://sites.google.com/view/encodersyncworkshop/
home
7.6.5. WebRTC-Based Streaming
WebRTC is increasingly being used for streaming of time-sensitive
content such as live sporting events. Innovations in cloud computing
allow implementers to efficiently scale delivery of content using
WebRTC. Support for WebRTC communication is available on all modern
web browsers and is available on native clients for all major
platforms.
* DASH-IF WebRTC Discussions: https://dashif.org/webRTC/
* Overview of WebRTC: https://webrtc.org/
8. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
8. Security Considerations 9. Security Considerations
This document introduces no new security issues. This document introduces no new security issues.
9. Acknowledgments 10. Acknowledgments
Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen, Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen,
Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock,
Mike English, Roni Even, and Will Law for very helpful suggestions, Mike English, Roni Even, and Will Law for very helpful suggestions,
reviews and comments. reviews and comments.
(If we missed your name, please let us know!) (If we missed your name, please let us know!)
10. Informative References 11. 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.,
<https://www.betterads.org/>.
[CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion [CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion
Defense in Depth", July 2019, Defense in Depth", July 2019,
<https://datatracker.ietf.org/meeting/105/materials/ <https://datatracker.ietf.org/meeting/105/materials/
slides-105-tsvarea-congestion-defense-in-depth-00>. slides-105-tsvarea-congestion-defense-in-depth-00>.
[CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked- [CMAF-CTE] Law, W., "Ultra-Low-Latency Streaming Using Chunked-
Encoded and Chunked Transferred CMAF", October 2018, Encoded and Chunked Transferred CMAF", October 2018,
<https://www.akamai.com/us/en/multimedia/documents/white- <https://www.akamai.com/us/en/multimedia/documents/white-
paper/low-latency-streaming-cmaf-whitepaper.pdf>. paper/low-latency-streaming-cmaf-whitepaper.pdf>.
[CODASPY17] [CODASPY17]
Reed, A. and M. Kranch, "Identifying HTTPS-Protected Reed, A. and M. Kranch, "Identifying HTTPS-Protected
Netflix Videos in Real-Time", ACM CODASPY , March 2017, Netflix Videos in Real-Time", ACM CODASPY , March 2017,
<https://dl.acm.org/doi/10.1145/3029806.3029821>. <https://dl.acm.org/doi/10.1145/3029806.3029821>.
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay",
Communications of the ACM, Volume 55, Issue 7, pp. 42-50 ,
July 2012.
[COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based [COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based
Congestion Control for the Internet", USENIX NSDI , April Congestion Control for the Internet", USENIX NSDI , April
2018, <https://web.mit.edu/copa/>. 2018, <https://web.mit.edu/copa/>.
[CTA-2066] Consumer Technology Association, "Streaming Quality of [CTA-2066] Consumer Technology Association, "Streaming Quality of
Experience Events, Properties and Metrics", March 2020, Experience Events, Properties and Metrics", March 2020,
<https://shop.cta.tech/products/streaming-quality-of- <https://shop.cta.tech/products/streaming-quality-of-
experience-events-properties-and-metrics>. experience-events-properties-and-metrics>.
[CTA-5004] CTA, ., "Common Media Client Data (CMCD)", September 2020, [CTA-5004] CTA, ., "Common Media Client Data (CMCD)", September 2020,
skipping to change at page 29, line 51 skipping to change at page 41, line 41
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., and V. Jacobson,
"BBR Congestion Control", Work in Progress, Internet- "BBR Congestion Control", Work in Progress, Internet-
Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3 Draft, draft-cardwell-iccrg-bbr-congestion-control-00, 3
July 2017, <https://www.ietf.org/archive/id/draft- July 2017, <https://datatracker.ietf.org/doc/html/draft-
cardwell-iccrg-bbr-congestion-control-00.txt>. cardwell-iccrg-bbr-congestion-control-00>.
[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-09,
27 April 2021, <https://www.ietf.org/archive/id/draft- 27 April 2021, <https://datatracker.ietf.org/doc/html/
pantos-hls-rfc8216bis-09.txt>. draft-pantos-hls-rfc8216bis-09>.
[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-02, 16 February 2021, Draft, draft-ietf-quic-datagram-04, 8 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic-datagram- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
02.txt>. datagram-04>.
[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://www.ietf.org/archive/id/draft-ietf-quic-http- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
34.txt>. http-34>.
[I-D.ietf-quic-manageability] [I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-11, 21 April 2021, draft-ietf-quic-manageability-13, 2 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-11.txt>. manageability-13>.
[I-D.ietf-quic-qlog-h3-events]
Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK
event definitions for qlog", Work in Progress, Internet-
Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
qlog-h3-events-00>.
[I-D.ietf-quic-qlog-main-schema]
Marx, R., Niccolini, L., and M. Seemann, "Main logging
schema for qlog", Work in Progress, Internet-Draft, draft-
ietf-quic-qlog-main-schema-00, 10 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
qlog-main-schema-00>.
[I-D.ietf-quic-qlog-quic-events]
Marx, R., Niccolini, L., and M. Seemann, "QUIC event
definitions for qlog", Work in Progress, Internet-Draft,
draft-ietf-quic-qlog-quic-events-00, 10 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
qlog-quic-events-00>.
[IAB-ADS] "IAB", n.d., <https://www.iab.com/>.
[IABcovid] Arkko, J., Farrel, S., Kühlewind, M., and C. Perkins, [IABcovid] Arkko, J., Farrel, S., Kühlewind, M., and C. Perkins,
"Report from the IAB COVID-19 Network Impacts Workshop "Report from the IAB COVID-19 Network Impacts Workshop
2020", November 2020, <https://datatracker.ietf.org/doc/ 2020", November 2020, <https://datatracker.ietf.org/doc/
draft-iab-covid19-workshop/>. draft-iab-covid19-workshop/>.
[Jacobson-Karels] [Jacobson-Karels]
Jacobson, V. and M. Karels, "Congestion Avoidance and Jacobson, V. and M. Karels, "Congestion Avoidance and
Control", November 1988, Control", November 1988,
<https://ee.lbl.gov/papers/congavoid.pdf>. <https://ee.lbl.gov/papers/congavoid.pdf>.
skipping to change at page 32, line 26 skipping to change at page 44, line 42
Selected Topics in Circuits and Systems , March 2019, Selected Topics in Circuits and Systems , March 2019,
<https://ieeexplore.ieee.org/document/8571288>. <https://ieeexplore.ieee.org/document/8571288>.
[Port443] "Service Name and Transport Protocol Port Number [Port443] "Service Name and Transport Protocol Port Number
Registry", April 2021, <https://www.iana.org/assignments/ Registry", April 2021, <https://www.iana.org/assignments/
service-names-port-numbers/service-names-port- service-names-port-numbers/service-names-port-
numbers.txt>. numbers.txt>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001, Retransmit, and Fast Recovery Algorithms", RFC 2001,
DOI 10.17487/RFC2001, January 1997, DOI 10.17487/RFC2001, January 1997,
<https://www.rfc-editor.org/info/rfc2001>. <https://www.rfc-editor.org/rfc/rfc2001>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001, DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>. <https://www.rfc-editor.org/rfc/rfc3135>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, Partial Reliability Extension", RFC 3758,
DOI 10.17487/RFC3758, May 2004, DOI 10.17487/RFC3758, May 2004,
<https://www.rfc-editor.org/info/rfc3758>. <https://www.rfc-editor.org/rfc/rfc3758>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/rfc/rfc4733>.
[RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop [RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop
on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
RFC 5594, DOI 10.17487/RFC5594, July 2009, RFC 5594, DOI 10.17487/RFC5594, July 2009,
<https://www.rfc-editor.org/info/rfc5594>. <https://www.rfc-editor.org/rfc/rfc5594>.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April
2010, <https://www.rfc-editor.org/info/rfc5762>. 2010, <https://www.rfc-editor.org/rfc/rfc5762>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<https://www.rfc-editor.org/info/rfc6190>. <https://www.rfc-editor.org/rfc/rfc6190>.
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
NewReno Modification to TCP's Fast Recovery Algorithm", NewReno Modification to TCP's Fast Recovery Algorithm",
RFC 6582, DOI 10.17487/RFC6582, April 2012, RFC 6582, DOI 10.17487/RFC6582, April 2012,
<https://www.rfc-editor.org/info/rfc6582>. <https://www.rfc-editor.org/rfc/rfc6582>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/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/info/rfc6843>. <https://www.rfc-editor.org/rfc/rfc6843>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <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/info/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/info/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
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<https://www.rfc-editor.org/info/rfc7656>. <https://www.rfc-editor.org/rfc/rfc7656>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661, TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015, DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/info/rfc7661>. <https://www.rfc-editor.org/rfc/rfc7661>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>. <https://www.rfc-editor.org/rfc/rfc8083>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/rfc/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017, RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/info/rfc8216>. <https://www.rfc-editor.org/rfc/rfc8216>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018, RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/info/rfc8312>. <https://www.rfc-editor.org/rfc/rfc8312>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>. June 2019, <https://www.rfc-editor.org/rfc/rfc8622>.
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
"Double Encryption Procedures for the Secure Real-Time "Double Encryption Procedures for the Secure Real-Time
Transport Protocol (SRTP)", RFC 8723, Transport Protocol (SRTP)", RFC 8723,
DOI 10.17487/RFC8723, April 2020, DOI 10.17487/RFC8723, April 2020,
<https://www.rfc-editor.org/info/rfc8723>. <https://www.rfc-editor.org/rfc/rfc8723>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/rfc/rfc8825>.
[RFC8999] Thomson, M., "Version-Independent Properties of QUIC", [RFC8999] Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021, RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>. <https://www.rfc-editor.org/rfc/rfc8999>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>. May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[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>.
 End of changes. 75 change blocks. 
128 lines changed or deleted 727 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/