draft-ietf-rmcat-scream-cc-05.txt		draft-ietf-rmcat-scream-cc-06.txt
	RMCAT WG I. Johansson		RMCAT WG I. Johansson
	Internet-Draft Z. Sarker		Internet-Draft Z. Sarker
	Intended status: Experimental Ericsson AB		Intended status: Experimental Ericsson AB
	Expires: December 29, 2016 June 27, 2016		Expires: February 16, 2017 August 15, 2016
	Self-Clocked Rate Adaptation for Multimedia		Self-Clocked Rate Adaptation for Multimedia
	draft-ietf-rmcat-scream-cc-05		draft-ietf-rmcat-scream-cc-06
	Abstract		Abstract
	This memo describes a rate adaptation algorithm for conversational		This memo describes a rate adaptation algorithm for conversational
	media services such as video. The solution conforms to the packet		media services such as video. The solution conforms to the packet
	conservation principle and uses a hybrid loss and delay based		conservation principle and uses a hybrid loss and delay based
	congestion control algorithm. The algorithm is evaluated over both		congestion control algorithm. The algorithm is evaluated over both
	simulated Internet bottleneck scenarios as well as in a LTE (Long		simulated Internet bottleneck scenarios as well as in a LTE (Long
	Term Evolution) system simulator and is shown to achieve both low		Term Evolution) system simulator and is shown to achieve both low
	latency and high video throughput in these scenarios.		latency and high video throughput in these scenarios.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 December 29, 2016.		This Internet-Draft will expire on February 16, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	4.1.1. Constants and Parameter values . . . . . . . . . . . 9		4.1.1. Constants and Parameter values . . . . . . . . . . . 9
	4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9		4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9
	4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10		4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10
	4.1.2. Network congestion control . . . . . . . . . . . . . 12		4.1.2. Network congestion control . . . . . . . . . . . . . 12
	4.1.2.1. Congestion window update . . . . . . . . . . . . 15		4.1.2.1. Congestion window update . . . . . . . . . . . . 15
	4.1.2.2. Competing flows compensation . . . . . . . . . . 17		4.1.2.2. Competing flows compensation . . . . . . . . . . 17
	4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19		4.1.2.3. Lost packets detection . . . . . . . . . . . . . 19
	4.1.2.4. Send window calculation . . . . . . . . . . . . . 19		4.1.2.4. Send window calculation . . . . . . . . . . . . . 19
	4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20		4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 20
	4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20		4.1.3. Media rate control . . . . . . . . . . . . . . . . . 20
	4.1.3.1. FEC and packet overhead considerations . . . . . 24		4.1.3.1. FEC and packet overhead considerations . . . . . 23
	4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24		4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 24
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 24
	6. Implementation status . . . . . . . . . . . . . . . . . . . . 25		6. Implementation status . . . . . . . . . . . . . . . . . . . . 24
	6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25		6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 25
	6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 26		6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 25
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 26
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	10. Change history . . . . . . . . . . . . . . . . . . . . . . . 27		10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		11. Change history . . . . . . . . . . . . . . . . . . . . . . . 27
	11.1. Normative References . . . . . . . . . . . . . . . . . . 28		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	11.2. Informative References . . . . . . . . . . . . . . . . . 28		12.1. Normative References . . . . . . . . . . . . . . . . . . 28
			12.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Additional information . . . . . . . . . . . . . . . 30		Appendix A. Additional information . . . . . . . . . . . . . . . 30
	A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30		A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 30
	A.2. Computation of autocorrelation function . . . . . . . . . 31		A.2. Computation of autocorrelation function . . . . . . . . . 31
	A.3. Sender transmission control and packet pacing . . . . . . 31		A.3. Sender transmission control and packet pacing . . . . . . 31
	A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31		A.4. RTCP feedback considerations . . . . . . . . . . . . . . 31
	A.4.1. Requirements on feedback elements . . . . . . . . . . 31		A.4.1. Requirements on feedback elements . . . . . . . . . . 32
	A.4.2. Requirements on feedback intensity . . . . . . . . . 33		A.4.2. Requirements on feedback intensity . . . . . . . . . 34
	A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34		A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	Congestion in the Internet occurs when the transmitted bitrate is		Congestion in the Internet occurs when the transmitted bitrate is
	higher than the available bandwidth over a given transmission path.		higher than the available bandwidth over a given transmission path.
	Applications that are deployed in the Internet must have congestion		Applications that are deployed in the Internet must have congestion
	control schemes in place not only for the robustness of the service		control schemes in place not only for the robustness of the service
	that it provides but also to ensure the function of the currently		that it provides but also to ensure the function of the currently
	skipping to change at page 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	update_cwnd(bytes_newly_acked):		update_cwnd(bytes_newly_acked):
	# in fast increase ?		# in fast increase ?
	if (in_fast_increase)		if (in_fast_increase)
	if (qdelay_trend >= 0.2)		if (qdelay_trend >= 0.2)
	# incipient congestion detected, exit fast increase		# incipient congestion detected, exit fast increase
	in_fast_increase = false		in_fast_increase = false
	else		else
	# no congestion yet, increase cwnd if it		# no congestion yet, increase cwnd if it
	# is sufficiently used		# is sufficiently used
	if (bytes_in_flight*1.5 > cwnd)		# an additional slack of bytes_newly_acked is
			# added to ensure that CWND growth occurs
			# even when feedback is sparse
			if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)
	cwnd = cwnd+bytes_newly_acked		cwnd = cwnd+bytes_newly_acked
	end		end
	return		return
	end		end
	end		end
	# not in fast increase phase		# not in fast increase phase
	# off_target calculated as with LEDBAT		# off_target calculated as with LEDBAT
	off_target_t = (qdelay_target - qdelay) / qdelay_target		off_target_t = (qdelay_target - qdelay) / qdelay_target
	gain_t = GAIN		gain_t = GAIN
	# adjust congestion window		# adjust congestion window
	cwnd_delta_t =		cwnd_delta_t =
	gain_t * off_target_t * bytes_newly_acked * MSS / cwnd		gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
	if (off_target_t > 0 && bytes_in_flight*1.25 <= cwnd)		if (off_target_t > 0 && bytes_in_flight*1.25+bytes_newly_acked <= cwnd)
	# no cwnd increase if window is underutilized		# no cwnd increase if window is underutilized
			# an additional slack of bytes_newly_acked is
			# added to ensure that CWND growth occurs
			# even when feedback is sparse
	cwnd_delta_t = 0;		cwnd_delta_t = 0;
	end		end
	# apply delta		# apply delta
	cwnd += cwnd_delta_t		cwnd += cwnd_delta_t
	# limit cwnd to the maximum number of bytes in flight		# limit cwnd to the maximum number of bytes in flight
	cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)		cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
	cwnd = max(cwnd, MIN_CWND)		cwnd = max(cwnd, MIN_CWND)
	CWND is updated differently depending on whether the congestion		CWND is updated differently depending on whether the congestion
	control is in fast increase state or not, as controlled by the		control is in fast increase state or not, as controlled by the
	variable in_fast_increase.		variable in_fast_increase.
	When in fast increase state, the congestion window is increased with		When in fast increase state, the congestion window is increased with
	the number of newly acknowledged bytes as long as the window is		the number of newly acknowledged bytes as long as the window is
	sufficiently used.		sufficiently used. Sparse feedback can potentially limit congestion
			window growth, an additional slack is therefore added, given by the
			number of newly acked bytes.
	The congestion window growth when in_fast_increase is false is		The congestion window growth when in_fast_increase is false is
	dictated by the relation between qdelay and qdelay_target, congestion		dictated by the relation between qdelay and qdelay_target, congestion
	window growth is limited if the window is not used sufficiently.		window growth is limited if the window is not used sufficiently.
	SCReAM calculates the GAIN in a similar way to what is specified in		SCReAM calculates the GAIN in a similar way to what is specified in
	[RFC6817]. There are however a few differences.		[RFC6817]. There are however a few differences.
	o [RFC6817] specifies a constant GAIN, this specification however		o [RFC6817] specifies a constant GAIN, this specification however
	limits the gain when CWND is increased dependent on near		limits the gain when CWND is increased dependent on near
	skipping to change at page 18, line 51 ¶		skipping to change at page 18, line 51 ¶
	The qdelay_target is adjusted differently, depending on if		The qdelay_target is adjusted differently, depending on if
	qdelay_norm_var_t is above or below a given value.		qdelay_norm_var_t is above or below a given value.
	A low qdelay_norm_avg_t value indicates that the qdelay does not		A low qdelay_norm_avg_t value indicates that the qdelay does not
	change rapidly. It is desired avoid the case that the qdelay target		change rapidly. It is desired avoid the case that the qdelay target
	is increased due to self-congestion, indicated by a changing qdelay		is increased due to self-congestion, indicated by a changing qdelay
	and consequently an increased qdelay_norm_var_t. Still it should be		and consequently an increased qdelay_norm_var_t. Still it should be
	possible to increase the qdelay target if the qdelay continues to be		possible to increase the qdelay target if the qdelay continues to be
	high. This is a simple function with a certain risk of both false		high. This is a simple function with a certain risk of both false
	positives and negatives but it manages competing FTP flows reasonably		positives and negatives but it manages competing FTP flows reasonably
	well at the same time as it has proven to avoid accidental increased		well at the same time as it has proven to avoid accidental increased
	qdelay target relatively well in simulated LTE test cases.		qdelay target relatively well in simulated LTE test cases. The
			algorithm can however accidentally increase the qdelay target and
			cause self-inflicted congestion in certain cases, therefore it is
			recommended to turn off the algorithm if is unlikely that competing
			flows will occur over the same bottleneck.
	4.1.2.3. Lost packets detection		4.1.2.3. Lost packets detection
	Lost packets detection is based on the received sequence number list.		Lost packets detection is based on the received sequence number list.
	A reordering window should be applied to avoid that packet reordering		A reordering window should be applied to avoid that packet reordering
	triggers loss events.		triggers loss events.
	The reordering window is specified as a time unit, similar to the		The reordering window is specified as a time unit, similar to the
	ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation		ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation
	of the reordering window is made possible by means of a lost flag in		of the reordering window is made possible by means of a lost flag in
	the list of transmitted RTP packets. This flag is set if the		the list of transmitted RTP packets. This flag is set if the
	skipping to change at page 21, line 27 ¶		skipping to change at page 21, line 30 ¶
	The current throughput, current_rate, is computed as the maximum		The current throughput, current_rate, is computed as the maximum
	value of rate_transmit and rate_ack. The rationale behind the use of		value of rate_transmit and rate_ack. The rationale behind the use of
	rate_ack in addition to rate_transmit is that rate_transmit is		rate_ack in addition to rate_transmit is that rate_transmit is
	affected also by the amount of data that is available to transmit,		affected also by the amount of data that is available to transmit,
	thus a lack of data to transmit can be seen as reduced throughput		thus a lack of data to transmit can be seen as reduced throughput
	that may itself cause an unnecessary rate reduction. To overcome		that may itself cause an unnecessary rate reduction. To overcome
	this shortcoming; rate_ack is used as well. This gives a more stable		this shortcoming; rate_ack is used as well. This gives a more stable
	throughput estimate.		throughput estimate.
	The rate change behavior depends on whether a loss event has occurred		The rate change behavior depends on whether a loss or ECN event has
	and if the congestion control is in fast increase or not.		occurred and if the congestion control is in fast increase or not.
	# The target_bitrate is updated at a regular interval according		# The target_bitrate is updated at a regular interval according
	# to RATE_ADJUST_INTERVAL		# to RATE_ADJUST_INTERVAL
	on loss:		on loss:
			# Loss event detected
	target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)		target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN)
	exit		exit
			on ecn_mark:
			# ECN event detected
			target_bitrate = max(BETA_ECN* target_bitrate, TARGET_BITRATE_MIN)
			exit
	ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0)		ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0)
	scale_t = (target_bitrate - target_bitrate_last_max)/		scale_t = (target_bitrate - target_bitrate_last_max)/
	target_bitrate_last_max		target_bitrate_last_max
	scale_t = max(0.2, min(1.0, (scale_t*4)^2))		scale_t = max(0.2, min(1.0, (scale_t*4)^2))
	# min scale_t value 0.2 as the bitrate should be allowed to		# min scale_t value 0.2 as the bitrate should be allowed to
	# increase at least slowly --> avoid locking the rate to		# increase at least slowly --> avoid locking the rate to
	# target_bitrate_last_max		# target_bitrate_last_max
	if (in_fast_increase = true)		if (in_fast_increase = true)
	increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL		increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
	skipping to change at page 23, line 6 ¶		skipping to change at page 22, line 39 ¶
	rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem)		rate_media_limit_t *= (2.0-1.0*qdelay_trend_mem)
	target_bitrate = min(target_bitrate, rate_media_limit_t)		target_bitrate = min(target_bitrate, rate_media_limit_t)
	target_bitrate = min(TARGET_BITRATE_MAX,		target_bitrate = min(TARGET_BITRATE_MAX,
	max(TARGET_BITRATE_MIN,target_bitrate))		max(TARGET_BITRATE_MIN,target_bitrate))
	In case of a loss event the target_bitrate is updated and the rate		In case of a loss event the target_bitrate is updated and the rate
	change procedure is exited. Otherwise the rate change procedure		change procedure is exited. Otherwise the rate change procedure
	continues. The rationale behind the rate reduction due to loss is		continues. The rationale behind the rate reduction due to loss is
	that a congestion window reduction will take effect, a rate reduction		that a congestion window reduction will take effect, a rate reduction
	pro actively avoids that RTP packets are queued up when the transmit		pro actively avoids that RTP packets are queued up when the transmit
	rate decreases due to the reduced congestion window. An ECN event		rate decreases due to the reduced congestion window. A similar rate
	does not cause any action, the reason to this is that the congestion		reduction happens when ECN events are detected.
	window is reduced less due to ECN events than loss events, the effect
	is thus that the expected additional RTP queuing delay due to ECN
	events is so small that an additional decrease in media rate is not
	warranted.
	The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless		The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless
	a loss event occurs. The value is based on experimentation with real		a loss event occurs. The value is based on experimentation with real
	life limitations in video coders taken into account. A too short		life limitations in video coders taken into account. A too short
	interval has shown to make the video coder internal rate control loop		interval has shown to make the video coder internal rate control loop
	more unstable, a too long interval makes the overall congestion		more unstable, a too long interval makes the overall congestion
	control sluggish.		control sluggish.
	When in fast increase state (in_fast_increase=true), the bitrate		When in fast increase state (in_fast_increase=true), the bitrate
	increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The		increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The
	skipping to change at page 26, line 21 ¶		skipping to change at page 25, line 48 ¶
	o Contact : irc://chat.freenode.net/openwebrtc		o Contact : irc://chat.freenode.net/openwebrtc
	6.2. A C++ Implementation of SCReAM		6.2. A C++ Implementation of SCReAM
	o Organization : Ericsson Research, Ericsson.		o Organization : Ericsson Research, Ericsson.
	o Name : SCReAM.		o Name : SCReAM.
	o Implementation link : A C++ implementation of SCReAM is also		o Implementation link : A C++ implementation of SCReAM is also
	available [SCReAM-Cplusplus_Implementation]The code includes full		available [SCReAM-Cplusplus_Implementation]. The code includes
	support for congestion control, rate control and multi stream		full support for congestion control, rate control and multi stream
	handling, it can be integrated in web clients given the addition		handling, it can be integrated in web clients given the addition
	of extra code to implement the RTCP feedback and RTP queue(s).		of extra code to implement the RTCP feedback and RTP queue(s).
	The code also includes a rudimentary implementation of a
	simulator.		The code also includes a rudimentary implementation of a simulator
			that allows for some initial experiments.
	o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]		o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]
	o Contact : ingemar.s.johansson@ericsson.com		o Contact : ingemar.s.johansson@ericsson.com
	7. Acknowledgements		7. Suggested experiments
			SCReAM has been evaluated in a number of different ways, most of the
			evaluation has been in simulator. The OpenWebRTC implementation work
			involved extensive testing with artificial bottlenecks with varying
			bandwidths and using two different video coders (OpenH264 and VP9),
			the experience of this lead to further improvements of the media rate
			control logic.
			Further experiments are preferably done by means of implementation in
			real clients and web browsers. Recommended experiments are:
			o Trials with various access technologies: EDGE/3G/4G, WiFi, DSL.
			o Trials with different kinds of media: Audio, Video, slide show
			content. Evaluation of multi stream handling in SCReAM.
			o Evaluation of functionality of competing flows compensation
			mechanism: Evaluate how SCReAM performs with competing TCP like
			traffic and to what extent the competing flows compensation causes
			self-inflicted congestion.
			o Determine proper parameters: A set of default parameters are given
			that makes SCReAM work over a reasonably large operation range,
			however for instance for very low or very high bitrates it may be
			necessary to use different values for instance for RAMP_UP_SPEED.
			8. Acknowledgements
	We would like to thank the following persons for their comments,		We would like to thank the following persons for their comments,
	questions and support during the work that led to this memo: Markus		questions and support during the work that led to this memo: Markus
	Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,		Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
	Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,		Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
	Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard		Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
	Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many		Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many
	additional thanks to RMCAT chairs Karen and Mirja for patiently		additional thanks to RMCAT chairs Karen and Mirja for patiently
	reading, suggesting improvements and also for asking all the		reading, suggesting improvements and also for asking all the
	difficult but necessary questions. Thanks to Stefan Holmer and		difficult but necessary questions. Thanks to Stefan Holmer and
	Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time		Xiaoqing Zhu for the review. Thanks to Ralf Globisch for taking time
	to try out SCReAM in his challenging low bitrate use cases.		to try out SCReAM in his challenging low bitrate use cases.
	8. IANA Considerations		9. IANA Considerations
	A new RFC4585 transport layer feedback message needs to be		A new RFC4585 transport layer feedback message needs to be
	standardized.		standardized.
	9. Security Considerations		10. Security Considerations
	The feedback can be vulnerable to attacks similar to those that can		The feedback can be vulnerable to attacks similar to those that can
	affect TCP. It is therefore recommended that the RTCP feedback is at		affect TCP. It is therefore recommended that the RTCP feedback is at
	least integrity protected. Furthermore, as SCReAM is self-clocked, a		least integrity protected. Furthermore, as SCReAM is self-clocked, a
	malicious middlebox can drop RTCP feedback packets and thus cause the		malicious middlebox can drop RTCP feedback packets and thus cause the
	self-clocking in SCReAM to stall.		self-clocking in SCReAM to stall.
	10. Change history		11. Change history
	A list of changes:		A list of changes:
			o WG-05 to WG-06: Added list of suggested experiments
	o WG-04 to WG-05: Congestion control and rate control simplified		o WG-04 to WG-05: Congestion control and rate control simplified
	somewhat		somewhat
	o WG-03 to WG-04: Editorial fixes		o WG-03 to WG-04: Editorial fixes
	o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing		o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing
	Zhu addressed, owd changed to qdelay for clarity. Added appendix		Zhu addressed, owd changed to qdelay for clarity. Added appendix
	section with RTCP feedback requirements, including a suggested		section with RTCP feedback requirements, including a suggested
	basic feedback format based Loss RLE report block and the Packet		basic feedback format based Loss RLE report block and the Packet
	Receipt Times blocks in [RFC3611]. Loss detection added as a		Receipt Times blocks in [RFC3611]. Loss detection added as a
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 12 ¶
	o -03 to -04 : Extensive changes due to review comments, code		o -03 to -04 : Extensive changes due to review comments, code
	somewhat modified, frame skipping made optional		somewhat modified, frame skipping made optional
	o -02 to -03 : Added algorithm description with equations, removed		o -02 to -03 : Added algorithm description with equations, removed
	pseudo code and simulation results		pseudo code and simulation results
	o -01 to -02 : Updated GCC simulation results		o -01 to -02 : Updated GCC simulation results
	o -00 to -01 : Fixed a few bugs in example code		o -00 to -01 : Fixed a few bugs in example code
	11. References		12. References
	11.1. Normative References		12.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	skipping to change at page 28, line 40 ¶		skipping to change at page 28, line 47 ¶
	[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,		[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
	"Computing TCP's Retransmission Timer", RFC 6298,		"Computing TCP's Retransmission Timer", RFC 6298,
	DOI 10.17487/RFC6298, June 2011,		DOI 10.17487/RFC6298, June 2011,
	<http://www.rfc-editor.org/info/rfc6298>.		<http://www.rfc-editor.org/info/rfc6298>.
	[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,		[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
	"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,		"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
	DOI 10.17487/RFC6817, December 2012,		DOI 10.17487/RFC6817, December 2012,
	<http://www.rfc-editor.org/info/rfc6817>.		<http://www.rfc-editor.org/info/rfc6817>.
	11.2. Informative References		12.2. Informative References
	[I-D.ietf-rmcat-app-interaction]		[I-D.ietf-rmcat-app-interaction]
	Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP		Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
	Application Interaction with Congestion Control", draft-		Application Interaction with Congestion Control", draft-
	ietf-rmcat-app-interaction-01 (work in progress), October		ietf-rmcat-app-interaction-01 (work in progress), October
	2014.		2014.
	[I-D.ietf-rmcat-cc-codec-interactions]		[I-D.ietf-rmcat-cc-codec-interactions]
	Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,		Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
	"Congestion Control and Codec interactions in RTP		"Congestion Control and Codec interactions in RTP
	Applications", draft-ietf-rmcat-cc-codec-interactions-02		Applications", draft-ietf-rmcat-cc-codec-interactions-02
	(work in progress), March 2016.		(work in progress), March 2016.
	[I-D.ietf-rmcat-coupled-cc]		[I-D.ietf-rmcat-coupled-cc]
	Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion		Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
	control for RTP media", draft-ietf-rmcat-coupled-cc-02		control for RTP media", draft-ietf-rmcat-coupled-cc-03
	(work in progress), April 2016.		(work in progress), July 2016.
	[I-D.ietf-rmcat-scream-cc]		[I-D.ietf-rmcat-scream-cc]
	Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation		Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
	for Multimedia", draft-ietf-rmcat-scream-cc-04 (work in		for Multimedia", draft-ietf-rmcat-scream-cc-05 (work in
	progress), June 2016.		progress), June 2016.
	[I-D.ietf-rmcat-wireless-tests]		[I-D.ietf-rmcat-wireless-tests]
	Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and		Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
	M. Ramalho, "Evaluation Test Cases for Interactive Real-		D. Ramalho, "Evaluation Test Cases for Interactive Real-
	Time Media over Wireless Networks", draft-ietf-rmcat-		Time Media over Wireless Networks", draft-ietf-rmcat-
	wireless-tests-02 (work in progress), May 2016.		wireless-tests-02 (work in progress), May 2016.
	[Khademi_alternative_backoff_ECN]		[Khademi_alternative_backoff_ECN]
	"TCP Alternative Backoff with ECN (ABE)",		"TCP Alternative Backoff with ECN (ABE)",
	<https://tools.ietf.org/html/draft-khademi-		<https://tools.ietf.org/html/draft-khademi-
	alternativebackoff-ecn-00>.		alternativebackoff-ecn-00>.
	[OpenWebRTC]		[OpenWebRTC]
	"Open WebRTC project.", <http://www.openwebrtc.io/>.		"Open WebRTC project.", <http://www.openwebrtc.io/>.
	skipping to change at page 33, line 27 ¶		skipping to change at page 34, line 9 ¶
	[RFC6679]. The given feedback report format is actually a slight		[RFC6679]. The given feedback report format is actually a slight
	overkill as SCReAM would do quite well with only a counter that		overkill as SCReAM would do quite well with only a counter that
	increments by one for each received packet with the ECE-CE code		increments by one for each received packet with the ECE-CE code
	point set. The more bulky format may be nevertheless be useful		point set. The more bulky format may be nevertheless be useful
	for e.g ECN black-hole detection.		for e.g ECN black-hole detection.
	o Source quench bit (Q): Makes it possible to request the sender to		o Source quench bit (Q): Makes it possible to request the sender to
	reduce its congestion window. This is useful if WebRTC media is		reduce its congestion window. This is useful if WebRTC media is
	received from many hosts and it becomes necessary to balance the		received from many hosts and it becomes necessary to balance the
	bitrates between the streams. This can currently not be realized		bitrates between the streams. This can currently not be realized
	with any standardized feedback format.		with any standardized feedback format, however the ECN counter can
			be artificially incremented, even though no ECN-CE marked packets
			are received to achieve a similar behavior.
	A.4.2. Requirements on feedback intensity		A.4.2. Requirements on feedback intensity
	SCReAM benefits from a relatively frequent feedback. Experiments		SCReAM benefits from a relatively frequent feedback. The feedback
	have shown that a feedback rate roughly equal to the frame rate gives		interval depends on the media bitrate. At low bitrates it is
	a stable self-clocking and robustness against loss of feedback. With		sufficient with a feedback interval of 100 to 200ms, while at high
	a maximum bitrate of 1500kbps the RTCP feedback overhead is in the		bitrates a feedback interval of ~20ms is to prefer.
	range 10-15kbps with reduced size RTCP [RFC5506], including IP and
	UDP framing and a reasonable compact RTCP feedback format. In other
	words the RTCP overhead is quite modest and should not pose a problem
	in the general case. Worth notice is that SCReAM can work with as
	low feedback rates as once every 200ms at low media rates (e.g
	50kbps) , a low feedback rate when media rate is high comes at the
	cost of a higher sensitivity to loss of feedback and also a potential
	reduction in throughput due to degraded ACK-clocking performance.
	SCReAM works with AVPF regular mode, immediate or early mode is not
	required by SCReAM but may nonetheless be useful for e.g RTCP
	messages not directly related to SCReAM, such as those specified in
	[RFC4585]. It is recommended to use reduced size RTCP [RFC5506]where
	regular full compound RTCP transmission is controlled by trr-int as
	described in [RFC4585].
	The feedback interval depends on the media bitrate. At low bitrates
	it is sufficient with a feedback interval of 100 to 200ms, while at
	high bitrates a feedback interval of ~20ms is to prefer.
	This leads to a feedback rate according to the following equation:		The numbers above can be formulated as feedback interval function
			that can be useful for the computation of the desired RTCP bandwidth.
			The following equation expresses the feedback rate:
	rate_fb = min(50,max(10,rate_media/20000))		rate_fb = min(50,max(5,rate_media/10000))
	rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is		rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is
	the feedback rate expressed in [packets/s]. Converted to feedback		the feedback rate expressed in [packets/s]. Converted to feedback
	interval we get:		interval we get:
	fb_int = 1.0/min(50,max(10,rate_media/20000))		fb_int = 1.0/min(50,max(5,rate_media/10000))
	The transmission interval is not critical, this means that in the		The transmission interval is not critical, this means that in the
	case of multi-stream handling between two hosts, the feedback for two		case of multi-stream handling between two hosts, the feedback for two
	or more SSRCs can be bundled to save UDP/IP overhead, the final		or more SSRCs can be bundled to save UDP/IP overhead, the final
	realized feedback interval should however not exceed 2*fb_int in such		realized feedback interval should however not exceed 2*fb_int in such
	cases meaning that a scheduled feedback transmission event should not		cases meaning that a scheduled feedback transmission event should not
	be delayed more that fb_int.		be delayed more that fb_int.
			SCReAM works with AVPF regular mode, immediate or early mode is not
			required by SCReAM but may nonetheless be useful for e.g RTCP
			messages not directly related to SCReAM, such as those specified in
			[RFC4585]. It is recommended to use reduced size RTCP [RFC5506]
			where regular full compound RTCP transmission is controlled by trr-
			int as described in [RFC4585].
	A.5. Q-bit semantics (source quench)		A.5. Q-bit semantics (source quench)
	The Q bit in the feedback is set by a receiver to signal that the		The Q bit in the feedback is set by a receiver to signal that the
	sender should reduce the bitrate. The sender will in response to		sender should reduce the bitrate. The sender will in response to
	this reduce the congestion window with the consequence that the video		this reduce the congestion window with the consequence that the video
	bitrate decreases. A typical use case for source quench is when a		bitrate decreases. A typical use case for source quench is when a
	receiver receives streams from sources located at different hosts and		receiver receives streams from sources located at different hosts and
	they all share a common bottleneck, typically it is difficult to		they all share a common bottleneck, typically it is difficult to
	apply any rate distribution signaling between the sending hosts. The		apply any rate distribution signaling between the sending hosts. The
	solution is then that the receiver sets the Q bit in the feedback to		solution is then that the receiver sets the Q bit in the feedback to
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 23 ¶
	This is ensured by the opportunistic behavior of SCReAM's congestion		This is ensured by the opportunistic behavior of SCReAM's congestion
	control. The source quench will have no or little effect if the		control. The source quench will have no or little effect if the
	flows do not share the same bottleneck.		flows do not share the same bottleneck.
	The reduction in congestion window is proportional to the amount of		The reduction in congestion window is proportional to the amount of
	SCReAM RTCP feedback with the Q bit set, the below steps outline how		SCReAM RTCP feedback with the Q bit set, the below steps outline how
	the sender should react to RTCP feedback with the Q bit set. The		the sender should react to RTCP feedback with the Q bit set. The
	reduction is done once per RTT. Let :		reduction is done once per RTT. Let :
	o n = Number of received RTCP feedback messages in one RTT		o n = Number of received RTCP feedback messages in one RTT
	o n_q = Number of received RTCP feedback messages in one RTT, with Q		o n_q = Number of received RTCP feedback messages in one RTT, with Q
	bit set.		bit set.
	The new congestion window is then expressed as:		The new congestion window is then expressed as:
	cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n))		cwnd = max(MIN_CWND, cwnd*(1.0-0.5*n_q/n))
	Note that CWND is adjusted at most once per RTT. Furthermore The		Note that CWND is adjusted at most once per RTT. Furthermore The
	CWND increase should be inhibited for one RTT if CWND has been		CWND increase should be inhibited for one RTT if CWND has been
	decreased as a result of Q bits set in the feedback.		decreased as a result of Q bits set in the feedback.
	The required intensity of the Q-bit set in the feedback in order to		The required intensity of the Q-bit set in the feedback in order to
	achieve a given rate distribution depends on many factors such as		achieve a given rate distribution depends on many factors such as
	RTT, video source material etc. The receiver thus need to monitor		RTT, video source material etc. The receiver thus need to monitor
	the change in the received video bitrate on the different streams and		the change in the received video bitrate on the different streams and
	adjust the intensity of the Q-bit accordingly.		adjust the intensity of the Q-bit accordingly.
End of changes. 37 change blocks.
	70 lines changed or deleted		107 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/