< draft-ietf-mops-streaming-opcons-05.txt   draft-ietf-mops-streaming-opcons-06.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: 10 December 2021 Networked Media Expires: 13 January 2022 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
8 June 2021 12 July 2021
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-05 draft-ietf-mops-streaming-opcons-06
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 10 December 2021. This Internet-Draft will expire on 13 January 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 . . . . . . . 4
1.1.2. Template for Contributions . . . . . . . . . . . . . 5 1.1.2. History of Public Discussion . . . . . . . . . . . . 5
1.1.3. History of Public Discussion . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 7 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 7
2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 8 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 7
2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 8 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8
2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 9
2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 9 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 9
2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 10 2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 10
3. Latency Considerations . . . . . . . . . . . . . . . . . . . 12 3. Latency Considerations . . . . . . . . . . . . . . . . . . . 11
3.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 12 3.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 12
3.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 13 3.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 12
3.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 14 3.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 13
3.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Adaptive Encoding, Adaptive Delivery, and Measurement 4. Adaptive Encoding, Adaptive Delivery, and Measurement
Collection . . . . . . . . . . . . . . . . . . . . . . . 15 Collection . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 16 4.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 15
4.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 16 4.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 15
4.3.1. Idle Time between Segments . . . . . . . . . . . . . 17 4.4. Bitrate Detection Challenges . . . . . . . . . . . . . . 16
4.3.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 17 4.4.1. Idle Time between Segments . . . . . . . . . . . . . 16
4.4. Measurement Collection . . . . . . . . . . . . . . . . . 18 4.4.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 17
4.4.1. CTA-2066: Streaming Quality of Experience Events, 4.4.3. Wide and Rapid Variation in Path Capacity . . . . . . 17
4.5. Measurement Collection . . . . . . . . . . . . . . . . . 18
4.5.1. CTA-2066: Streaming Quality of Experience Events,
Properties and Metrics . . . . . . . . . . . . . . . 18 Properties and Metrics . . . . . . . . . . . . . . . 18
4.4.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 19 4.5.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 19
4.5. Unreliable Transport . . . . . . . . . . . . . . . . . . 19 4.6. Unreliable Transport . . . . . . . . . . . . . . . . . . 19
5. Evolution of Transport Protocols and Transport Protocol 5. Evolution of Transport Protocols and Transport Protocol
Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 20 Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 20 5.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 20
5.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 21 5.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 21
5.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 22 5.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 22
6. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 24 6. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 24
6.1. General Considerations for Media Encryption . . . . . . . 25 6.1. General Considerations for Media Encryption . . . . . . . 25
6.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 26 6.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 26
6.3. Considerations for "End-to-End" Media Encryption . . . . 27 6.3. Considerations for "End-to-End" Media Encryption . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 4, line 11 skipping to change at page 4, line 11
bandwidth availability but also real-time constraints. That is, bandwidth availability but also real-time constraints. That is,
the client cannot fetch media that is not available from a server the client cannot fetch media that is not available from a server
yet. yet.
In many contexts, video traffic can be handled transparently as In many contexts, video traffic can be handled transparently as
generic application-level traffic. However, as the volume of video generic application-level traffic. However, as the volume of video
traffic continues to grow, it's becoming increasingly important to traffic continues to grow, it's becoming increasingly important to
consider the effects of network design decisions on application-level consider the effects of network design decisions on application-level
performance, with considerations for the impact on video delivery. performance, with considerations for the impact on video delivery.
This document aims to provide a taxonomy of networking issues as they This document examines networking issues as they relate to quality of
relate to quality of experience in internet video delivery. The experience in internet video delivery. The focus is on capturing
focus is on capturing characteristics of video delivery that have characteristics of video delivery that have surprised network
surprised network designers or transport experts without specific designers or transport experts without specific video expertise,
video expertise, since these highlight key differences between common since these highlight key differences between common assumptions in
assumptions in existing networking documents and observations of existing networking documents and observations of video delivery
video delivery issues in practice. issues in practice.
Making specific recommendations for mitigating these issues is out of Making specific recommendations on operational practices aimed at
scope, though some existing mitigations are mentioned in passing. mitigating these issues is out of scope, though some existing
The intent is to provide a point of reference for future solution mitigations are mentioned in passing. The intent is to provide a
proposals to use in describing how new technologies address or avoid point of reference for future solution proposals to use in describing
these existing observed problems. how new technologies address or avoid these existing observed
problems.
1.1. Notes for Contributors and Reviewers 1.1. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section and its subsections Note to RFC Editor: Please remove this section and its subsections
before publication. before publication.
This section is to provide references to make it easier to review the This section is to provide references to make it easier to review the
development and discussion on the draft so far. development and discussion on the draft so far.
1.1.1. Venues for Contribution and Discussion 1.1.1. Venues for Contribution and Discussion
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Substantial discussion of this document should take place on the MOPS Substantial discussion of this document should take place on the MOPS
working group mailing list (mops@ietf.org). working group mailing list (mops@ietf.org).
* Join: https://www.ietf.org/mailman/listinfo/mops * Join: https://www.ietf.org/mailman/listinfo/mops
(https://www.ietf.org/mailman/listinfo/mops) (https://www.ietf.org/mailman/listinfo/mops)
* Search: https://mailarchive.ietf.org/arch/browse/mops/ * Search: https://mailarchive.ietf.org/arch/browse/mops/
(https://mailarchive.ietf.org/arch/browse/mops/) (https://mailarchive.ietf.org/arch/browse/mops/)
1.1.2. Template for Contributions 1.1.2. History of Public Discussion
Contributions are solicited regarding issues and considerations that
have an impact on media streaming operations.
Please note that contributions may be merged and substantially
edited, and as a reminder, please carefully consider the Note Well
before contributing: https://datatracker.ietf.org/submit/note-well/
(https://datatracker.ietf.org/submit/note-well/)
Contributions can be emailed to mops@ietf.org, submitted as issues to
the issue tracker of the repository in Section 1.1.1, or emailed to
the document authors at draft-ietf-mops-streaming-opcons@ietf.org.
Contributors describing an issue not yet addressed in the draft are
requested to provide the following information, where applicable:
* a suggested title or name for the issue
* a long-term pointer to the best reference describing the issue
* a short description of the nature of the issue and its impact on
media quality of service, including:
- where in the network this issue has root causes
- who can detect this issue when it occurs
* an overview of the issue's known prevalence in practice. pointers
to write-ups of high-profile incidents are a plus.
* a list of known mitigation techniques, with (for each known
mitigation):
- a name for the mitigation technique
- a long-term pointer to the best reference describing it
- a short description of the technique:
o what it does
o where in the network it operates
o an overview of the tradeoffs involved-how and why it's
helpful, what it costs.
- supplemental information about the technique's deployment
prevalence and status
1.1.3. History of Public Discussion
Presentations: Presentations:
* IETF 105 BOF: * IETF 105 BOF:
https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s
(https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s) (https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s)
* IETF 106 meeting: * IETF 106 meeting:
skipping to change at page 7, line 6 skipping to change at page 6, line 6
encoding parameters, scene complexity and amount of motion. encoding parameters, scene complexity and amount of motion.
Generally speaking, as the resolution, frame rate, color depth, scene Generally speaking, as the resolution, frame rate, color depth, scene
complexity and amount of motion increase, the encoding bitrate complexity and amount of motion increase, the encoding bitrate
increases. As newer codecs with better compression tools are used, increases. As newer codecs with better compression tools are used,
the encoding bitrate decreases. Similarly, a multi-pass encoding the encoding bitrate decreases. Similarly, a multi-pass encoding
generally produces better quality output compared to single-pass generally produces better quality output compared to single-pass
encoding at the same bitrate, or delivers the same quality at a lower encoding at the same bitrate, or delivers the same quality at a lower
bitrate. bitrate.
Here are a few common resolutions used for video content, with Here are a few common resolutions used for video content, with
typical ranges of bitrate for the two most popular video codecs typical ranges of bitrates for the two most popular video codecs
[Encodings]. [Encodings].
+============+================+============+============+ +============+================+============+============+
| Name | Width x Height | AVC | HEVC | | Name | Width x Height | H.264 | H.265 |
+============+================+============+============+ +============+================+============+============+
| DVD | 720 x 480 | 1.0 Mbps | 0.5 Mbps | | DVD | 720 x 480 | 1.0 Mbps | 0.5 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps | | 720p (1K) | 1280 x 720 | 3-4.5 Mbps | 2-4 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps | | 1080p (2K) | 1920 x 1080 | 6-8 Mbps | 4.5-7 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
| 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps | | 2160p (4k) | 3840 x 2160 | N/A | 10-20 Mbps |
+------------+----------------+------------+------------+ +------------+----------------+------------+------------+
skipping to change at page 9, line 19 skipping to change at page 8, line 19
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.4),
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.5, Section 2.6).
And as with other parts of the ecosystem, new technology brings new
challenges. For example, with the emergence of ultra-low-latency
streaming, responses have to start streaming to the end user while
still being transmitted to the cache, and while the cache does not
yet know the size of the object. Some of the popular caching systems
were designed around cache footprint and had deeply ingrained
assumptions about knowing the size of objects that are being stored,
so the change in design requirements in long-established systems
caused some errors in production. Incidents occurred where a
transmission error in the connection from the upstream source to the
cache could result in the cache holding a truncated segment and
transmitting it to the end user's device. In this case, players
rendering the stream often had the video freeze until the player was
reset. In some cases the truncated object was even cached that way
and served later to other players as well, causing continued stalls
at the same spot in the video for all players playing the segment
delivered from that cache node.
2.4. Predictable Usage Profiles 2.4. 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.
TBD: insert charts showing historical relative data usage patterns
with error bars by time of day in consumer networks?
TBD: Cross-ref vs. video quality by time of day in practice for some
case study? Not sure if there's a good way to capture a generalized
insight here, but it seems worth making the point that demand
projections can be used to help with e.g. power consumption with
routing architectures that provide for modular scalability.
2.5. Unpredictable Usage Profiles 2.5. 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
skipping to change at page 16, line 44 skipping to change at page 16, line 5
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
This kind of bandwidth-measurement system can experience trouble in This kind of bandwidth-measurement system can experience trouble in
several ways that can be affected by networking design choices. several ways that are affected by networking issues. Because
Because adaptive application-level response strategies are typically adaptive application-level response strategies are often using rates
using application-level protocols, these mechanisms are affected by as observed by the application layer, there are sometimes inscrutable
transport-level protocol behaviors, and the application-level transport-level protocol behaviors that can produce surprising
feedback loop is interacting with a transport-level feedback loop, as measurement values when the application-level feedback loop is
described in Section 4.3.1 and Section 4.3.2. interacting with a transport-level feedback loop.
4.3.1. Idle Time between Segments A few specific examples of surprising phenomena that affect bitrate
detection measurements are described in the following subsections.
As these examples will demonstrate, it's common to encounter cases
that can deliver application level measurements that are too low, too
high, and (possibly) correct but varying more quickly than a lab-
tested selection algorithm might expect.
These effects and others that cause transport behavior to diverge
from lab modeling can sometimes have a significant impact on ABR
bitrate selection and on user quality of experience, especially where
players use naive measurement strategies and selection algorithms
that don't account for the likelihood of bandwidth measurements that
diverge from the true path capacity.
4.4.1. Idle Time between Segments
When the bitrate selection is chosen substantially below the When the bitrate selection is chosen substantially below the
available capacity of the network path, the response to a segment available capacity of the network path, the response to a segment
request will typically complete in much less absolute time than the request will typically complete in much less absolute time than the
duration of the requested segment, leaving significant idle time duration of the requested segment, leaving significant idle time
between segment downloads. This can have a few surprising between segment downloads. This can have a few surprising
consequences: consequences:
* TCP slow-start when restarting after idle requires multiple RTTs * TCP slow-start when restarting after idle requires multiple RTTs
to re-establish a throughput at the network's available capacity. to re-establish a throughput at the network's available capacity.
When the active transmission time for segments is substantially When the active transmission time for segments is substantially
shorter than the time between segments leaving an idle gap between shorter than the time between segments, leaving an idle gap
segments that triggers a restart of TCP slow-start, the estimate between segments that triggers a restart of TCP slow-start, the
of the successful download speed coming from the application- estimate of the successful download speed coming from the
visible receive rate on the socket can thus end up much lower than application-visible receive rate on the socket can thus end up
the actual available network capacity, preventing a shift to the much lower than the actual available network capacity. This in
most appropriate bitrate. [RFC7661] provides some mitigations for turn can prevent a shift to the most appropriate bitrate.
this effect at the TCP transport layer, for senders who anticipate [RFC7661] provides some mitigations for this effect at the TCP
a high incidence of this problem. transport layer, for senders who anticipate a high incidence of
this problem.
* Mobile flow-bandwidth spectrum and timing mapping can be impacted * Mobile flow-bandwidth spectrum and timing mapping can be impacted
by idle time in some networks. The carrier capacity assigned to a by idle time in some networks. The carrier capacity assigned to a
link can vary with activity. Depending on the idle time link can vary with activity. Depending on the idle time
characteristics, this can result in a lower available bitrate than characteristics, this can result in a lower available bitrate than
would be achievable with a steadier transmission in the same would be achievable with a steadier transmission in the same
network. network.
Some receive-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. Another way to mitigate this effect is by try to avoid this effect.
the help of two simultaneous TCP connections is explained in
[MMSys11] for Microsoft Smooth Streaming. In some cases, the system-
level TCP slow-start restart can be disabled [OReilly-HPBN].
4.3.2. Head-of-Line Blocking Another way to mitigate this effect is by the help of two
simultaneous TCP connections, as explained in [MMSys11] for Microsoft
Smooth Streaming. In some cases, the system-level TCP slow-start
restart can also be disabled, for example as described in
[OReilly-HPBN].
4.4.2. Head-of-Line Blocking
In the event of a lost packet on a TCP connection with SACK support In the event of a lost packet on a TCP connection with SACK support
(a common case for segmented delivery in practice), loss of a packet (a common case for segmented delivery in practice), loss of a packet
can provide a confusing bandwidth signal to the receiving can provide a confusing bandwidth signal to the receiving
application. Because of the sliding window in TCP, many packets may application. Because of the sliding window in TCP, many packets may
be accepted by the receiver without being available to the be accepted by the receiver without being available to the
application until the missing packet arrives. Upon arrival of the application until the missing packet arrives. Upon arrival of the
one missing packet after retransmit, the receiver will suddenly get one missing packet after retransmit, the receiver will suddenly get
access to a lot of data at the same time. access to a lot of data at the same time.
To a receiver measuring bytes received per unit time at the To a receiver measuring bytes received per unit time at the
application layer, and interpreting it as an estimate of the application layer, and interpreting it as an estimate of the
available network bandwidth, this appears as a high jitter in the available network bandwidth, this appears as a high jitter in the
goodput measurement. goodput measurement. This can appear as a stall of some time,
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
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. Measurement Collection 4.4.3. Wide and Rapid Variation in Path Capacity
As many end devices have moved to wireless connectivity for the final
hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
emerged from radio interference and signal strength effects.
Each of these technologies can experience sudden changes in capacity
as the end user device moves from place to place and encounters new
sources of interference. Microwave ovens, for example, can cause a
throughput degradation of more than a factor of 2 while active
[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.
These swings in actual transport capacity can result in user
experience issues that can be exacerbated by insufficiently
responsive ABR algorithms.
4.5. 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.4.1. CTA-2066: Streaming Quality of Experience Events, Properties and 4.5.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.4.2. CTA-5004: Common Media Client Data (CMCD) 4.5.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.5. Unreliable Transport 4.6. 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 20, line 7 skipping to change at page 20, line 7
change encoder settings (as in [RFC5762]), to using fewer enhancement change encoder settings (as in [RFC5762]), to using fewer enhancement
layers (as in [RFC6190]), to using proprietary methods to detect layers (as in [RFC6190]), to using proprietary methods to detect
"quality of experience" issues and turn off video in order to allow "quality of experience" issues and turn off video in order to allow
less bandwidth-intensive media such as audio to be delivered. less bandwidth-intensive media such as audio to be delivered.
More details about congestion avoidance strategies used with More details about congestion avoidance strategies used with
unreliable transport protocols are included in Section 5.1. unreliable transport protocols are included in Section 5.1.
5. Evolution of Transport Protocols and Transport Protocol Behaviors 5. Evolution of Transport Protocols and Transport Protocol Behaviors
*Note to Reviewers*
This section includes some material on UDP and TCP that may be
tutorial for some readers. We can decide how to explain that, if the
working group feels that this tutorial material is worth keeping.
Spencer thought it was worth including, because it provides a
contrast to the material on QUIC, which is significantly less
tutorial, unless the reader participated in the QUIC working group.
Because networking resources are shared between users, a good place Because networking resources are shared between users, a good place
to start our discussion is how contention between users, and to start our discussion is how contention between users, and
mechanisms to resolve that contention in ways that are "fair" between mechanisms to resolve that contention in ways that are "fair" between
users, impact streaming media users. These topics are closely tied users, impact streaming media users. These topics are closely tied
to transport protocol behaviors. to transport protocol behaviors.
As noted in Section 4, Adaptive Bitrate response strategies such as As noted in Section 4, Adaptive Bitrate response strategies such as
HLS [RFC8216] or DASH [MPEG-DASH] are attempting to respond to HLS [RFC8216] or DASH [MPEG-DASH] are attempting to respond to
changing path characteristics, and underlying transport protocols are changing path characteristics, and underlying transport protocols are
also attempting to respond to changing path characteristics. also attempting to respond to changing path characteristics.
skipping to change at page 23, line 17 skipping to change at page 23, line 4
standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which standardized mapping is for HTTP/3 [I-D.ietf-quic-http], which
describes how QUIC transport features are used for HTTP. The describes how QUIC transport features are used for HTTP. The
convention is for HTTP/3 to run over UDP port 443 [Port443] but this convention is for HTTP/3 to run over UDP port 443 [Port443] but this
is not a strict requirement. is not a strict requirement.
When HTTP/3 is encapsulated in QUIC, which is then encapsulated in When HTTP/3 is encapsulated in QUIC, which is then encapsulated in
UDP, streaming operators (and network operators) might see UDP UDP, streaming operators (and network operators) might see UDP
traffic patterns that are similar to HTTP(S) over TCP. Since earlier traffic patterns that are similar to HTTP(S) over TCP. Since earlier
versions of HTTP(S) rely on TCP, UDP ports may be blocked for any versions of HTTP(S) rely on TCP, UDP ports may be blocked for any
port numbers that are not commonly used, such as UDP 53 for DNS. port numbers that are not commonly used, such as UDP 53 for DNS.
Even when UDP ports are not blocked and HTTP/3 can flow, streaming Even when UDP ports are not blocked and HTTP/3 can flow, streaming
operators (and network operators) may severely rate-limit this operators (and network operators) may severely rate-limit this
traffic because they do not expect to see legitimate high-bandwidth traffic because they do not expect to see legitimate high-bandwidth
traffic such as streaming media over the UDP ports that HTTP/3 is traffic such as streaming media over the UDP ports that HTTP/3 is
using. using.
As noted in Section 4.3.2, because TCP provides a reliable, in-order As noted in Section 4.4.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 35 skipping to change at page 28, line 32
7. IANA Considerations 7. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
8. Security Considerations 8. Security Considerations
This document introduces no new security issues. This document introduces no new security issues.
9. Acknowledgments 9. Acknowledgments
Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen,
Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock,
and Mike English for their very helpful reviews and comments. Mike English, Roni Even, and Will Law for very helpful suggestions,
reviews and comments.
(If we missed your name, please let us know!)
10. Informative References 10. 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>.
skipping to change at page 30, line 32 skipping to change at page 30, line 32
<https://www.ietf.org/archive/id/draft-ietf-quic-http- <https://www.ietf.org/archive/id/draft-ietf-quic-http-
34.txt>. 34.txt>.
[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-11, 21 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://www.ietf.org/archive/id/draft-ietf-quic-
manageability-11.txt>. manageability-11.txt>.
[IABcovid] Arkko, J., Farrel, S., Kuhlewind, 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>.
[Labovitz] Labovitz, C., "Network traffic insights in the time of [Labovitz] Labovitz, C., "Network traffic insights in the time of
skipping to change at page 31, line 8 skipping to change at page 31, line 8
[LabovitzDDoS] [LabovitzDDoS]
Takahashi, D., "Why the game industry is still vulnerable Takahashi, D., "Why the game industry is still vulnerable
to DDoS attacks", May 2018, to DDoS attacks", May 2018,
<https://venturebeat.com/2018/05/13/why-the-game-industry- <https://venturebeat.com/2018/05/13/why-the-game-industry-
is-still-vulnerable-to-distributed-denial-of-service- is-still-vulnerable-to-distributed-denial-of-service-
attacks/>. attacks/>.
[LL-DASH] DASH-IF, ., "Low-latency Modes for DASH", March 2020, [LL-DASH] DASH-IF, ., "Low-latency Modes for DASH", March 2020,
<https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>. <https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>.
[Micro] Taher, T.M., Misurac, M.J., LoCicero, J.L., and D.R. Ucci,
"Microwave Oven Signal Interference Mitigation For Wi-Fi
Communication Systems", 2008 5th IEEE Consumer
Communications and Networking Conference 5th IEEE, pp.
67-68 , 2008.
[Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video [Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video
Alliance", April 2020, Alliance", 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>.
[MMSP20] Durak, K. and . et al, "Evaluating the performance of [MMSP20] Durak, K. and . et al, "Evaluating the performance of
Apple's low-latency HLS", IEEE MMSP , September 2020, Apple's low-latency HLS", IEEE MMSP , September 2020,
<https://ieeexplore.ieee.org/document/9287117>. <https://ieeexplore.ieee.org/document/9287117>.
 End of changes. 33 change blocks. 
141 lines changed or deleted 143 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/