draft-ietf-mops-streaming-opcons-01.txt   draft-ietf-mops-streaming-opcons-02.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 September 2020 Networked Media Expires: 13 January 2021 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
9 March 2020 12 July 2020
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-01 draft-ietf-mops-streaming-opcons-02
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 delivery 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 September 2020. This Internet-Draft will expire on 13 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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. Venues for Contribution and Discussion . . . . . . . . . 3 1.1. Notes for Contributors and Reviewers . . . . . . . . . . 3
2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 3 1.1.1. Venues for Contribution and Discussion . . . . . . . 3
2.1. Scaling Requirements for Media Delivery . . . . . . . . . 3 1.1.2. Template for Contributions . . . . . . . . . . . . . 3
2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 3 1.1.3. History of Public Discussion . . . . . . . . . . . . 4
2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 4 2. Bandwidth Provisioning . . . . . . . . . . . . . . . . . . . 5
2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 4 2.1. Scaling Requirements for Media Delivery . . . . . . . . . 5
2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Video Bitrates . . . . . . . . . . . . . . . . . . . 5
2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 5 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 5
2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 5 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 6
3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 6
3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 7 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 7
3.2.1. Idle Time between Segments . . . . . . . . . . . . . 7 2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 8
3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 7 3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 8 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Doc History and Side Notes . . . . . . . . . . . . . . . . . 8 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Idle Time between Segments . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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]).
skipping to change at page 3, line 11 skipping to change at page 3, line 14
video expertise, since these highlight key differences between common video expertise, since these highlight key differences between common
assumptions in existing networking documents and observations of assumptions in existing networking documents and observations of
video delivery issues in practice. video delivery issues in practice.
Making specific recommendations for mitigating these issues is out of Making specific recommendations for mitigating these issues is out of
scope, though some existing mitigations are mentioned in passing. scope, though some existing mitigations are mentioned in passing.
The intent is to provide a point of reference for future solution The intent is to provide a point of reference for future solution
proposals to use in describing how new technologies address or avoid proposals to use in describing how new technologies address or avoid
these existing observed problems. these existing observed problems.
1.1. Venues for Contribution and Discussion 1.1. Notes for Contributors and Reviewers
Note to RFC Editor: Please remove this section before publication Note to RFC Editor: Please remove this section and its subsections
before publication.
(To the editor: check this repository URL after the draft is adopted. This section is to provide references to make it easier to review the
The working group may create its own repository) development and discussion on the draft so far.
This document is in the Github repository at 1.1.1. Venues for Contribution and Discussion
https://github.com/GrumpyOldTroll/ietf-mops-drafts. Readers are
welcome to open issues and send pull requests for this document. This document is in the Github repository at:
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons
Readers are welcome to open issues and send pull requests for this
document.
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
* Search: https://mailarchive.ietf.org/arch/browse/mops/
1.1.2. Template for Contributions
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/
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:
* IETF 105 BOF:
https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s
* IETF 106 meeting:
https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s
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]:
skipping to change at page 4, line 5 skipping to change at page 5, line 28
Height and width are in pixels, and frame rate is in frames per Height and width are in pixels, and frame rate is in frames per
second. The actual bitrate required for a specific video will also second. The actual bitrate required for a specific video will also
depend on the codec used, fidelity desired and some other depend on the codec used, fidelity desired and some other
characteristics of the video itself, such as the amount and frequency characteristics of the video itself, such as the amount and frequency
of high-detail motion, which may influence the compressability of the of high-detail motion, which may influence the compressability of the
content, but this equation provides a rough estimate. content, but this equation provides a rough estimate.
Here are a few common resolutions used for video content, with their Here are a few common resolutions used for video content, with their
typical per-user bandwidth requirements according to this formula: typical per-user bandwidth requirements according to this formula:
+------------+----------------+-------------------------------+ +============+================+===============================+
| Name | Width x Height | Approximate Bitrate for 60fps | | Name | Width x Height | Approximate Bitrate for 60fps |
+============+================+===============================+ +============+================+===============================+
| DVD | 720 x 480 | 1.3 Mbps | | DVD | 720 x 480 | 1.3 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+-------------------------------+
| 720p (1K) | 1280 x 720 | 3.6 Mbps | | 720p (1K) | 1280 x 720 | 3.6 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+-------------------------------+
| 1080p (2K) | 1920 x 1080 | 8.1 Mbps | | 1080p (2K) | 1920 x 1080 | 8.1 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+-------------------------------+
| 2160p (4k) | 3840 x 2160 | 32 Mbps | | 2160p (4k) | 3840 x 2160 | 32 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+-------------------------------+
skipping to change at page 6, line 42 skipping to change at page 8, line 16
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
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
post-IETF 107 meeting that humans are not always in control, and
forces of nature can cause enormous fluctuations in traffic patterns.
In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19
pandemic broke out in early 2020,
* Comcast's streaming and web video consumption rose by 38%, with
their reported peak traffic up 32% overall between March 1 to
March 30 [Comcast],
* AT&T reported a 28% jump in core network traffic (single day in
April, as compared to pre stay-at-home daily average traffic),
with video accounting for nearly half of all mobile network
traffic, while social networking and web browsing remained the
highest percentage (almost a quarter each) of overall mobility
traffic [ATT], and
* Verizon reported similar trends with video traffic up 36% over an
average day (pre COVID-19) [Verizon].
We note that other operators saw similar spikes during this time
period. Craig Labowitz [Labovitz] reported
* Weekday peak traffic increases over 45%-50% from pre-lockdown
levels,
* A 30% increase in upstream traffic over their pre-pandemic levels,
and
* A steady increase in the overall volume of DDoS traffic, with
amounts exceeding the pre-pandemic levels by 40%. (He attributed
this increase to the significant rise in gaming-related DDoS
attacks ([LabovitzDDoS]), as gaming usage also increased.)
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 receiving media player attempts to detect the
available bandwidth of the network path by experiment or by observing available bandwidth of the network path by experiment or by observing
the successful application-layer download speed, then chooses a video the successful application-layer download speed, then chooses a video
bitrate (among the limited number of available options) that fits bitrate (among the limited number of available options) that fits
within that bandwidth, typically adjusting as changes in available within that bandwidth, typically adjusting as changes in available
skipping to change at page 8, line 38 skipping to change at page 11, line 12
applications like videoconferencing, or for other live-action video applications like videoconferencing, or for other live-action video
with interactive components, such as some sporting events. with interactive components, such as some sporting events.
Congestion avoidance strategies for this kind of deployment vary Congestion avoidance strategies for this kind of deployment vary
widely in practice, ranging from some streams that are entirely widely in practice, ranging from some streams that are entirely
unresponsive to using feedback signaling to change encoder settings unresponsive to using feedback signaling to change encoder settings
(as in [RFC5762]), or to use fewer enhancement layers (as in (as in [RFC5762]), or to use fewer enhancement layers (as in
[RFC6190]), to proprietary methods for detecting quality of [RFC6190]), to proprietary methods for detecting quality of
experience issues and cutting off video. experience issues and cutting off video.
4. Doc History and Side Notes 4. IANA Considerations
Note to RFC Editor: Please remove this section before publication
TBD: suggestion from mic at IETF 106 (Mark Nottingham): dive into the
different constraints coming from different parts of the network or
distribution channels. (regarding questions about how to describe the
disconnect between demand vs. capacity, while keeping good archival
value.) https://www.youtube.com/watch?v=4_k340xT2jM&t=13m
TBD: suggestion from mic at IETF 106 (Dave Oran + Glenn Deen
responding): pre-placement for many use cases is useful-distinguish
between live vs. cacheable. "People assume high-demand == live, but
not always true" with popular netflix example.
(Glenn): something about latency requirements for cached vs.
streaming on live vs. pre-recorded content, and breaking
requirements into 2 separate charts. also: "Standardized ladder" for
adaptive bit rate rates suggested, declined as out of scope.
https://www.youtube.com/watch?v=4_k340xT2jM&t=14m15s
TBD: suggestion at the mic from IETF 106 (Aaron Falk): include
industry standard metrics from citations, some standard scoping
metrics may be already defined. https://www.youtube.com/
watch?v=4_k340xT2jM&t=19m15s
5. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
6. Security Considerations 5. Security Considerations
This document introduces no new security issues. This document introduces no new security issues.
7. 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, and Leslie Daigle for their very helpful reviews and comments. Rose, and Leslie Daigle for their very helpful reviews and comments.
8. Informative References 7. Informative References
[ATT] AT&T, "Tuesday (March 24, 2020) Network Insights", March
2020, <https://about.att.com/pages/COVID-19/updates.html>.
[Comcast] CNBC, "Comcast sees network traffic surge amid coronavirus
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.
[Labovitz] Labovitz, C. and Nokia Deepfield, "Network traffic
insights in the time of COVID-19: April 9 update", April
2020, <https://www.nokia.com/blog/network-traffic-
insights-time-covid-19-april-9-update/>.
[LabovitzDDoS]
Takahashi, D. and Venture Beat, "Why the game industry is
still vulnerable to DDoS attacks", May 2018,
<https://venturebeat.com/2018/05/13/why-the-game-industry-
is-still-vulnerable-to-distributed-denial-of-service-
attacks/>.
[Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video
Alliance", 2020, <https://datatracker.ietf.org/meeting/
interim-2020-mops-01/materials/slides-interim-2020-mops-
01-sessa-april-15-2020-mops-interim-an-update-on-
streaming-video-alliance>.
[MSOD] Akamai Technologies, Inc., "Media Services On Demand: [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 al., S.A.e., "What Happens When HTTP Adaptive Streaming
Players Compete for Bandwidth?", June 2012, Players Compete for Bandwidth?", June 2012,
<https://dl.acm.org/doi/10.1145/2229087.2229092>. <https://dl.acm.org/doi/10.1145/2229087.2229092>.
skipping to change at page 10, line 46 skipping to change at page 13, line 20
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A "Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<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>.
[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
 End of changes. 18 change blocks. 
63 lines changed or deleted 182 lines changed or added

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