< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/