< draft-ietf-mops-streaming-opcons-08.txt		draft-ietf-mops-streaming-opcons-09.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: 15 July 2022 Networked Media		Expires: 2 September 2022 Networked Media
	S. Dawkins		S. Dawkins
	Tencent America LLC		Tencent America LLC
	11 January 2022		1 March 2022
	Operational Considerations for Streaming Media		Operational Considerations for Streaming Media
	draft-ietf-mops-streaming-opcons-08		draft-ietf-mops-streaming-opcons-09
	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 when streaming video and other		that pertain to quality of experience when streaming 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 15 July 2022.		This Internet-Draft will expire on 2 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 26 ¶		skipping to change at page 2, line 26 ¶
	3.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8		3.2.1. Know Your Network Traffic . . . . . . . . . . . . . . 8
	3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9		3.3. Path Requirements . . . . . . . . . . . . . . . . . . . . 9
	3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 10		3.4. Caching Systems . . . . . . . . . . . . . . . . . . . . . 10
	3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11		3.5. Predictable Usage Profiles . . . . . . . . . . . . . . . 11
	3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11		3.6. Unpredictable Usage Profiles . . . . . . . . . . . . . . 11
	3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12		3.7. Extremely Unpredictable Usage Profiles . . . . . . . . . 12
	4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14		4. Latency Considerations . . . . . . . . . . . . . . . . . . . 14
	4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14		4.1. Ultra Low-Latency . . . . . . . . . . . . . . . . . . . . 14
	4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15		4.2. Low-Latency Live . . . . . . . . . . . . . . . . . . . . 15
	4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16		4.3. Non-Low-Latency Live . . . . . . . . . . . . . . . . . . 16
	4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 16		4.4. On-Demand . . . . . . . . . . . . . . . . . . . . . . . . 17
	5. Adaptive Encoding, Adaptive Delivery, and Measurement		5. Adaptive Encoding, Adaptive Delivery, and Measurement
	Collection . . . . . . . . . . . . . . . . . . . . . . . 17		Collection . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17		5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18		5.2. Adaptive Encoding . . . . . . . . . . . . . . . . . . . . 18
	5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18		5.3. Adaptive Segmented Delivery . . . . . . . . . . . . . . . 18
	5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 18		5.4. Advertising . . . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 20		5.5. Bitrate Detection Challenges . . . . . . . . . . . . . . 21
	5.5.1. Idle Time between Segments . . . . . . . . . . . . . 20		5.5.1. Idle Time between Segments . . . . . . . . . . . . . 21
	5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 21		5.5.2. Head-of-Line Blocking . . . . . . . . . . . . . . . . 22
	5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22		5.5.3. Wide and Rapid Variation in Path Capacity . . . . . . 22
	5.6. Measurement Collection . . . . . . . . . . . . . . . . . 22		5.6. Measurement Collection . . . . . . . . . . . . . . . . . 23
	5.6.1. CTA-2066: Streaming Quality of Experience Events,		5.6.1. CTA-2066: Streaming Quality of Experience Events,
	Properties and Metrics . . . . . . . . . . . . . . . 22		Properties and Metrics . . . . . . . . . . . . . . . 23
	5.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23		5.6.2. CTA-5004: Common Media Client Data (CMCD) . . . . . . 23
	5.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 23		5.7. Unreliable Transport . . . . . . . . . . . . . . . . . . 24
	6. Evolution of Transport Protocols and Transport Protocol		6. Evolution of Transport Protocols and Transport Protocol
	Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24		Behaviors . . . . . . . . . . . . . . . . . . . . . . . . 24
	6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 24		6.1. UDP and Its Behavior . . . . . . . . . . . . . . . . . . 25
	6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 25		6.2. TCP and Its Behavior . . . . . . . . . . . . . . . . . . 26
	6.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 26		6.3. The QUIC Protocol and Its Behavior . . . . . . . . . . . 27
	7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 28		7. Streaming Encrypted Media . . . . . . . . . . . . . . . . . . 29
	7.1. General Considerations for Media Encryption . . . . . . . 29		7.1. General Considerations for Media Encryption . . . . . . . 30
	7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 30		7.2. Considerations for "Hop-by-Hop" Media Encryption . . . . 31
	7.3. Considerations for "End-to-End" Media Encryption . . . . 31		7.3. Considerations for "End-to-End" Media Encryption . . . . 32
	8. Further Reading and References . . . . . . . . . . . . . . . 32		8. Further Reading and References . . . . . . . . . . . . . . . 33
	8.1. Industry Terminology . . . . . . . . . . . . . . . . . . 32		8.1. Industry Terminology . . . . . . . . . . . . . . . . . . 33
	8.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 32		8.2. Surveys and Tutorials . . . . . . . . . . . . . . . . . . 33
	8.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 32		8.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 33
	8.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33		8.2.2. Packaging . . . . . . . . . . . . . . . . . . . . . . 33
	8.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 33		8.2.3. Content Delivery . . . . . . . . . . . . . . . . . . 34
	8.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 33		8.2.4. ABR Algorithms . . . . . . . . . . . . . . . . . . . 34
	8.2.5. Low-Latency Live Adaptive Streaming . . . . . . . . . 34		8.2.5. Low-Latency Live Adaptive Streaming . . . . . . . . . 34
	8.2.6. Server/Client/Network Collaboration . . . . . . . . . 34		8.2.6. Server/Client/Network Collaboration . . . . . . . . . 35
	8.2.7. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35		8.2.7. QoE Metrics . . . . . . . . . . . . . . . . . . . . . 35
	8.2.8. Point Clouds and Immersive Media . . . . . . . . . . 35		8.2.8. Point Clouds and Immersive Media . . . . . . . . . . 36
	8.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36		8.3. Open-Source Tools . . . . . . . . . . . . . . . . . . . . 36
	8.4. Technical Events . . . . . . . . . . . . . . . . . . . . 36		8.4. Technical Events . . . . . . . . . . . . . . . . . . . . 37
	8.5. List of Organizations Working on Streaming Media . . . . 37		8.5. List of Organizations Working on Streaming Media . . . . 37
	8.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38		8.6. Topics to Keep an Eye on . . . . . . . . . . . . . . . . 38
	8.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38		8.6.1. 5G and Media . . . . . . . . . . . . . . . . . . . . 38
	8.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 38		8.6.2. Ad Insertion . . . . . . . . . . . . . . . . . . . . 39
	8.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 39		8.6.3. Contribution and Ingest . . . . . . . . . . . . . . . 40
	8.6.4. Synchronized Encoding and Packaging . . . . . . . . . 39		8.6.4. Synchronized Encoding and Packaging . . . . . . . . . 40
	8.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 39		8.6.5. WebRTC-Based Streaming . . . . . . . . . . . . . . . 40
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 40		10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
	12. Informative References . . . . . . . . . . . . . . . . . . . 40		12. Informative References . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	This document examines networking issues as they relate to quality of		This document examines networking issues as they relate to quality of
	experience in Internet media delivery, especially focusing on		experience in Internet media delivery, especially focusing on
	capturing characteristics of streaming video delivery that have		capturing characteristics of streaming video delivery that have
	surprised network designers or transport experts who lack specific		surprised network designers or transport experts who lack specific
	video expertise, since streaming media highlights key differences		video expertise, since streaming media highlights key differences
	between common assumptions in existing networking practices and		between common assumptions in existing networking practices and
	observations of video delivery issues encountered when streaming		observations of video delivery issues encountered when streaming
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	communications (for example, online videoconferencing) has also grown		communications (for example, online videoconferencing) has also grown
	significantly. While both streaming video and videoconferencing have		significantly. While both streaming video and videoconferencing have
	real-time delivery and latency requirements, these requirements vary		real-time delivery and latency requirements, these requirements vary
	from one application to another. For example, videoconferencing		from one application to another. For example, videoconferencing
	demands an end-to-end (one-way) latency of a few hundreds of		demands an end-to-end (one-way) latency of a few hundreds of
	milliseconds whereas live streaming can tolerate latencies of several		milliseconds whereas live streaming can tolerate latencies of several
	seconds.		seconds.
	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 is 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.
	Much of the focus of this document is on reliable media using HTTP		Much of the focus of this document is on reliable media using HTTP
	over TCP. which is widely used because support for HTTP is widely		over TCP, which is widely used because
	available in a wide range of operating systems, is also used in a
	wide variety of other applications, has been demonstrated to provide
	acceptable performance over the open Internet, includes state of the
	art standardized security mechanisms, and can make use of already-
	deployed caching infrastructure.
	Some mentions of unreliable media delivery using RTP and other UDP-		* support for HTTP is widely available in a wide range of operating
	based protocols appear in Section 4.1, Section 5.7, Section 6.1, and		systems,
	Section 7.2, but it's difficult to give general guidance for these
			* HTTP is also used in a wide variety of other applications,
			* HTTP has been demonstrated to provide acceptable performance over
			the open Internet,
			* HTTP includes state of the art standardized security mechanisms,
			and
			* HTTP can make use of already-deployed caching infrastructure.
			Unreliable media delivery using RTP and other UDP-based protocols is
			also discussed in Section 4.1, Section 5.7, Section 6.1, and
			Section 7.2, but it is difficult to give general guidance for these
	applications. For instance, when loss occurs, the most appropriate		applications. For instance, when loss occurs, the most appropriate
	response may depend on the type of codec being used.		response may depend on the type of codec being used.
	3. Bandwidth Provisioning		3. Bandwidth Provisioning
	3.1. Scaling Requirements for Media Delivery		3.1. Scaling Requirements for Media Delivery
	3.1.1. Video Bitrates		3.1.1. Video Bitrates
	Video bitrate selection depends on many variables including the		Video bitrate selection depends on many variables including the
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 30 ¶
	when that content is relatively static, caching content close to		when that content is relatively static, caching content close to
	requesters, and pre-loading caches to respond quickly to initial		requesters, and pre-loading caches to respond quickly to initial
	requests is often useful (for example, HTTP/1.1 caching is described		requests is often useful (for example, HTTP/1.1 caching is described
	in [I-D.ietf-httpbis-cache]). This is subject to the usual		in [I-D.ietf-httpbis-cache]). This is subject to the usual
	considerations for caching - for example, how much data must be		considerations for caching - for example, how much data must be
	cached to make a significant difference to the requester, and how the		cached to make a significant difference to the requester, and how the
	benefits of caching and pre-loading caches balances against the costs		benefits of caching and pre-loading caches balances against the costs
	of tracking "stale" content in caches and refreshing that content.		of tracking "stale" content in caches and refreshing that content.
	It is worth noting that not all high-demand content is "live"		It is worth noting that not all high-demand content is "live"
	content. One popular example is when popular streaming content can		content. One relevant example is when popular streaming content can
	be staged close to a significant number of requesters, as can happen		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		when a new episode of a popular show is released. This content may
	be largely stable, so low-cost to maintain in multiple places		be largely stable, so low-cost to maintain in multiple places
	throughout the Internet. This can reduce demands for high end-to-end		throughout the Internet. This can reduce demands for high end-to-end
	bandwidth without having to use mechanisms like multicast.		bandwidth without having to use mechanisms like multicast.
	Caching and pre-loading can also reduce exposure to peering point		Caching and pre-loading can also reduce exposure to peering point
	congestion, since less traffic crosses the peering point exchanges if		congestion, since less traffic crosses the peering point exchanges if
	the caches are placed in peer networks, especially when the content		the caches are placed in peer networks, especially when the content
	can be pre-loaded during off-peak hours, and especially if the		can be pre-loaded during off-peak hours, and especially if the
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 25 ¶
	cache could result in the cache holding a truncated segment and		cache could result in the cache holding a truncated segment and
	transmitting it to the end user's device. In this case, players		transmitting it to the end user's device. In this case, players
	rendering the stream often had the video freeze until the player was		rendering the stream often had the video freeze until the player was
	reset. In some cases the truncated object was even cached that way		reset. In some cases the truncated object was even cached that way
	and served later to other players as well, causing continued stalls		and served later to other players as well, causing continued stalls
	at the same spot in the video for all players playing the segment		at the same spot in the video for all players playing the segment
	delivered from that cache node.		delivered from that cache node.
	3.5. Predictable Usage Profiles		3.5. Predictable Usage Profiles
	Historical data shows that users consume more video and videos at		Historical data shows that users consume more videos and at a higher
	higher bitrates than they did in the past on their connected devices.		bit rate than they did in the past on their connected devices.
	Improvements in the codecs that help with reducing the encoding		Improvements in the codecs that help with reducing the encoding
	bitrates with better compression algorithms could not have offset the		bitrates with better compression algorithms could not have offset the
	increase in the demand for the higher quality video (higher		increase in the demand for the higher quality video (higher
	resolution, higher frame rate, better color gamut, better dynamic		resolution, higher frame rate, better color gamut, better dynamic
	range, etc.). In particular, mobile data usage has shown a large		range, etc.). In particular, mobile data usage has shown a large
	jump over the years due to increased consumption of entertainment as		jump over the years due to increased consumption of entertainment as
	well as conversational video.		well as conversational video.
	3.6. Unpredictable Usage Profiles		3.6. Unpredictable Usage Profiles
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 23 ¶
	rather than communicating with a server. Bittorrent favored peers		rather than communicating with a server. Bittorrent favored peers
	who uploaded as much as they downloaded, so that new Bittorrent users		who uploaded as much as they downloaded, so that new Bittorrent users
	had an incentive to significantly increase their upstream bandwidth		had an incentive to significantly increase their upstream bandwidth
	utilization.		utilization.
	The combination of the large volume of "torrents" and the peer-to-		The combination of the large volume of "torrents" and the peer-to-
	peer characteristic of swarm transfers meant that end user hosts were		peer characteristic of swarm transfers meant that end user hosts were
	suddenly uploading higher volumes of traffic to more destinations		suddenly uploading higher volumes of traffic to more destinations
	than was the case before Bittorrent. This caused at least one large		than was the case before Bittorrent. This caused at least one large
	internet service provider (ISP) to attempt to "throttle" these		internet service provider (ISP) to attempt to "throttle" these
	transfers, to mitigate the load that these hosts placed on their		transfers in order to to mitigate the load that these hosts placed on
	network. These efforts were met by increased use of encryption in		their network. These efforts were met by increased use of encryption
	Bittorrent, similar to an arms race, and set off discussions about		in Bittorrent, similar to an arms race, and set off discussions about
	"Net Neutrality" and calls for regulatory action.		"Net Neutrality" and calls for 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.
	3.7. Extremely Unpredictable Usage Profiles		3.7. Extremely Unpredictable Usage Profiles
	The causes of unpredictable usage described in Section 3.6 were more		The causes of unpredictable usage described in Section 3.6 were more
	skipping to change at page 15, line 39 ¶		skipping to change at page 16, line 8 ¶
	with failing to achieve this level of latency for live sporting		with failing to achieve this level of latency for live sporting
	events is the user experience failure from having crowds within		events is the user experience failure from having crowds within
	earshot of one another who react audibly to an important play, or		earshot of one another who react audibly to an important play, or
	from users who learn of an event in the match via some other channel,		from users who learn of an event in the match via some other channel,
	for example social media, before it has happened on the screen		for example social media, before it has happened on the screen
	showing the sporting event.		showing the sporting event.
	Applications requiring low-latency live media delivery are generally		Applications requiring low-latency live media delivery are generally
	feasible at scale with some restrictions. This typically requires		feasible at scale with some restrictions. This typically requires
	the use of a premium service dedicated to the delivery of live video,		the use of a premium service dedicated to the delivery of live video,
	and some tradeoffs may be necessary relative to what's feasible in a		and some tradeoffs may be necessary relative to what is feasible in a
	higher latency service. The tradeoffs may include higher costs, or		higher latency service. The tradeoffs may include higher costs, or
	delivering a lower quality video, or reduced flexibility for adaptive		delivering a lower quality video, or reduced flexibility for adaptive
	bitrates, or reduced flexibility for available resolutions so that		bitrates, or reduced flexibility for available resolutions so that
	fewer devices can receive an encoding tuned for their display. Low-		fewer devices can receive an encoding tuned for their display. Low-
	latency live delivery is also more susceptible to user-visible		latency live delivery is also more susceptible to user-visible
	disruptions due to transient network conditions than higher latency		disruptions due to transient network conditions than higher latency
	services.		services.
	Implementation of a low-latency live video service can be achieved		Implementation of a low-latency live video service can be achieved
	with the use of low-latency extensions of HLS (called LL-HLS)		with the use of low-latency extensions of HLS (called LL-HLS)
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 31 ¶
	(CMAF) standard [MPEG-CMAF] that allows the media to be packaged into		(CMAF) standard [MPEG-CMAF] that allows the media to be packaged into
	and transmitted in units smaller than segments, which are called		and transmitted in units smaller than segments, which are called
	chunks in CMAF language. This way, the latency can be decoupled from		chunks in CMAF language. This way, the latency can be decoupled from
	the duration of the media segments. Without a CMAF-like packaging,		the duration of the media segments. Without a CMAF-like packaging,
	lower latencies can only be achieved by using very short segment		lower latencies can only be achieved by using very short segment
	durations. However, shorter segments means more frequent intra-coded		durations. However, shorter segments means more frequent intra-coded
	frames and that is detrimental to video encoding quality. CMAF		frames and that is detrimental to video encoding quality. CMAF
	allows us to still use longer segments (improving encoding quality)		allows us to still use longer segments (improving encoding quality)
	without penalizing latency.		without penalizing latency.
	While an LL-HLS client retrieves each chunk with a separate HTTP GET		While a LL-HLS client retrieves each chunk with a separate HTTP GET
	request, an LL-DASH client uses the chunked transfer encoding feature		request, a LL-DASH client uses the chunked transfer encoding feature
	of the HTTP [CMAF-CTE] which allows the LL-DASH client to fetch all		of the HTTP [CMAF-CTE] which allows the LL-DASH client to fetch all
	the chunks belonging to a segment with a single GET request. An HTTP		the chunks belonging to a segment with a single GET request. An HTTP
	server can transmit the CMAF chunks to the LL-DASH client as they		server can transmit the CMAF chunks to the LL-DASH client as they
	arrive from the encoder/packager. A detailed comparison of LL-HLS		arrive from the encoder/packager. A detailed comparison of LL-HLS
	and LL-DASH is given in [MMSP20].		and LL-DASH is given in [MMSP20].
	4.3. Non-Low-Latency Live		4.3. Non-Low-Latency Live
	Non-low-latency live delivery of media is defined here as a live		Non-low-latency live delivery of media is defined here as a live
	stream that does not have a latency target shorter than 10 seconds.		stream that does not have a latency target shorter than 10 seconds.
	skipping to change at page 19, line 13 ¶		skipping to change at page 19, line 36 ¶
	inclusion of advertising alongside or interspersed with streaming		inclusion of advertising alongside or interspersed with streaming
	media content is therefore common in today's media landscape.		media content is therefore common in today's media landscape.
	Some commonly used forms of advertising can introduce potential user		Some commonly used forms of advertising can introduce potential user
	experience issues for a media stream. This section provides a very		experience issues for a media stream. This section provides a very
	brief overview of a complex and evolving space, but a complete		brief overview of a complex and evolving space, but a complete
	coverage of the potential issues is out of scope for this document.		coverage of the potential issues is out of scope for this document.
	The same techniques used to allow a media player to switch between		The same techniques used to allow a media player to switch between
	renditions of different bitrates at segment or chunk boundaries can		renditions of different bitrates at segment or chunk boundaries can
	also be used to enable the dynamic insertion of advertisements.		also be used to enable the dynamic insertion of advertisements
			(herafter referred to as "ads").
	Ads may be inserted either with Client Side Ad Insertion (CSAI) or		Ads may be inserted either with Client Side Ad Insertion (CSAI) or
	Server Side Ad Insertion (SSAI). In CSAI, the ABR manifest will		Server Side Ad Insertion (SSAI). In CSAI, the ABR manifest will
	generally include links to an external ad server for some segments of		generally include links to an external ad server for some segments of
	the media stream, while in SSAI the server will remain the same		the media stream, while in SSAI the server will remain the same
	during advertisements, but will include media segments that contain		during advertisements, but will include media segments that contain
	the advertising. In SSAI, the media segments may or may not be		the advertising. In SSAI, the media segments may or may not be
	sourced from an external ad server like with CSAI.		sourced from an external ad server like with CSAI.
	In general, the more targeted the ad request is, the more requests		In general, the more targeted the ad request is, the more requests
	skipping to change at page 20, line 32 ¶		skipping to change at page 21, line 17 ¶
	This kind of bandwidth-measurement system can experience trouble in		This kind of bandwidth-measurement system can experience trouble in
	several ways that are affected by networking issues. Because		several ways that are affected by networking issues. Because
	adaptive application-level response strategies are often using rates		adaptive application-level response strategies are often using rates
	as observed by the application layer, there are sometimes inscrutable		as observed by the application layer, there are sometimes inscrutable
	transport-level protocol behaviors that can produce surprising		transport-level protocol behaviors that can produce surprising
	measurement values when the application-level feedback loop is		measurement values when the application-level feedback loop is
	interacting with a transport-level feedback loop.		interacting with a transport-level feedback loop.
	A few specific examples of surprising phenomena that affect bitrate		A few specific examples of surprising phenomena that affect bitrate
	detection measurements are described in the following subsections.		detection measurements are described in the following subsections.
	As these examples will demonstrate, it's common to encounter cases		As these examples will demonstrate, it is common to encounter cases
	that can deliver application level measurements that are too low, too		that can deliver application level measurements that are too low, too
	high, and (possibly) correct but varying more quickly than a lab-		high, and (possibly) correct but varying more quickly than a lab-
	tested selection algorithm might expect.		tested selection algorithm might expect.
	These effects and others that cause transport behavior to diverge		These effects and others that cause transport behavior to diverge
	from lab modeling can sometimes have a significant impact on bitrate		from lab modeling can sometimes have a significant impact on bitrate
	selection and on user quality of experience, especially where players		selection and on user quality of experience, especially where players
	use naive measurement strategies and selection algorithms that don't		use naive measurement strategies and selection algorithms that don't
	account for the likelihood of bandwidth measurements that diverge		account for the likelihood of bandwidth measurements that diverge
	from the true path capacity.		from the true path capacity.
	skipping to change at page 22, line 5 ¶		skipping to change at page 22, line 40 ¶
	access to a lot of data at the same time.		access to a lot of data at the same time.
	To a receiver measuring bytes received per unit time at the		To a receiver measuring bytes received per unit time at the
	application layer, and interpreting it as an estimate of the		application layer, and interpreting it as an estimate of the
	available network bandwidth, this appears as a high jitter in the		available network bandwidth, this appears as a high jitter in the
	goodput measurement, presenting as a stall, followed by a sudden leap		goodput measurement, presenting as a stall, followed by a sudden leap
	that can far exceed the actual capacity of the transport path from		that can far exceed the actual capacity of the transport path from
	the server when the hole in the received data is filled by a later		the server when the hole in the received data is filled by a later
	retransmission.		retransmission.
	It's worth noting that more modern transport protocols such as QUIC		It is worth noting that more modern transport protocols such as QUIC
	have mitigation of head-of-line blocking as a protocol design goal.		have mitigation of head-of-line blocking as a protocol design goal.
	See Section 6.3 for more details.		See Section 6.3 for more details.
	5.5.3. Wide and Rapid Variation in Path Capacity		5.5.3. Wide and Rapid Variation in Path Capacity
	As many end devices have moved to wireless connectivity for the final		As many end devices have moved to wireless connectivity for the final
	hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have		hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
	emerged from radio interference and signal strength effects.		emerged from radio interference and signal strength effects.
	Each of these technologies can experience sudden changes in capacity		Each of these technologies can experience sudden changes in capacity
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 40 ¶
	In recent times, the usage of UDP-based applications that were not		In recent times, the usage of UDP-based applications that were not
	simple query-response protocols has grown substantially, and since		simple query-response protocols has grown substantially, and since
	UDP does not provide any feedback mechanism to senders to help limit		UDP does not provide any feedback mechanism to senders to help limit
	impacts on other users, application-level protocols such as RTP		impacts on other users, application-level protocols such as RTP
	[RFC3550] have been responsible for the decisions that TCP-based		[RFC3550] have been responsible for the decisions that TCP-based
	applications have delegated to TCP - what to send, how much to send,		applications have delegated to TCP - what to send, how much to send,
	and when to send it. So, the way some UDP-based applications		and when to send it. So, the way some UDP-based applications
	interact with other users has changed.		interact with other users has changed.
	It's also worth pointing out that because UDP has no transport-layer		It is also worth pointing out that because UDP has no transport-layer
	feedback mechanisms, UDP-based applications that send and receive		feedback mechanisms, UDP-based applications that send and receive
	substantial amounts of information are expected to provide their own		substantial amounts of information are expected to provide their own
	feedback mechanisms. This expectation is most recently codified in		feedback mechanisms. This expectation is most recently codified in
	Best Current Practice [RFC8085].		Best Current Practice [RFC8085].
	RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own		RTP relies on RTCP Sender and Receiver Reports [RFC3550] as its own
	feedback mechanism, and even includes Circuit Breakers for Unicast		feedback mechanism, and even includes Circuit Breakers for Unicast
	RTP Sessions [RFC8083] for situations when normal RTP congestion		RTP Sessions [RFC8083] for situations when normal RTP congestion
	control has not been able to react sufficiently to RTP flows sending		control has not been able to react sufficiently to RTP flows sending
	at rates that result in sustained packet loss.		at rates that result in sustained packet loss.
	skipping to change at page 27, line 26 ¶		skipping to change at page 28, line 11 ¶
	delivery to the application to continue. As described in [RFC9000],		delivery to the application to continue. As described in [RFC9000],
	QUIC connections can carry multiple streams, and when packet losses		QUIC connections can carry multiple streams, and when packet losses
	do occur, only the streams carried in the lost packet are delayed.		do occur, only the streams carried in the lost packet are delayed.
	A QUIC extension currently being specified ([I-D.ietf-quic-datagram])		A QUIC extension currently being specified ([I-D.ietf-quic-datagram])
	adds the capability for "unreliable" delivery, similar to the service		adds the capability for "unreliable" delivery, similar to the service
	provided by UDP, but these datagrams are still subject to the QUIC		provided by UDP, but these datagrams are still subject to the QUIC
	connection's congestion controller, providing some transport-level		connection's congestion controller, providing some transport-level
	congestion avoidance measures, which UDP does not.		congestion avoidance measures, which UDP does not.
	As noted in Section 6.2, there is increasing interest in transport		As noted in Section 6.2, there is an increasing interest in transport
	protocol behaviors that respond to delay measurements, instead of		protocol behaviors that respond to delay measurements, instead of
	responding to packet loss. These behaviors may deliver improved user		responding to packet loss. These behaviors may deliver improved user
	experience, but in some cases have not responded to sustained packet		experience, but in some cases have not responded to sustained packet
	loss, which exhausts available buffers along the end-to-end path that		loss, which exhausts available buffers along the end-to-end path that
	may affect other users sharing that path. The QUIC protocol provides		may affect other users sharing that path. The QUIC protocol provides
	a set of congestion control hooks that can be used for algorithm		a set of congestion control hooks that can be used for algorithm
	agility, and [RFC9002] defines a basic algorithm with transport		agility, and [RFC9002] defines a basic algorithm with transport
	behavior that is roughly similar to TCP NewReno [RFC6582]. However,		behavior that is roughly similar to TCP NewReno [RFC6582]. However,
	QUIC senders can and do unilaterally choose to use different		QUIC senders can and do unilaterally choose to use different
	algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or		algorithms such as loss-based CUBIC [RFC8312], delay-based COPA or
	skipping to change at page 28, line 34 ¶		skipping to change at page 29, line 24 ¶
	traffic. It discusses what network operators can consider in some		traffic. It discusses what network operators can consider in some
	detail.		detail.
	7. Streaming Encrypted Media		7. Streaming Encrypted Media
	"Encrypted Media" has at least three meanings:		"Encrypted Media" has at least three meanings:
	* Media encrypted at the application layer, typically using some		* Media encrypted at the application layer, typically using some
	sort of Digital Rights Management (DRM) system, and typically		sort of Digital Rights Management (DRM) system, and typically
	remaining encrypted "at rest", when senders and receivers store		remaining encrypted "at rest", when senders and receivers store
	it,		it.
	* Media encrypted by the sender at the transport layer, and		* Media encrypted by the sender at the transport layer, and
	remaining encrypted until it reaches the ultimate media consumer		remaining encrypted until it reaches the ultimate media consumer
	(in this document, referred to as "end-to-end media encryption"),		(in this document, referred to as "end-to-end media encryption").
	and
	* Media encrypted by the sender at the transport layer, and		* Media encrypted by the sender at the transport layer, and
	remaining encrypted until it reaches some intermediary that is		remaining encrypted until it reaches some intermediary that is
	_not_ the ultimate media consumer, but has credentials allowing		_not_ the ultimate media consumer, but has credentials allowing
	decryption of the media content. This intermediary may examine		decryption of the media content. This intermediary may examine
	and even transform the media content in some way, before		and even transform the media content in some way, before
	forwarding re-encrypted media content (in this document referred		forwarding re-encrypted media content (in this document referred
	to as "hop-by-hop media encryption").		to as "hop-by-hop media encryption").
	Both "hop-by-hop" and "end-to-end" encrypted transport may carry		Both "hop-by-hop" and "end-to-end" encrypted transport may carry
	skipping to change at page 40, line 19 ¶		skipping to change at page 41, line 15 ¶
	10. Security Considerations		10. Security Considerations
	Security is an important matter for streaming media applications and		Security is an important matter for streaming media applications and
	it was briefly touched on in Section 7.1. This document itself		it was briefly touched on in Section 7.1. This document itself
	introduces no new security issues.		introduces no new security issues.
	11. Acknowledgments		11. Acknowledgments
	Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,		Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
	Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,		Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham,
	Matt Stock, Mike English, Renan Krishna, Roni Even, and Will Law for		Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra,
	very helpful suggestions, reviews and comments.		and Will Law for very helpful suggestions, reviews and comments.
	(If we missed your name, please let us know!)
	12. Informative References		12. Informative References
	[ABRSurvey]		[ABRSurvey]
	Taani, B., Begen, A.C., Timmerer, C., Zimmermann, R., and		Taani, B., Begen, A. C., Timmerer, C., Zimmermann, R., and
	A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes		A. Bentaleb et al, "A Survey on Bitrate Adaptation Schemes
	for Streaming Media Over HTTP", IEEE Communications		for Streaming Media Over HTTP", IEEE Communications
	Surveys & Tutorials , 2019,		Surveys & Tutorials , 2019,
	<https://ieeexplore.ieee.org/abstract/document/8424813>.		<https://ieeexplore.ieee.org/abstract/document/8424813>.
	[BAP] "The Coalition for Better Ads", n.d.,		[BAP] "The Coalition for Better Ads", n.d.,
	<https://www.betterads.org/>.		<https://www.betterads.org/>.
	[CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion		[CDiD] Huitema, C. and B. Trammell, "(A call for) Congestion
	Defense in Depth", July 2019,		Defense in Depth", July 2019,
	skipping to change at page 41, line 18 ¶		skipping to change at page 42, line 10 ¶
	[COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based		[COPA18] Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based
	Congestion Control for the Internet", USENIX NSDI , April		Congestion Control for the Internet", USENIX NSDI , April
	2018, <https://web.mit.edu/copa/>.		2018, <https://web.mit.edu/copa/>.
	[CTA-2066] Consumer Technology Association, "Streaming Quality of		[CTA-2066] Consumer Technology Association, "Streaming Quality of
	Experience Events, Properties and Metrics", March 2020,		Experience Events, Properties and Metrics", March 2020,
	<https://shop.cta.tech/products/streaming-quality-of-		<https://shop.cta.tech/products/streaming-quality-of-
	experience-events-properties-and-metrics>.		experience-events-properties-and-metrics>.
	[CTA-5004] CTA, ., "Common Media Client Data (CMCD)", September 2020,		[CTA-5004] CTA, "Common Media Client Data (CMCD)", September 2020,
	<https://shop.cta.tech/products/web-application-video-		<https://shop.cta.tech/products/web-application-video-
	ecosystem-common-media-client-data-cta-5004>.		ecosystem-common-media-client-data-cta-5004>.
	[CVNI] "Cisco Visual Networking Index: Forecast and Trends,		[CVNI] "Cisco Visual Networking Index: Forecast and Trends,
	2017-2022 White Paper", 27 February 2019,		2017-2022 White Paper", 27 February 2019,
	<https://www.cisco.com/c/en/us/solutions/collateral/		<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>.
	[ELASTIC] De Cicco, L., Caldaralo, V., Palmisano, V., and S.		[ELASTIC] De Cicco, L., Caldaralo, V., Palmisano, V., and S.
	Mascolo, "ELASTIC: A client-side controller for dynamic		Mascolo, "ELASTIC: A client-side controller for dynamic
	adaptive streaming over HTTP (DASH)", Packet Video		adaptive streaming over HTTP (DASH)", Packet Video
	Workshop , December 2013,		Workshop , December 2013,
	<https://ieeexplore.ieee.org/document/6691442>.		<https://ieeexplore.ieee.org/document/6691442>.
	[Encodings]		[Encodings]
	Apple, Inc, ., "HLS Authoring Specification for Apple		Apple, Inc, "HLS Authoring Specification for Apple
	Devices", June 2020,		Devices", June 2020,
	<https://developer.apple.com/documentation/		<https://developer.apple.com/documentation/
	http_live_streaming/		http_live_streaming/
	hls_authoring_specification_for_apple_devices>.		hls_authoring_specification_for_apple_devices>.
	[I-D.cardwell-iccrg-bbr-congestion-control]		[I-D.cardwell-iccrg-bbr-congestion-control]
	Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.		Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
	Jacobson, "BBR Congestion Control", Work in Progress,		Jacobson, "BBR Congestion Control", Work in Progress,
	Internet-Draft, draft-cardwell-iccrg-bbr-congestion-		Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
	control-01, 7 November 2021,		control-01, 7 November 2021,
	skipping to change at page 42, line 21 ¶		skipping to change at page 43, line 8 ¶
	[I-D.ietf-httpbis-cache]		[I-D.ietf-httpbis-cache]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Caching", Work in Progress, Internet-Draft, draft-ietf-		Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-cache-19, 12 September 2021,		httpbis-cache-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	cache-19>.		cache-19>.
	[I-D.ietf-quic-datagram]		[I-D.ietf-quic-datagram]
	Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable		Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
	Datagram Extension to QUIC", Work in Progress, Internet-		Datagram Extension to QUIC", Work in Progress, Internet-
	Draft, draft-ietf-quic-datagram-07, 8 December 2021,		Draft, draft-ietf-quic-datagram-10, 4 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	datagram-07>.		datagram-10>.
	[I-D.ietf-quic-http]		[I-D.ietf-quic-http]
	Bishop, M., "Hypertext Transfer Protocol Version 3		Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-34, 2 February 2021,		quic-http-34, 2 February 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	http-34>.		http-34>.
	[I-D.ietf-quic-manageability]		[I-D.ietf-quic-manageability]
	Kuehlewind, M. and B. Trammell, "Manageability of the QUIC		Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
	Transport Protocol", Work in Progress, Internet-Draft,		Transport Protocol", Work in Progress, Internet-Draft,
	draft-ietf-quic-manageability-13, 2 September 2021,		draft-ietf-quic-manageability-14, 21 January 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	manageability-13>.		manageability-14>.
	[I-D.ietf-quic-qlog-h3-events]		[I-D.ietf-quic-qlog-h3-events]
	Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK		Marx, R., Niccolini, L., and M. Seemann, "HTTP/3 and QPACK
	event definitions for qlog", Work in Progress, Internet-		event definitions for qlog", Work in Progress, Internet-
	Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021,		Draft, draft-ietf-quic-qlog-h3-events-00, 10 June 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	qlog-h3-events-00>.		qlog-h3-events-00>.
	[I-D.ietf-quic-qlog-main-schema]		[I-D.ietf-quic-qlog-main-schema]
	Marx, R., Niccolini, L., and M. Seemann, "Main logging		Marx, R., Niccolini, L., and M. Seemann, "Main logging
	skipping to change at page 43, line 36 ¶		skipping to change at page 44, line 22 ¶
	<https://www.nokia.com/blog/network-traffic-insights-time-		<https://www.nokia.com/blog/network-traffic-insights-time-
	covid-19-april-9-update/>.		covid-19-april-9-update/>.
	[LabovitzDDoS]		[LabovitzDDoS]
	Takahashi, D., "Why the game industry is still vulnerable		Takahashi, D., "Why the game industry is still vulnerable
	to DDoS attacks", May 2018,		to DDoS attacks", May 2018,
	<https://venturebeat.com/2018/05/13/why-the-game-industry-		<https://venturebeat.com/2018/05/13/why-the-game-industry-
	is-still-vulnerable-to-distributed-denial-of-service-		is-still-vulnerable-to-distributed-denial-of-service-
	attacks/>.		attacks/>.
	[LL-DASH] DASH-IF, ., "Low-latency Modes for DASH", March 2020,		[LL-DASH] DASH-IF, "Low-latency Modes for DASH", March 2020,
	<https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>.		<https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>.
	[Micro] Taher, T.M., Misurac, M.J., LoCicero, J.L., and D.R. Ucci,		[Micro] Taher, T. M., Misurac, M. J., LoCicero, J. L., and D. R.
	"Microwave Oven Signal Interference Mitigation For Wi-Fi		Ucci, "Microwave Oven Signal Interference Mitigation For
	Communication Systems", 2008 5th IEEE Consumer		Wi-Fi Communication Systems", 2008 5th IEEE Consumer
	Communications and Networking Conference 5th IEEE, pp.		Communications and Networking Conference 5th IEEE, pp.
	67-68 , 2008.		67-68 , 2008.
	[Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video		[Mishra] Mishra, S. and J. Thibeault, "An update on Streaming Video
	Alliance", April 2020,		Alliance", April 2020,
	<https://datatracker.ietf.org/meeting/interim-2020-mops-		<https://datatracker.ietf.org/meeting/interim-2020-mops-
	01/materials/slides-interim-2020-mops-01-sessa-april-		01/materials/slides-interim-2020-mops-01-sessa-april-
	15-2020-mops-interim-an-update-on-streaming-video-		15-2020-mops-interim-an-update-on-streaming-video-
	alliance>.		alliance>.
	[MMSP20] Durak, K. and . et al, "Evaluating the performance of		[MMSP20] Durak, K. and et al, "Evaluating the performance of
	Apple's low-latency HLS", IEEE MMSP , September 2020,		Apple's low-latency HLS", IEEE MMSP , September 2020,
	<https://ieeexplore.ieee.org/document/9287117>.		<https://ieeexplore.ieee.org/document/9287117>.
	[MMSys11] Akhshabi, S., Begen, A.C., and C. Dovrolis, "An		[MMSys11] Akhshabi, S., Begen, A. C., and C. Dovrolis, "An
	experimental evaluation of rate-adaptation algorithms in		experimental evaluation of rate-adaptation algorithms in
	adaptive streaming over HTTP", ACM MMSys , February 2011,		adaptive streaming over HTTP", ACM MMSys , February 2011,
	<https://dl.acm.org/doi/10.1145/1943552.1943574>.		<https://dl.acm.org/doi/10.1145/1943552.1943574>.
	[MPEG-CMAF]		[MPEG-CMAF]
	"ISO/IEC 23000-19:2020 Multimedia application format		"ISO/IEC 23000-19:2020 Multimedia application format
	(MPEG-A) - Part 19: Common media application format (CMAF)		(MPEG-A) - Part 19: Common media application format (CMAF)
	for segmented media", March 2020,		for segmented media", March 2020,
	<https://www.iso.org/standard/79106.html>.		<https://www.iso.org/standard/79106.html>.
	skipping to change at page 44, line 36 ¶		skipping to change at page 45, line 21 ¶
	[MPEG-DASH-SAND]		[MPEG-DASH-SAND]
	"ISO/IEC 23009-5:2017 Dynamic adaptive streaming over HTTP		"ISO/IEC 23009-5:2017 Dynamic adaptive streaming over HTTP
	(DASH) - Part 5: Server and network assisted DASH (SAND)",		(DASH) - Part 5: Server and network assisted DASH (SAND)",
	February 2017, <https://www.iso.org/standard/69079.html>.		February 2017, <https://www.iso.org/standard/69079.html>.
	[MPEG-TS] "H.222.0 : Information technology - Generic coding of		[MPEG-TS] "H.222.0 : Information technology - Generic coding of
	moving pictures and associated audio information:		moving pictures and associated audio information:
	Systems", 29 August 2018,		Systems", 29 August 2018,
	<https://www.itu.int/rec/T-REC-H.222.0>.		<https://www.itu.int/rec/T-REC-H.222.0>.
	[MPEGI] Boyce, J.M. and . et al, "MPEG Immersive Video Coding		[MPEGI] Boyce, J. M. and et al, "MPEG Immersive Video Coding
	Standard", Proceedings of the IEEE , n.d.,		Standard", Proceedings of the IEEE , n.d.,
	<https://ieeexplore.ieee.org/document/9374648>.		<https://ieeexplore.ieee.org/document/9374648>.
	[OReilly-HPBN]		[OReilly-HPBN]
	"High Performance Browser Networking (Chapter 2: Building		"High Performance Browser Networking (Chapter 2: Building
	Blocks of TCP)", May 2021,		Blocks of TCP)", May 2021,
	<https://hpbn.co/building-blocks-of-tcp/>.		<https://hpbn.co/building-blocks-of-tcp/>.
	[PCC] Schwarz, S. and . et al, "Emerging MPEG Standards for		[PCC] Schwarz, S. and et al, "Emerging MPEG Standards for Point
	Point Cloud Compression", IEEE Journal on Emerging and		Cloud Compression", IEEE Journal on Emerging and Selected
	Selected Topics in Circuits and Systems , March 2019,		Topics in Circuits and Systems , March 2019,
	<https://ieeexplore.ieee.org/document/8571288>.		<https://ieeexplore.ieee.org/document/8571288>.
	[Port443] "Service Name and Transport Protocol Port Number		[Port443] "Service Name and Transport Protocol Port Number
	Registry", April 2021, <https://www.iana.org/assignments/		Registry", April 2021, <https://www.iana.org/assignments/
	service-names-port-numbers/service-names-port-		service-names-port-numbers/service-names-port-
	numbers.txt>.		numbers.txt>.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/rfc/rfc793>.		<https://www.rfc-editor.org/rfc/rfc793>.
	skipping to change at page 48, line 16 ¶		skipping to change at page 49, line 6 ¶
	<https://datatracker.ietf.org/doc/charter-ietf-sframe/>.		<https://datatracker.ietf.org/doc/charter-ietf-sframe/>.
	[SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol		[SRT] Sharabayko, M., "Secure Reliable Transport (SRT) Protocol
	Overview", 15 April 2020,		Overview", 15 April 2020,
	<https://datatracker.ietf.org/meeting/interim-2020-mops-		<https://datatracker.ietf.org/meeting/interim-2020-mops-
	01/materials/slides-interim-2020-mops-01-sessa-april-		01/materials/slides-interim-2020-mops-01-sessa-april-
	15-2020-mops-interim-an-update-on-streaming-video-		15-2020-mops-interim-an-update-on-streaming-video-
	alliance>.		alliance>.
	[Survey360o]		[Survey360o]
	Yaqoob, A., Bi, T., and G.-M. Muntean, "A Survey on		Yaqoob, A., Bi, T., and G. Muntean, "A Survey on Adaptive
	Adaptive 360° Video Streaming: Solutions, Challenges and		360° Video Streaming: Solutions, Challenges and
	Opportunities", IEEE Communications Surveys & Tutorials ,		Opportunities", IEEE Communications Surveys & Tutorials ,
	July 2020, <https://ieeexplore.ieee.org/document/9133103>.		July 2020, <https://ieeexplore.ieee.org/document/9133103>.
	[tsvarea-105]		[tsvarea-105]
	"TSVAREA Minutes - IETF 105", July 2019,		"TSVAREA Minutes - IETF 105", July 2019,
	<https://datatracker.ietf.org/meeting/105/materials/		<https://datatracker.ietf.org/meeting/105/materials/
	minutes-105-tsvarea-00>.		minutes-105-tsvarea-00>.
	Authors' Addresses		Authors' Addresses
End of changes. 46 change blocks.
	86 lines changed or deleted		92 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/