draft-ietf-rmcat-cc-requirements-06.txt		draft-ietf-rmcat-cc-requirements-07.txt
	Network Working Group R. Jesup		Network Working Group R. Jesup
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Informational October 7, 2014		Intended status: Informational Z. Sarker, Ed.
	Expires: April 10, 2015		Expires: April 30, 2015 Ericsson
			October 27, 2014
	Congestion Control Requirements For RMCAT		Congestion Control Requirements for Interactive Real-Time Media
	draft-ietf-rmcat-cc-requirements-06		draft-ietf-rmcat-cc-requirements-07
	Abstract		Abstract
	Congestion control is needed for all data transported across the		Congestion control is needed for all data transported across the
	Internet, in order to promote fair usage and prevent congestion		Internet, in order to promote fair usage and prevent congestion
	collapse. The requirements for interactive, point-to-point real time		collapse. The requirements for interactive, point-to-point real-time
	multimedia, which needs low-delay, semi-reliable data delivery, are		multimedia, which needs low-delay, semi-reliable data delivery, are
	different from the requirements for bulk transfer like FTP or bursty		different from the requirements for bulk transfer like FTP or bursty
	transfers like Web pages. Due to an increasing amount of RTP-based		transfers like Web pages. Due to an increasing amount of RTP-based
	real-time media traffic on the Internet (e.g. with the introduction		real-time media traffic on the Internet (e.g. with the introduction
	of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to		of the Web Real-Time Communication (WebRTC)), it is especially
	ensure that this kind of traffic is congestion controlled.		important to ensure that this kind of traffic is congestion
			controlled.
	This document describes a set of requirements that can be used to		This document describes a set of requirements that can be used to
	evaluate other congestion control mechanisms in order to figure out		evaluate other congestion control mechanisms in order to figure out
	their fitness for this purpose, and in particular to provide a set of		their fitness for this purpose, and in particular to provide a set of
	possible requirements for realtime media congestion avoidance		possible requirements for real-time media congestion avoidance
	technique.		technique.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	The terms are presented in many cases using lowercase for		The terms are presented in many cases using lowercase for
	readability.		readability.
	skipping to change at page 2, line 7		skipping to change at page 2, line 10
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 10, 2015.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		3. Deficiencies of existing mechanisms . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Most of today's TCP congestion control schemes were developed with a		Most of today's TCP congestion control schemes were developed with a
	focus on an use of the Internet for reliable bulk transfer of non-		focus on an use of the Internet for reliable bulk transfer of non-
	time-critical data, such as transfer of large files. They have also		time-critical data, such as transfer of large files. They have also
	been used successfully to govern the reliable transfer of smaller		been used successfully to govern the reliable transfer of smaller
	chunks of data in as short a time as possible, such as when fetching		chunks of data in as short a time as possible, such as when fetching
	Web pages.		Web pages.
	These algorithms have also been used for transfer of media streams		These algorithms have also been used for transfer of media streams
	that are viewed in a non-interactive manner, such as "streaming"		that are viewed in a non-interactive manner, such as "streaming"
	video, where having the data ready when the viewer wants it is		video, where having the data ready when the viewer wants it is
	important, but the exact timing of the delivery is not.		important, but the exact timing of the delivery is not.
	When doing real time interactive media, the requirements are		When doing real-time interactive media, the requirements are
	different; one needs to provide the data continuously, within a very		different; one needs to provide the data continuously, within a very
	limited time window (no more than 100s of milliseconds end-to-end		limited time window (no more than 100s of milliseconds end-to-end
	delay), the sources of data may be able to adapt the amount of data		delay), the sources of data may be able to adapt the amount of data
	that needs sending within fairly wide margins, and may tolerate some		that needs sending within fairly wide margins but can be rate limited
	amount of packet loss, but since the data is generated in real time,		by the application- even not always have data to send, and may
	sending "future" data is impossible, and since it's consumed in real		tolerate some amount of packet loss, but since the data is generated
	time, data delivered late is commonly useless.		in real-time, sending "future" data is impossible, and since it's
			consumed in real-time, data delivered late is commonly useless.
	While the requirements for RMCAT differ from the requirements for the		While the requirements for real-time interactive differ from the
	other flow types, these other flow types will be present in the		requirements for the other flow types, these other flow types will be
	network. The RMCAT congestion control algorithm must work properly		present in the network. The congestion control algorithm for real-
	when these other flow types are present as cross traffic on the		time interactive media must work properly when these other flow types
	network.		are present as cross traffic on the network.
	One particular protocol portofolio being developed for this use case		One particular protocol portofolio being developed for this use case
	is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending		is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending
	multiple RTP-based flows between two peers, in conjunction with data		multiple flows using the Real-time Transport Protocol (RTP) [RFC3550]
	flows, all at the same time, without having special arrangements with		between two peers, in conjunction with data flows, all at the same
	the intervening service providers.		time, without having special arrangements with the intervening
			service providers.
	Given that this use case is the focus of this document, use cases		Given that this use case is the focus of this document, use cases
	involving noninteractive media such as video streaming, and use cases		involving non-interactive media such as video streaming, and use
	using multicast/broadcast-type technologies, are out of scope.		cases using multicast/broadcast-type technologies, are out of scope.
	The terminology defined in [I-D.ietf-rtcweb-overview] is used in this		The terminology defined in [I-D.ietf-rtcweb-overview] is used in this
	memo.		memo.
	2. Requirements		2. Requirements
	1. The congestion control algorithm must attempt to provide as-low-		1. The congestion control algorithm must attempt to provide as-low-
	as-possible-delay transit for real-time traffic while still		as-possible-delay transit for interactive real-time traffic
	providing a useful amount of bandwidth. There may be lower		while still providing a useful amount of bandwidth. There may
	limits on the amount of bandwidth that is useful, but this is		be lower limits on the amount of bandwidth that is useful, but
	largely application-specific and the application may be able to		this is largely application-specific and the application may be
	modify or remove flows in order allow some useful flows to get		able to modify or remove flows in order allow some useful flows
	enough bandwidth. (Example: not enough bandwidth for low-		to get enough bandwidth. (Example: not enough bandwidth for
	latency video+audio, but enough for audio-only.)		low-latency video+audio, but enough for audio-only.)
	A. Jitter (variation in the bitrate over short timescales) also		A. Jitter (variation in the bitrate over short timescales) also
	is relevant, though moderate amounts of jitter will be		is relevant, though moderate amounts of jitter will be
	absorbed by jitter buffers. Transit delay should be		absorbed by jitter buffers. Transit delay should be
	considered to track the short-term maximums of delay		considered to track the short-term maximums of delay
	including jitter.		including jitter.
	B. It should provide this as-low-as-possible-delay transit even		B. It should provide this as-low-as-possible-delay transit even
	when faced with intermediate bottlenecks and competing		when faced with intermediate bottlenecks and competing
	flows. Competing flows may limit what's possible to		flows. Competing flows may limit what's possible to
	achieve.		achieve.
	C. It should handle routing changes which may alter or remove		C. It should handle routing changes which may alter or remove
	bottlenecks or change the bandwidth available, and react		bottlenecks or change the bandwidth available especially if
	quickly, especially if there is a reduction in available		there is a reduction in available bandwidth or increase in
	bandwidth or increase in observed delay.		observed delay. It is expected that the mechanism reacts to
			the routing change events in a way that avoids delay
			buildup.
	D. It should handle interface changes (WLAN to 3G data, etc)		D. It should handle both local and remote interface changes
	which may radically change the bandwidth available or		(WLAN to 3G data, etc) which may radically change the
	bottlenecks, and react quickly, especially if there is a		bandwidth available or bottlenecks, especially if there is a
	reduction in available bandwidth or increase in bottleneck		reduction in available bandwidth or increase in bottleneck
	delay. It is assumed that an interface change can generate		delay. It is assumed that an interface change can generate
	a notification to the algorithm.		a notification to the algorithm.
	E. The offered load may be less than the available bandwidth at		E. The algorithm must consider the case where offered loads are
	any given moment, and may vary dramatically over time,		less than the available bandwidth at any given moment, and
	including dropping to no load and then resuming a high load,		may vary dramatically over time, including dropping to no
	such as in a mute operation. The reaction time between a		load and then resuming a high load, such as in a mute/unmute
	change in the bandwidth available from the algorithm and a		operation. Note that the reaction time between a change in
	change in the offered load is variable, and may be different		the bandwidth available from the algorithm and a change in
	when increasing versus decreasing.		the offered load is variable, and may be different when
			increasing versus decreasing.
	F. The algorithm must not overreact to short-term bursts (such		F. The algorithm requires to avoid building up queues when
	as web-browsing) which can quickly saturate a local-		competing with short-term bursts of traffic (for example,
	bottleneck router or link, but also clear quickly, and		traffic generated by web-browsing) which can quickly
	should recover quickly when the burst ends. This is		saturate a local-bottleneck router or link, but also clear
	inherently at odds with the need to react quickly-enough to		quickly. The algorithm should also attempt to regain its
	avoid queue buildup.		previous share of the bandwidth when the local-bottleneck or
			link is cleared.
	G. Similarly periodic bursty flows such as MPEG DASH		G. Similarly periodic bursty flows such as MPEG DASH
	[MPEG_DASH] or proprietary media streaming algorithms may		[MPEG_DASH] or proprietary media streaming algorithms may
	compete in bursts with the algorithm, and may not be		compete in bursts with the algorithm, and may not be
	adaptive within a burst. They are often layered on top of		adaptive within a burst. They are often layered on top of
	TCP. The algorithm must avoid too much delay buildup during		TCP. Due to non-adaptiveness of the competing traffic as
	those bursts, and quickly recover. Note that this competing		such, the algorithm must not increase the already existing
			delay buildup during those bursts. Note that this competing
	traffic may on a shared access link, or the traffic burst		traffic may on a shared access link, or the traffic burst
	may cause a shift in the location of the bottleneck for the		may cause a shift in the location of the bottleneck for the
	duration of the burst.		duration of the burst.
	2. The algorithm must be fair to other flows, both realtime flows		2. The algorithm must be fair to other flows, both real-time flows
	(such as other instances of itself), and TCP flows, both long-		(such as other instances of itself), and TCP flows, both long-
	lived and bursts such as the traffic generated by a typical web		lived and bursts such as the traffic generated by a typical web
	browsing session. Note that 'fair' is a rather hard-to-define		browsing session. Note that 'fair' is a rather hard-to-define
	term. It should be fair with itself, giving roughly equal		term. It should be fair with itself, giving fair share of the
	bandwidth to multiple flows with similar RTTs, and if possible		bandwidth to multiple flows with similar RTTs, and if possible
	to multiple flows with different RTTs.		to multiple flows with different RTTs.
	A. Existing flows at a bottleneck must also be fair to new		A. Existing flows at a bottleneck must also be fair to new
	flows to that bottleneck, and must allow new flows to ramp		flows to that bottleneck, and must allow new flows to ramp
	up to a useful share of the bottleneck bandwidth quickly.		up to a useful share of the bottleneck bandwidth as quickly
			as possible. A useful share will depend on the media types
	Note that relative RTTs may affect the rate new flows can		involved and total bandwidth available. Note that relative
	ramp up to a reasonable share.		RTTs may affect the rate new flows can ramp up to a
			reasonable share.
	3. The algorithm should not starve competing TCP flows, and should		3. The algorithm should not starve competing TCP flows, and should
	as best as possible avoid starvation by TCP flows.		as best as possible avoid starvation by TCP flows.
	A. An algorithm may be more successful at avoiding starvation		A. The congestion control should prioritise achieving a useful
	from short-lived TCP than long-lived/saturating TCP flows.		share of the bandwidth depending on the media types and
			total available bandwidth over achieving as low as possible
	B. In order to avoid starvation other goals may need to be		transit delay, when these two requirements are in conflict.
	compromised (such as delay).
	4. The algorithm should quickly adapt to initial network conditions
	at the start of a flow. This should occur both if the initial
	bandwidth is above or below the bottleneck bandwidth.
	A. The startup adaptation may be faster than adaptation later
	in a flow. It should allow for both slow-start operation
	(adapt up) and history-based startup (start at a point
	expected to be at or below channel bandwidth from historical
	information, which may need to adapt down quickly if the
	initial guess is wrong). Starting too low and/or adapting
	up too slowly can cause a critical point in a personal
	communication to be poor ("Hello!"). Starting over-
	bandwidth causes other problems for user experience, so
	there's a tension here.
	B. Alternative methods to help startup like probing during		4. The algorithm should as quickly as possible adapt to initial
	setup with dummy data may be useful in some applications; in		network conditions at the start of a flow. This should occur
	some cases there will be a considerable gap in time between		both if the initial bandwidth is above or below the bottleneck
	flow creation and the initial flow of data.		bandwidth.
	C. A flow may need to change adaptation rates due to network		A. The algorithm should allow different modes of adaptation for
	conditions or changes in the provided flows (such as un-		example,the startup adaptation may be faster than adaptation
	muting or sending data after a gap).		later in a flow. It should allow for both slow-start
			operation (adapt up) and history-based startup (start at a
			point expected to be at or below channel bandwidth from
			historical information, which may need to adapt down quickly
			if the initial guess is wrong). Starting too low and/or
			adapting up too slowly can cause a critical point in a
			personal communication to be poor ("Hello!"). Starting
			over-bandwidth causes other problems for user experience, so
			there's a tension here. Alternative methods to help startup
			like probing during setup with dummy data may be useful in
			some applications; in some cases there will be a
			considerable gap in time between flow creation and the
			initial flow of data. Again, A flow may need to change
			adaptation rates due to network conditions or changes in the
			provided flows (such as un-muting or sending data after a
			gap).
	5. It should be stable if the RTP streams are halted or		5. The algorithm should be stable if the RTP streams are halted or
	discontinuous (Voice Activity Detection/Discontinuous		discontinuous (for example - Voice Activity Detection).
	Transmission).
	A. After a resumption of RTP data it may adapt more quickly		A. After stream resumption, the algorithm should attempt to
	(similar to the start of a flow), and previous bandwidth		rapidly regain its previous share of the bandwidth; the
	estimates may need to be aged or thrown away.		aggressiveness with which this is done will decay with the
			length of the pause.
	6. The algorithm should where possible merge information across		6. The algorithm should where possible merge information across
	multiple RTP streams between the same endpoints, whether or not		multiple RTP streams sent between two endpoints, when those RTP
	they're multiplexed on the same ports, in order to allow		streams share a common bottleneck, whether or not those streams
			are multiplexed onto the same ports, in order to allow
	congestion control of the set of streams together instead of as		congestion control of the set of streams together instead of as
	multiple independent streams. This allows better overall		multiple independent streams. This allows better overall
	bandwidth management, faster response to changing conditions,		bandwidth management, faster response to changing conditions,
	and fairer sharing of bandwidth with other network users.		and fairer sharing of bandwidth with other network users.
	Alternatively, it should work with an external bandwidth control
	framework to coordinate bandwidth usage across a bottleneck,
	such as draft-welzl-rmcat-coupled-cc
	[I-D.welzl-rmcat-coupled-cc].
	A. If possible, it should also share information and adaptation		A. The algorithm should also share information and adaptation
	with other non-RTP flows between the same endpoints, such as		with other non-RTP flows between the same endpoints, such as
	a WebRTC DataChannel[I-D.ietf-rtcweb-data-channel]		a WebRTC DataChannel [I-D.ietf-rtcweb-data-channel], when
			possible.
	B. The most correlated bandwidth usage would be with other
	flows on the same 5-tuple, but there may be use in
	coordinating measurement and control of the local link(s).
	C. Use of information about previous flows, especially on the
	same 5-tuple, may be useful input to the algorithm,
	especially to startup performance of a new flow.
	D. When there are multiple streams across the same 5-tuple		B. When there are multiple streams across the same 5-tuple
	coordinating their bandwidth use and congestion control, it		coordinating their bandwidth use and congestion control, the
	should be possible for the application to control the		algorithm should allow the application to control the
	relative split of available bandwidth.		relative split of available bandwidth.The most correlated
			bandwidth usage would be with other flows on the same
			5-tuple, but there may be use in coordinating measurement
			and control of the local link(s). Use of information about
			previous flows, especially on the same 5-tuple, may be
			useful input to the algorithm, especially to startup
			performance of a new flow.
	7. The algorithm should not require any special support from		7. The algorithm should not require any special support from
	network elements (Explicit Congestion Notification (ECN)		network elements to convey congestion related information to be
	[RFC3168], etc). As much as possible, it should leverage		functional. As much as possible, it should leverage available
	available information about the incoming flow to provide		information about the incoming flow to provide feedback to the
	feedback to the sender. Examples of this information are the		sender. Examples of this information are the packet arrival
	ECN, packet arrival times, acknowledgments and feedback, packet		times, acknowledgments and feedback, packet timestamps, and
	timestamps, and packet losses; all of these can provide		packet losses, Explicit Congestion Notification (ECN) [RFC3168];
	information about the state of the path and any bottlenecks.		all of these can provide information about the state of the path
			and any bottlenecks. However, the use of available information
			is algorithm dependent.
	A. Extra information could be added to the packets to provide		A. Extra information could be added to the packets to provide
	more detailed information on actual send times (as opposed		more detailed information on actual send times (as opposed
	to sampling times), but should not be required.		to sampling times), but should not be required.
	B. When additional input signals such as ECN are available,
	they should be utilized if possible.
	8. Since the assumption here is a set of RTP streams, the		8. Since the assumption here is a set of RTP streams, the
	backchannel typically should be done via RTCP; one alternative		backchannel typically should be done via RTCP[RFC3550]; one
	would be to include it instead in a reverse RTP channel using		alternative would be to include it instead in a reverse RTP
	header extensions.		channel using header extensions.
	A. In order to react sufficiently quickly when using RTCP for a		A. In order to react sufficiently quickly when using RTCP for a
	backchannel, an RTP profile such as RTP/AVPF [RFC4585] or		backchannel, an RTP profile such as RTP/AVPF [RFC4585] or
	RTP/SAVPF [RFC5124] that allows sufficiently frequent		RTP/SAVPF [RFC5124] that allows sufficiently frequent
	feedback must be used.		feedback must be used. Note that in some cases, backchannel
			messages may be delayed until the RTCP channel can be
	B. Note that in some cases, backchannel messages may be delayed		allocated enough bandwidth, even under AVPF rules. This may
	until the RTCP channel can be allocated enough bandwidth,		also imply negotiating a higher maximum percentage for RTCP
	even under AVPF rules. This may also imply negotiating a		data or allowing solutions to violate or modify the rules
	higher maximum percentage for RTCP data or allowing RMCAT		specified for AVPF.
	solutions to violate or modify the rules specified for AVPF.
	C. Bandwidth for the feedback messages should be minimized		B. Bandwidth for the feedback messages should be minimized
	(such as via RFC 5506 [RFC5506]to allow RTCP without Sender		(such as via RFC 5506 [RFC5506]to allow RTCP without Sender
	Reports/Receiver Reports)		Reports/Receiver Reports)
	D. Header extensions would avoid the RTCP timing rules issues,		C. Backchannel data should be minimized to avoid taking too
	and allow the application to allocate bandwidth as needed
	for the congestion algorithm.
	E. Backchannel data should be minimized to avoid taking too
	much reverse-channel bandwidth (since this will often be		much reverse-channel bandwidth (since this will often be
	used in a bidirectional set of flows). In areas of		used in a bidirectional set of flows). In areas of
	stability, backchannel data may be sent more infrequently so		stability, backchannel data may be sent more infrequently so
	long as algorithm stability and fairness are maintained.		long as algorithm stability and fairness are maintained.
	When the channel is unstable or has not yet reached		When the channel is unstable or has not yet reached
	equilibrium after a change, backchannel feedback may be more		equilibrium after a change, backchannel feedback may be more
	frequent and use more reverse-channel bandwidth. This is an		frequent and use more reverse-channel bandwidth. This is an
	area with considerable flexibility of design, and different		area with considerable flexibility of design, and different
	approaches to backchannel messages and frequency are		approaches to backchannel messages and frequency are
	expected to be evaluated.		expected to be evaluated.
	skipping to change at page 7, line 44		skipping to change at page 7, line 47
	bottleneck may have different DSCP[RFC5865] markings depending		bottleneck may have different DSCP[RFC5865] markings depending
	on the type of traffic, or may be subject to flow-based QoS. A		on the type of traffic, or may be subject to flow-based QoS. A
	particular bottleneck or section of the network path may or may		particular bottleneck or section of the network path may or may
	not honor DSCP markings. The algorithm should attempt to		not honor DSCP markings. The algorithm should attempt to
	leverage DSCP markings when they're available.		leverage DSCP markings when they're available.
	A. In WebRTC, a division of packets into 4 classes is		A. In WebRTC, a division of packets into 4 classes is
	envisioned in order of priority: faster-than-audio, audio,		envisioned in order of priority: faster-than-audio, audio,
	video, best-effort, and bulk-transfer. Typically the flows		video, best-effort, and bulk-transfer. Typically the flows
	managed by this algorithm would be audio or video in that		managed by this algorithm would be audio or video in that
	heirarchy, and feedback flows would be faster-than-audio.		hierarchy, and feedback flows would be faster-than-audio.
	10. The algorithm should sense the unexpected lack of backchannel		10. The algorithm should sense the unexpected lack of backchannel
	information as a possible indication of a channel overuse		information as a possible indication of a channel overuse
	problem and react accordingly to avoid burst events causing a		problem and react accordingly to avoid burst events causing a
	congestion collapse.		congestion collapse.
	11. The algorithm should be stable and low-delay when faced with		11. The algorithm should be stable and low-delay when faced with
	active queue management (AQM) algorithms. Also note that these		Active Queue Management (AQM) algorithms. Also note that these
	algorithms may apply across multiple queues in the bottleneck,		algorithms may apply across multiple queues in the bottleneck,
	or to a single queue		or to a single queue
	3. IANA Considerations		3. Deficiencies of existing mechanisms
			Among the existing congestion control mechanisms TCP Friendly Rate
			Control (TFRC) [RFC5348] is the one which claims to be suitable for
			real-time interactive media. TFRC is, an equation based, congestion
			control mechanism which provides reasonably fair share of the
			bandwidth when competing with TCP flows and offers much lower
			throughput variations than TCP. This is achieved by a slower
			response to the available bandwidth change than TCP. TFRC is
			designed to perform best with applications which has fixed packet
			size and does not have fixed period between sending packets.
			TFRC operates on detecting loss events and reacts to loss caused by
			congestion by reducing its sending rate. It allows applications to
			increase the sending rate until loss is observed in the flows. As it
			is noted in IAB/IRTF report [RFC7295] large buffers are available in
			the network elements which introduces additional delay in the
			communication, it becomes important to take all possible congestion
			indications into considerations. TFRC's only consideration of loss
			events as congestion indication can be considered as biggest lacking
			looking at the current Internet deployment.
			A typical real-time interactive communication includes live encoded
			audio and video flow(s). In such a communication scenario an audio
			source typically needs fixed interval between packets, needs to vary
			their segment size instead of their packet rate in response to
			congestion and sends smaller packets, a variance of TFRC , Small-
			Packet TFRC (TFRC-SP) [RFC4828] addresses the issues related to such
			kind of sources ; a video source generally varies video frame sizes,
			can produce large frames which need to be further fragmented to fit
			into path Maximum Transmission Unit (MTU) size, and have almost fixed
			interval between producing frames under a certain frame rate, TFRC is
			known to be less optimal when using with such video sources.
			There are also some mismatches between TFRC's design assumptions and
			how the media sources in a typical real-time interactive application
			works. TFRC is design to maintain smooth sending rate however media
			sources can change rates in steps for both rate increase and rate
			decrease. TFRC can operate in two modes - i) Bytes per second and
			ii) packets per second, where typical real-time interactive media
			sources operates on bit per second. There are also limitations on
			how quickly the media sources can adapt to specific sending rates.
			The modern video encoders can operate on a mode where they can vary
			the output bitrate a lot depending on the way there are configured,
			the current scene it is encoding and more. Therefore, it is possible
			that the video source does not always output at a bitrate they are
			allowed to. TFRC tries to raise its sending rate when transmitting
			at maximum allowed rate and increases only twice the current
			transmission rate hence it may create issues when the video source
			vary their bitrates.
			Moreover, there are number of studies on TFRC which shows it's
			limitations which includes TFRC's unfairness on low statistically
			multiplexed links, oscillatory behavior, performance issue in highly
			dynamic loss rates conditions and more [CH09].
			Looking at all these deficiencies it can be concluded that the
			requirements of congestion control mechanism for real-time
			interactive media cannot be met by TFRC as defined in the standard.
			4. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	4. Security Considerations		5. Security Considerations
	An attacker with the ability to delete, delay or insert messages in		An attacker with the ability to delete, delay or insert messages in
	the flow can fake congestion signals, unless they are passed on a		the flow can fake congestion signals, unless they are passed on a
	tamper-proof path. Since some possible algorithms depend on the		tamper-proof path. Since some possible algorithms depend on the
	timing of packet arrival, even a traditional protected channel does		timing of packet arrival, even a traditional protected channel does
	not fully mitigate such attacks.		not fully mitigate such attacks.
	An attack that reduces bandwidth is not necessarily significant,		An attack that reduces bandwidth is not necessarily significant,
	since an on-path attacker could break the connection by discarding		since an on-path attacker could break the connection by discarding
	all packets. Attacks that increase the percieved available bandwidth		all packets. Attacks that increase the percieved available bandwidth
	are concievable, and need to be evaluated.		are concievable, and need to be evaluated.
	Algorithm designers should consider the possibility of malicious on-		Algorithm designers should consider the possibility of malicious on-
	path attackers.		path attackers.
	5. Acknowledgements		6. Acknowledgements
	This document is the result of discussions in various fora of the		This document is the result of discussions in various fora of the
	WebRTC effort, in particular on the rtp-congestion@alvestrand.no		WebRTC effort, in particular on the rtp-congestion@alvestrand.no
	mailing list. Many people contributed their thoughts to this.		mailing list. Many people contributed their thoughts to this.
	6. References		7. References
	6.1. Normative References		7.1. Normative References
	[I-D.ietf-rtcweb-overview]		[I-D.ietf-rtcweb-overview]
	Alvestrand, H., "Overview: Real Time Protocols for		Alvestrand, H., "Overview: Real Time Protocols for
	Browser-based Applications", draft-ietf-rtcweb-overview-11		Browser-based Applications", draft-ietf-rtcweb-overview-12
	(work in progress), August 2014.		(work in progress), October 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
			Jacobson, "RTP: A Transport Protocol for Real-Time
			Applications", STD 64, RFC 3550, July 2003.
	[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,		[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
	"Extended RTP Profile for Real-time Transport Control		"Extended RTP Profile for Real-time Transport Control
	Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
	2006.		2006.
	[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for		[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
	Real-time Transport Control Protocol (RTCP)-Based Feedback		Real-time Transport Control Protocol (RTCP)-Based Feedback
	(RTP/SAVPF)", RFC 5124, February 2008.		(RTP/SAVPF)", RFC 5124, February 2008.
	6.2. Informative References		7.2. Informative References
			[CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window-
			based Congestion Control for Real-time Multimedia
			Applications", PFLDNeT 2009 Workshop , May 2009.
	[I-D.ietf-rtcweb-data-channel]		[I-D.ietf-rtcweb-data-channel]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
	Channels", draft-ietf-rtcweb-data-channel-12 (work in		Channels", draft-ietf-rtcweb-data-channel-12 (work in
	progress), September 2014.		progress), September 2014.
	[I-D.welzl-rmcat-coupled-cc]
	Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion
	control for RTP media", draft-welzl-rmcat-coupled-cc-03
	(work in progress), May 2014.
	[MPEG_DASH]		[MPEG_DASH]
	"Dynamic adaptive streaming over HTTP (DASH) -- Part 1:		"Dynamic adaptive streaming over HTTP (DASH) -- Part 1:
	Media presentation description and segment formats", April		Media presentation description and segment formats", April
	2012.		2012.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP", RFC		of Explicit Congestion Notification (ECN) to IP", RFC
	3168, September 2001.		3168, September 2001.
			[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
			(TFRC): The Small-Packet (SP) Variant", RFC 4828, April
			2007.
			[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
			Friendly Rate Control (TFRC): Protocol Specification", RFC
			5348, September 2008.
	[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size		[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
	Real-Time Transport Control Protocol (RTCP): Opportunities		Real-Time Transport Control Protocol (RTCP): Opportunities
	and Consequences", RFC 5506, April 2009.		and Consequences", RFC 5506, April 2009.
	[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated		[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
	Services Code Point (DSCP) for Capacity-Admitted Traffic",		Services Code Point (DSCP) for Capacity-Admitted Traffic",
	RFC 5865, May 2010.		RFC 5865, May 2010.
	Author's Address		[RFC7295] Tschofenig, H., Eggert, L., and Z. Sarker, "Report from
			the IAB/IRTF Workshop on Congestion Control for
			Interactive Real-Time Communication", RFC 7295, July 2014.
			Authors' Addresses
	Randell Jesup		Randell Jesup
	Mozilla		Mozilla
	USA		USA
	Email: randell-ietf@jesup.org		Email: randell-ietf@jesup.org
			Zaheduzzaman Sarker (editor)
			Ericsson
			Sweden
			Email: zaheduzzaman.sarker@ericsson.com
End of changes. 51 change blocks.
	160 lines changed or deleted		235 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/