< draft-ietf-mops-streaming-opcons-03.txt   draft-ietf-mops-streaming-opcons-04.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: 5 May 2021 Networked Media Expires: 12 November 2021 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
1 November 2020 11 May 2021
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-03 draft-ietf-mops-streaming-opcons-04
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 delivery 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 May 2021. This Internet-Draft will expire on 12 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notes for Contributors and Reviewers . . . . . . . . . . 3 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 3
1.1.1. Venues for Contribution and Discussion . . . . . . . 3 1.1.1. Venues for Contribution and Discussion . . . . . . . 4
1.1.2. Template for Contributions . . . . . . . . . . . . . 3 1.1.2. Template for Contributions . . . . . . . . . . . . . 4
1.1.3. History of Public Discussion . . . . . . . . . . . . 4 1.1.3. History of Public Discussion . . . . . . . . . . . . 5
2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 5 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 5
2.1. Scaling Requirements for Media Delivery . . . . . . . . . 5 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 6 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 7
2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 7 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 8
2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8
2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 8 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 9
2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 9 2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 10
3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 10 3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 10 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 12
3.2.1. Idle Time between Segments . . . . . . . . . . . . . 11 3.2.1. Idle Time between Segments . . . . . . . . . . . . . 12
3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 11 3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 12
3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 11 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . 12 7. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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. What's more, this estimate projects the gross volume of 82% by 2022. What's more, this estimate projects the gross volume of
video traffic will more than double during this time, based on a video traffic will more than double during this time, based on a
compound annual growth rate continuing at 34% (from Appendix D of compound annual growth rate continuing at 34% (from Appendix D of
[CVNI]). [CVNI]).
A substantial part of this growth is due to increased use of
streaming video, although the amount of video traffic in real-time
communications (for example, online videoconferencing) has also grown
significantly. While both streaming video and videoconferencing have
real-time delivery and latency requirements, these requirements vary
from one application to another. For example, videoconferencing
demands an end-to-end (one-way) latency of a few hundreds of
milliseconds whereas live streaming can tolerate latencies of several
seconds.
This document specifically focuses on the streaming applications and
defines streaming as follows: Streaming is transmission of a
continuous media from a server to a client and its simultaneous
consumption by the client. Here, continous media refers to media and
associated streams such as video, audio, metadata, etc. In this
definition, the critical term is "simultaneous", as it is not
considered streaming if one downloads a video file and plays it after
the download is completed, which would be called download-and-play.
This has two implications. First, server's transmission rate must
(loosely or tightly) match to client's consumption rate for an
uninterrupted playback. That is, the client must not run out of data
(buffer underrun) or take more than it can keep (buffer overrun) as
any excess media is simply discarded. Second, client's consumption
rate is limited by not only bandwidth availability but also the real-
time constraints. That is, the client cannot fetch media that is not
available 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 aims to provide a taxonomy of networking issues as they
relate to quality of experience in internet video delivery. The relate to quality of experience in internet video delivery. The
focus is on capturing characteristics of video delivery that have focus is on capturing characteristics of video delivery that have
surprised network designers or transport experts without specific surprised network designers or transport experts without specific
skipping to change at page 5, line 13 skipping to change at page 5, line 41
https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s
* MOPS Interim Meeting 2020-04-15: * MOPS Interim Meeting 2020-04-15:
https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s
* IETF 108 meeting: * IETF 108 meeting:
https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s
* MOPS 2020-10-30 Interim meeting:
https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s
2. Bandwidth Provisioning 2. Bandwidth Provisioning
2.1. Scaling Requirements for Media Delivery 2.1. Scaling Requirements for Media Delivery
2.1.1. Video Bitrates 2.1.1. Video Bitrates
Video bitrate selection depends on many variables. Different Video bitrate selection depends on many variables. Different
providers give different guidelines, but an equation that providers give different guidelines, but an equation that
approximately matches the bandwidth requirement estimates from approximately matches the bandwidth requirement estimates from
several video providers is given in [MSOD]: several video providers is given in [MSOD]:
Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (MOTION_FACTOR * 1024) Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (MOTION_FACTOR * 1024)
Height and width are in pixels, frame rate is in frames per second, Height and width are in pixels, frame rate is in frames per second,
skipping to change at page 6, line 36 skipping to change at page 7, line 22
smart delivery methods such as viewport-based or tiled-based smart delivery methods such as viewport-based or tiled-based
streaming, we do not need to send the whole scene to the user. streaming, we do not need to send the whole scene to the user.
Instead, the user needs only the portion corresponding to its Instead, the user needs only the portion corresponding to its
viewpoint at any given time. viewpoint at any given time.
In more immersive applications, where basic user movement (3DoF+) or In more immersive applications, where basic user movement (3DoF+) or
full user movement (6DoF) is allowed, the required bitrate grows even full user movement (6DoF) is allowed, the required bitrate grows even
further. In this case, the immersive content is typically referred further. In this case, the 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 [PCC] for more require a bitrate of 30 Mbps or higher. Refer to [MPEGI] and [PCC]
details. for more details.
2.2. Path Requirements 2.2. 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 would be necessary in order for all of them to approximately 80 Gbps would be necessary in order for all of them to
skipping to change at page 9, line 36 skipping to change at page 10, line 22
The causes of unpredictable usage described in Section 2.5 were more The causes of unpredictable usage described in Section 2.5 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 [Comcast], March 30,
* AT&T reported a 28% jump in core network traffic (single day in * AT&T reported a 28% jump in core network traffic (single day in
April, as compared to pre stay-at-home daily average traffic), April, as compared to pre stay-at-home daily average traffic),
with video accounting for nearly half of all mobile network with video accounting for nearly half of all mobile network
traffic, while social networking and web browsing remained the traffic, while social networking and web browsing remained the
highest percentage (almost a quarter each) of overall mobility highest percentage (almost a quarter each) of overall mobility
traffic [ATT], and traffic, and
* Verizon reported similar trends with video traffic up 36% over an * Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19) [Verizon]. average day (pre COVID-19)}.
We note that other operators saw similar spikes during this time We note that other operators saw similar spikes during this time
period. Craig Labowitz [Labovitz] reported period. Craig Labowitz [Labovitz] reported
* Weekday peak traffic increases over 45%-50% from pre-lockdown * Weekday peak traffic increases over 45%-50% from pre-lockdown
levels, levels,
* A 30% increase in upstream traffic over their pre-pandemic levels, * A 30% increase in upstream traffic over their pre-pandemic levels,
and and
* A steady increase in the overall volume of DDoS traffic, with * A steady increase in the overall volume of DDoS traffic, with
amounts exceeding the pre-pandemic levels by 40%. (He attributed amounts exceeding the pre-pandemic levels by 40%. (He attributed
this increase to the significant rise in gaming-related DDoS this increase to the significant rise in gaming-related DDoS
attacks ([LabovitzDDoS]), as gaming usage also increased.) attacks ([LabovitzDDoS]), as gaming usage also increased.)
Subsequently, the Inernet Architecture Board (IAB) held a COVID-19
Network Impacts Workshop [IABcovid] in November 2020. Given a larger
number of reports and more time to reflect, the following
observations from the draft workshop report are worth considering.
* Participants describing different types of networks reported
different kinds of impacts, but all types of networks saw impacts.
* Mobile networks saw traffic reductions and residential networks
saw significant increases.
* Reported traffic increases from ISPs and IXPs over just a few
weeks were as big as the traffic growth over the course of a
typical year, representing a 15-20% surge in growth to land at a
new normal that was much higher than anticipated.
* At DE-CIX Frankfurt, the world's largest Internet Exchange Point
in terms of data throughput, the year 2020 has seen the largest
increase in peak traffic within a single year since the IXP was
founded in 1995.
* The usage pattern changed significantly as work-from-home and
videoconferencing usage peaked during normal work hours, which
would have typically been off-peak hours with adults at work and
children at school. One might expect that the peak would have had
more impact on networks if it had happened during typical evening
peak hours for video streaming applications.
* The increase in daytime bandwidth consumption reflected both
significant increases in "essential" applications such as
videoconferencing and VPNs, and entertainment applications as
people watched videos or played games.
* At the IXP-level, it was observed that port utilization increased.
This phenomenon is mostly explained by a higher traffic demand
from residential users.
3. Adaptive Bitrate 3. Adaptive Bitrate
3.1. Overview 3.1. Overview
Adaptive BitRate (ABR) is a sort of application-level response Adaptive BitRate (ABR) is a sort of application-level response
strategy in which the receiving media player attempts to detect the strategy in which the streaming client attempts to detect the
available bandwidth of the network path by experiment or by observing available bandwidth of the network path by observing the successful
the successful application-layer download speed, then chooses a video application-layer download speed, then chooses a bitrate for each of
bitrate (among the limited number of available options) that fits the video, audio, subtitles and metadata (among the limited number of
within that bandwidth, typically adjusting as changes in available available options) that fits within that bandwidth, typically
bandwidth occur in the network or changes in capabilities occur in adjusting as changes in available bandwidth occur in the network or
the player (such as available memory, CPU, display size, etc.). changes in capabilities occur during the playback (such as available
memory, CPU, display size, etc.).
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 video player, such as highest achievable some metric monitored by the client, such as highest achievable video
video quality, or lowest rate of expected rebuffering events. quality or lowest chances for a rebuffering (playback stall).
3.2. Segmented Delivery 3.2. Segmented Delivery
ABR playback is commonly implemented by video players using HLS ABR playback is commonly implemented by streaming clients using HLS
[RFC8216] or DASH [DASH] to perform a reliable segmented delivery of [RFC8216] or DASH [DASH] to perform a reliable segmented delivery of
video data over HTTP. Different player implementations and receiving media over HTTP. Different implementations use different strategies
devices use different strategies, often proprietary algorithms [ABRSurvey], often proprietary algorithms (called rate adaptation or
(called rate adaptation or bitrate selection algorithms), to perform bitrate selection algorithms) to perform available bandwidth
available bandwidth estimation/prediction and the bitrate selection. estimation/prediction and the bitrate selection. Most clients only
Most players only use passive observations, i.e., they do not use passive observations, i.e., they do not generate probe traffic to
generate probe traffic to measure the available bandwidth. measure the available bandwidth.
This kind of bandwidth-measurement systems can experience trouble in This kind of bandwidth-measurement systems can experience trouble in
several ways that can be affected by networking design choices. several ways that can be affected by networking design choices.
3.2.1. Idle Time between Segments 3.2.1. Idle Time between Segments
When the bitrate selection is successfully chosen below the available When the bitrate selection is successfully chosen below the available
capacity of the network path, the response to a segment request will capacity of the network path, the response to a segment request will
typically complete in less absolute time than the duration of the typically complete in less absolute time than the duration of the
requested segment. The resulting idle time within the connection requested segment. The resulting idle time within the connection
skipping to change at page 12, line 34 skipping to change at page 14, line 5
This document introduces no new security issues. This document introduces no new security issues.
6. Acknowledgements 6. Acknowledgements
Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle
Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard,
and Mike English for their very helpful reviews and comments. and Mike English for their very helpful reviews and comments.
7. Informative References 7. Informative References
[ATT] AT&T, "Tuesday (March 24, 2020) Network Insights", March [ABRSurvey]
2020, <https://about.att.com/pages/COVID-19/updates.html>. Abdelhak Bentaleb et al, ., "A Survey on Bitrate
Adaptation Schemes for Streaming Media Over HTTP", 2019,
[Comcast] CNBC, "Comcast sees network traffic surge amid coronavirus <https://ieeexplore.ieee.org/abstract/document/8424813>.
outbreak", March 2020,
<https://www.cnbc.com/video/2020/03/30/comcast-sees-
network-traffic-surge-amid-coronavirus-outbreak.html>.
[CVNI] Cisco Systems, Inc., "Cisco Visual Networking Index: [CVNI] Cisco Systems, Inc, ., "Cisco Visual Networking Index:
Forecast and Trends, 2017-2022 White Paper", 27 February Forecast and Trends, 2017-2022 White Paper", 27 February
2019, <https://www.cisco.com/c/en/us/solutions/collateral/ 2019, <https://www.cisco.com/c/en/us/solutions/collateral/
service-provider/visual-networking-index-vni/white-paper- service-provider/visual-networking-index-vni/white-paper-
c11-741490.html>. c11-741490.html>.
[DASH] "Information technology -- Dynamic adaptive streaming over [DASH] "Information technology -- Dynamic adaptive streaming over
HTTP (DASH) -- Part 1: Media presentation description and HTTP (DASH) -- Part 1: Media presentation description and
segment formats", ISO/IEC 23009-1:2019, 2019. segment formats", ISO/IEC 23009-1:2019, 2019,
<https://www.iso.org/standard/79329.html>.
[IABcovid] Jari Arkko / Stephen Farrel / Mirja Kühlewind / Colin
Perkins, ., "Report from the IAB COVID-19 Network Impacts
Workshop 2020", November 2020,
<https://datatracker.ietf.org/doc/draft-iab-
covid19-workshop/>.
[Labovitz] Labovitz, C. and Nokia Deepfield, "Network traffic [Labovitz] Labovitz, C. and Nokia Deepfield, "Network traffic
insights in the time of COVID-19: April 9 update", April insights in the time of COVID-19: April 9 update", April
2020, <https://www.nokia.com/blog/network-traffic- 2020, <https://www.nokia.com/blog/network-traffic-
insights-time-covid-19-april-9-update/>. insights-time-covid-19-april-9-update/>.
[LabovitzDDoS] [LabovitzDDoS]
Takahashi, D. and Venture Beat, "Why the game industry is Takahashi, D. and Venture Beat, "Why the game industry is
still vulnerable to DDoS attacks", May 2018, still vulnerable 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/>.
[Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video [Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video
Alliance", 2020, <https://datatracker.ietf.org/meeting/ Alliance", 2020, <https://datatracker.ietf.org/meeting/
interim-2020-mops-01/materials/slides-interim-2020-mops- interim-2020-mops-01/materials/slides-interim-2020-mops-
01-sessa-april-15-2020-mops-interim-an-update-on- 01-sessa-april-15-2020-mops-interim-an-update-on-
streaming-video-alliance>. streaming-video-alliance>.
[MSOD] Akamai Technologies, Inc., "Media Services On Demand: [MPEGI] Boyce et al, J.M., "MPEG Immersive Video Coding Standard",
n.d., <https://ieeexplore.ieee.org/document/9374648>.
[MSOD] Akamai Technologies, Inc, ., "Media Services On Demand:
Encoder Best Practices", 2019, <https://learn.akamai.com/ Encoder Best Practices", 2019, <https://learn.akamai.com/
en-us/webhelp/media-services-on-demand/media-services-on- en-us/webhelp/media-services-on-demand/media-services-on-
demand-encoder-best-practices/GUID-7448548A-A96F-4D03- demand-encoder-best-practices/GUID-7448548A-A96F-4D03-
9E2D-4A4BBB6EC071.html>. 9E2D-4A4BBB6EC071.html>.
[NOSSDAV12] [NOSSDAV12]
al., S.A.e., "What Happens When HTTP Adaptive Streaming Saamer Akhshabi et al, ., "What Happens When HTTP Adaptive
Players Compete for Bandwidth?", June 2012, Streaming Players Compete for Bandwidth?", June 2012,
<https://dl.acm.org/doi/10.1145/2229087.2229092>. <https://dl.acm.org/doi/10.1145/2229087.2229092>.
[PCC] al., S.S.e., "Emerging MPEG Standards for Point Cloud [PCC] Sebastian Schwarz et al, ., "Emerging MPEG Standards for
Compression", March 2019, Point Cloud Compression", March 2019,
<https://ieeexplore.ieee.org/document/8571288>. <https://ieeexplore.ieee.org/document/8571288>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<https://www.rfc-editor.org/info/rfc2309>. <https://www.rfc-editor.org/info/rfc2309>.
skipping to change at page 14, line 43 skipping to change at page 16, line 19
<https://www.rfc-editor.org/info/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
[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/info/rfc8216>.
[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/info/rfc8622>.
[Verizon] Rorbuck, M. and Fierce Telecom, "Verizon: U.S. network
usage starts to normalize as subscribers settle into new
routines", April 2020,
<https://www.fiercetelecom.com/telecom/verizon-u-s-
network-usage-starts-to-normalize-as-subscribers-settle-
into-new-routines>.
Authors' Addresses Authors' Addresses
Jake Holland Jake Holland
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144, Cambridge, MA 02144,
United States of America United States of America
Email: jakeholland.net@gmail.com Email: jakeholland.net@gmail.com
Ali Begen Ali Begen
Networked Media Networked Media
 End of changes. 30 change blocks. 
69 lines changed or deleted 139 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/