< draft-ietf-mops-streaming-opcons-02.txt   draft-ietf-mops-streaming-opcons-03.txt >
MOPS J. Holland MOPS J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Informational A. Begen Intended status: Informational A. Begen
Expires: 13 January 2021 Networked Media Expires: 5 May 2021 Networked Media
S. Dawkins S. Dawkins
Tencent America LLC Tencent America LLC
12 July 2020 1 November 2020
Operational Considerations for Streaming Media Operational Considerations for Streaming Media
draft-ietf-mops-streaming-opcons-02 draft-ietf-mops-streaming-opcons-03
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 13 January 2021. This Internet-Draft will expire on 5 May 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . 3
1.1.2. Template for Contributions . . . . . . . . . . . . . 3 1.1.2. Template for Contributions . . . . . . . . . . . . . 3
1.1.3. History of Public Discussion . . . . . . . . . . . . 4 1.1.3. History of Public Discussion . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 5
2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 5 2.1.2. Virtual Reality Bitrates . . . . . . . . . . . . . . 6
2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 6 2.2. Path Requirements . . . . . . . . . . . . . . . . . . . . 6
2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 6 2.3. Caching Systems . . . . . . . . . . . . . . . . . . . . . 7
2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 6 2.4. Predictable Usage Profiles . . . . . . . . . . . . . . . 8
2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 7 2.5. Unpredictable Usage Profiles . . . . . . . . . . . . . . 8
2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 8 2.6. Extremely Unpredictable Usage Profiles . . . . . . . . . 9
3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 9 3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 9 3.2. Segmented Delivery . . . . . . . . . . . . . . . . . . . 10
3.2.1. Idle Time between Segments . . . . . . . . . . . . . 9 3.2.1. Idle Time between Segments . . . . . . . . . . . . . 11
3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 10 3.2.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 11
3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 10 3.3. Unreliable Transport . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. Informative References . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 5, line 5 skipping to change at page 5, line 5
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
* IETF 106 meeting: * IETF 106 meeting:
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:
https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s
* IETF 108 meeting:
https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s
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) / (15 * 1024) Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (MOTION_FACTOR * 1024)
Height and width are in pixels, and frame rate is in frames per Height and width are in pixels, frame rate is in frames per second,
second. The actual bitrate required for a specific video will also and the motion factor is a value that ranges from 20 for a low-motion
depend on the codec used, fidelity desired and some other talking heads video to 7 for sports, and content with a lot of screen
characteristics of the video itself, such as the amount and frequency changes.
of high-detail motion, which may influence the compressability of the
content, but this equation provides a rough estimate. The motion factor captures the variability in bitrate due to the
amount and frequency of high-detail motion, which generally
influences the compressability of the content.
The exact bitrate required for a particular video also depends on a
number of specifics about the codec used and how the codec-specific
tuning parameters are matched to the content, but this equation
provides a rough estimate that approximates the usual bitrate
characteristics using the most common codecs and settings for
production traffic.
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 and peak per-user bandwidth requirements for 60 frames per
second (FPS):
+============+================+===============================+ +============+================+==========+=========+
| Name | Width x Height | Approximate Bitrate for 60fps | | Name | Width x Height | Typical | Peak |
+============+================+===============================+ +============+================+==========+=========+
| DVD | 720 x 480 | 1.3 Mbps | | DVD | 720 x 480 | 1.3 Mbps | 3 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+----------+---------+
| 720p (1K) | 1280 x 720 | 3.6 Mbps | | 720p (1K) | 1280 x 720 | 3.6 Mbps | 5 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+----------+---------+
| 1080p (2K) | 1920 x 1080 | 8.1 Mbps | | 1080p (2K) | 1920 x 1080 | 8.1 Mbps | 18 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+----------+---------+
| 2160p (4k) | 3840 x 2160 | 32 Mbps | | 2160p (4k) | 3840 x 2160 | 32 Mbps | 70 Mbps |
+------------+----------------+-------------------------------+ +------------+----------------+----------+---------+
Table 1 Table 1
2.1.2. Virtual Reality Bitrates 2.1.2. Virtual Reality Bitrates
Even the basic virtual reality (360-degree) videos (that allow users Even the basic virtual reality (360-degree) videos (that allow users
to look around freely, referred to as three degrees of freedom - to look around freely, referred to as three degrees of freedom -
3DoF) require substantially larger bitrates when they are captured 3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the and encoded as such videos require multiple fields of view of the
scene. The typical multiplication factor is 8 to 10. Yet, due to scene. The typical multiplication factor is 8 to 10. Yet, due to
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.
skipping to change at page 6, line 21 skipping to change at page 6, line 47
details. 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 up to 80 Gbps would be necessary in order for all of approximately 80 Gbps would be necessary in order for all of them to
them to get 1080p resolution at 60 fps. get typical content at 1080p resolution at 60 fps, or up to 180 Gbps
to get sustained high-motion content such as sports, while
maintaining the same resolution.
However, when there is some overlap in the feeds being consumed by However, when there is some overlap in the feeds being consumed by
end users, it is sometimes possible to reduce the bandwidth end users, it is sometimes possible to reduce the bandwidth
provisioning requirements for the network by performing some kind of provisioning requirements for the network by performing some kind of
replication within the network. This can be achieved via object replication within the network. This can be achieved via object
caching with delivery of replicated objects over individual caching with delivery of replicated objects over individual
connections, and/or by packet-level replication using multicast. connections, and/or by packet-level replication using multicast.
To the extent that replication of popular content can be performed, To the extent that replication of popular content can be performed,
bandwidth requirements at peering or ingest points can be reduced to bandwidth requirements at peering or ingest points can be reduced to
as low as a per-feed requirement instead of a per-user requirement. as low as a per-feed requirement instead of a per-user requirement.
2.3. Caching Systems 2.3. Caching Systems
TBD: pros, cons, tradeoffs of caching designs at different locations When demand for content is relatively predictable, and especially
within the network? when that content is relatively static, caching content close to
requesters, and pre-loading caches to respond quickly to initial
requests, is often useful (for example, HTTP/1.1 caching is described
in [RFC7234]). This is subject to the usual considerations for
caching - for example, how much data must be cached to make a
significant difference to the requester, and how the benefits of
caching and pre-loading caches balances against the costs of tracking
"stale" content in caches and refreshing that content.
Peak vs. average provisioning, and effects on peering point It is worth noting that not all high-demand content is also "live"
congestion under peak load? content. One popular example is when popular streaming content can
be staged close to a significant number of requesters, as can happen
when a new episode of a popular show is released. This content may
be largely stable, so low-cost to maintain in multiple places
throughout the Internet. This can reduce demands for high end-to-end
bandwidth without having to use mechanisms like multicast.
Provisioning issues for caching systems? Caching and pre-loading can also reduce exposure to peering point
congestion, since less traffic crosses the peering point exchanges if
the caches are placed in peer networks, and could be pre-loaded
during off-peak hours, using "Lower-Effort Per-Hop Behavior (LE PHB)
for Differentiated Services" [RFC8622], "Low Extra Delay Background
Transport (LEDBAT)" [RFC6817], or similar mechanisms.
All of this depends, of course, on the ability of a content provider
to predict usage and provision bandwidth, caching, and other
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
(Section 2.5, Section 2.6).
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
skipping to change at page 11, line 23 skipping to change at page 12, line 29
This document requires no actions from IANA. This document requires no actions from IANA.
5. Security Considerations 5. Security Considerations
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, and Leslie Daigle for their very helpful reviews and comments. Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard,
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 [ATT] AT&T, "Tuesday (March 24, 2020) Network Insights", March
2020, <https://about.att.com/pages/COVID-19/updates.html>. 2020, <https://about.att.com/pages/COVID-19/updates.html>.
[Comcast] CNBC, "Comcast sees network traffic surge amid coronavirus [Comcast] CNBC, "Comcast sees network traffic surge amid coronavirus
outbreak", March 2020, outbreak", March 2020,
<https://www.cnbc.com/video/2020/03/30/comcast-sees- <https://www.cnbc.com/video/2020/03/30/comcast-sees-
network-traffic-surge-amid-coronavirus-outbreak.html>. network-traffic-surge-amid-coronavirus-outbreak.html>.
skipping to change at page 13, line 10 skipping to change at page 14, line 19
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April
2010, <https://www.rfc-editor.org/info/rfc5762>. 2010, <https://www.rfc-editor.org/info/rfc5762>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<https://www.rfc-editor.org/info/rfc6190>. <https://www.rfc-editor.org/info/rfc6190>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[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>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[Verizon] Rorbuck, M. and Fierce Telecom, "Verizon: U.S. network [Verizon] Rorbuck, M. and Fierce Telecom, "Verizon: U.S. network
usage starts to normalize as subscribers settle into new usage starts to normalize as subscribers settle into new
routines", April 2020, routines", April 2020,
<https://www.fiercetelecom.com/telecom/verizon-u-s- <https://www.fiercetelecom.com/telecom/verizon-u-s-
network-usage-starts-to-normalize-as-subscribers-settle- network-usage-starts-to-normalize-as-subscribers-settle-
into-new-routines>. 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. 20 change blocks. 
49 lines changed or deleted 106 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/