draft-ietf-rmcat-scream-cc-10.txt		draft-ietf-rmcat-scream-cc-11.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: January 19, 2018 July 18, 2017		Expires: April 12, 2018 October 9, 2017
	Self-Clocked Rate Adaptation for Multimedia		Self-Clocked Rate Adaptation for Multimedia
	draft-ietf-rmcat-scream-cc-10		draft-ietf-rmcat-scream-cc-11
	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 Long Term		simulated Internet bottleneck scenarios as well as in a Long Term
	Evolution (LTE) system simulator and is shown to achieve both low		Evolution (LTE) 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.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 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 January 19, 2018.		This Internet-Draft will expire on April 12, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4		3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
	3.1. Network Congestion Control . . . . . . . . . . . . . . . 7		3.1. Network Congestion Control . . . . . . . . . . . . . . . 7
	3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8		3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8
	3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8		3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8
	4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9		4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9
	4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9		4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . 11		4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11
	4.1.2. Network congestion control . . . . . . . . . . . . . 13		4.1.2. Network congestion control . . . . . . . . . . . . . 13
	4.1.2.1. Congestion window update . . . . . . . . . . . . 16		4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 15
	4.1.2.2. Competing flows compensation . . . . . . . . . . 18		4.1.2.2. Congestion window update . . . . . . . . . . . . 16
	4.1.2.3. Lost packet detection . . . . . . . . . . . . . . 20		4.1.2.3. Competing flows compensation . . . . . . . . . . 18
	4.1.2.4. Send window calculation . . . . . . . . . . . . . 20		4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 20
	4.1.2.5. Packet pacing . . . . . . . . . . . . . . . . . . 21		4.1.2.5. Send window calculation . . . . . . . . . . . . . 20
	4.1.2.6. Resuming fast increase . . . . . . . . . . . . . 21		4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 21
			4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 22
			4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 22
	4.1.3. Media rate control . . . . . . . . . . . . . . . . . 22		4.1.3. Media rate control . . . . . . . . . . . . . . . . . 22
	4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25		4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25
	4.2.1. Requirements on feedback elements . . . . . . . . . . 25		4.2.1. Requirements on feedback elements . . . . . . . . . . 25
	4.2.2. Requirements on feedback intensity . . . . . . . . . 27		4.2.2. Requirements on feedback intensity . . . . . . . . . 27
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28
	6. Implementation status . . . . . . . . . . . . . . . . . . . . 28		6. Implementation status . . . . . . . . . . . . . . . . . . . . 29
	6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29		6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29
	6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 29		6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 30
	7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30		7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 31		10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31		11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.1. Normative References . . . . . . . . . . . . . . . . . . 33
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Additional information . . . . . . . . . . . . . . . 34
	A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 34
	A.2. Computation of autocorrelation function . . . . . . . . . 35
	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 capacity over a given transmission path.		higher than the available capacity over a given transmission path.
	Applications that are deployed in the Internet MUST employ congestion		Applications that are deployed in the Internet have to employ
	control, to achieve robust performance and to avoid congestion		congestion control, to achieve robust performance and to avoid
	collapse in the Internet. Interactive realtime communication imposes		congestion collapse in the Internet. Interactive realtime
	a lot of requirements on the transport, therefore a robust, efficient		communication imposes a lot of requirements on the transport,
	rate adaptation for all access types is an important part of		therefore a robust, efficient rate adaptation for all access types is
	interactive realtime communications as the transmission channel		an important part of interactive realtime communications as the
	bandwidth MAY vary over time. Wireless access such as LTE, which is		transmission channel bandwidth can vary over time. Wireless access
	an integral part of the current Internet, increases the importance of		such as LTE, which is an integral part of the current Internet,
	rate adaptation as the channel bandwidth of a default LTE bearer		increases the importance of rate adaptation as the channel bandwidth
	[QoS-3GPP] can change considerably in a very short time frame. Thus		of a default LTE bearer [QoS-3GPP] can change considerably in a very
	a rate adaptation solution for interactive realtime media, such as		short time frame. Thus a rate adaptation solution for interactive
	WebRTC, SHOULD be both quick and be able to operate over a large		realtime media, such as WebRTC, should be both quick and be able to
	range in channel capacity. This memo describes SCReAM (Self-Clocked		operate over a large range in channel capacity. This memo describes
	Rate Adaptation for Multimedia), a solution that is based on the		SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that
	self-clocking principle of TCP and uses techniques similar to what is		implements congestion control for RTP streams [RFC3550]. While
	used in the LEDBAT based rate adaptation algorithm [RFC6817]. SCReAM		SCReAM was originally devised for WebRTC (Web Real-Time
	is not entirely self-clocked as it augments self-clocking with pacing		Communication) [RFC7478], it can also be used for other applications
	and a minimum send rate.		where congestion control of RTP streams is necessary. SCReAM is
			based on the self-clocking principle of TCP and uses techniques
			similar to what is used in the LEDBAT based rate adaptation algorithm
			[RFC6817]. SCReAM is not entirely self-clocked as it augments self-
			clocking with pacing and a minimum send rate.
	1.1. Wireless (LTE) access properties		1.1. Wireless (LTE) access properties
	[I-D.ietf-rmcat-wireless-tests] describes the complications that can		[I-D.ietf-rmcat-wireless-tests] describes the complications that can
	be observed in wireless environments. Wireless access such as LTE		be observed in wireless environments. Wireless access such as LTE
	can typically not guarantee a given bandwidth, this is true		can typically not guarantee a given bandwidth, this is true
	especially for default bearers. The network throughput MAY vary		especially for default bearers. The network throughput can vary
	considerably for instance in cases where the wireless terminal is		considerably for instance in cases where the wireless terminal is
	moving around. Even though LTE can support bitrates well above		moving around. Even though LTE can support bitrates well above
	100Mbps, there are cases when the available bitrate can be much		100Mbps, there are cases when the available bitrate can be much
	lower, examples are situations with high network load and poor		lower, examples are situations with high network load and poor
	coverage. An additional complication is that the network throughput		coverage. An additional complication is that the network throughput
	MAY drop for short time intervals at e.g. handover, these short		can drop for short time intervals at e.g. handover, these short
	glitches are initially very difficult to distinguish from more		glitches are initially very difficult to distinguish from more
	permanent reductions in throughput.		permanent reductions in throughput.
	Unlike wireline bottlenecks with large statistical multiplexing it is		Unlike wireline bottlenecks with large statistical multiplexing it is
	not possible to try to maintain a given bitrate when congestion is		not possible to try to maintain a given bitrate when congestion is
	detected with the hope that other flows will yield, this is because		detected with the hope that other flows will yield, this is because
	there are generally few other flows competing for the same		there are generally few other flows competing for the same
	bottleneck. Each user gets its own variable throughput bottleneck,		bottleneck. Each user gets its own variable throughput bottleneck,
	where the throughput depends on factors like channel quality, network		where the throughput depends on factors like channel quality, network
	load and historical throughput. The bottom line is, if the		load and historical throughput. The bottom line is, if the
	throughput drops, the sender has no other option than to reduce the		throughput drops, the sender has no other option than to reduce the
	bitrate. Once the radio scheduler has reduced the resource		bitrate. Once the radio scheduler has reduced the resource
	allocation for a bearer, an RMCAT flow in that bearer SHOULD reduce		allocation for a bearer, an RMCAT flow in that bearer aims to reduce
	the sending rate quite quickly (within one RTT) in order to avoid		the sending rate quite quickly (within one RTT) in order to avoid
	excessive queuing delay or packet loss.		excessive queuing delay or packet loss.
	1.2. Why is it a self-clocked algorithm?		1.2. Why is it a self-clocked algorithm?
	Self-clocked congestion control algorithms provide a benefit over the		Self-clocked congestion control algorithms provide a benefit over the
	rate based counterparts in that the former consists of two adaptation		rate based counterparts in that the former consists of two adaptation
	mechanisms:		mechanisms:
	o A congestion window computation that evolves over a longer		o A congestion window computation that evolves over a longer
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 10 ¶
	The RECOMMENDED values, within (), for the constants are deduced from		The RECOMMENDED values, within (), for the constants are deduced from
	experiments. The units are enclosed in square brackets [ ].		experiments. The units are enclosed in square brackets [ ].
	QDELAY_TARGET_LO (0.1s)		QDELAY_TARGET_LO (0.1s)
	Target value for the minimum qdelay.		Target value for the minimum qdelay.
	QDELAY_TARGET_HI (0.4s)		QDELAY_TARGET_HI (0.4s)
	Target value for the maximum qdelay. This parameter provides an		Target value for the maximum qdelay. This parameter provides an
	upper limit to how much the target qdelay (qdelay_target) can be		upper limit to how much the target qdelay (qdelay_target) can be
	increased in order to cope with competing loss based flows. The		increased in order to cope with competing loss based flows. The
	target qdelay MUST NOT be initialized to this high value however as		target qdelay does not have to be initialized to this high value
	it would increase e2e delay and also make the rate control and		however as it would increase e2e delay and also make the rate
	congestion control loop sluggish.		control and congestion control loop sluggish.
	QDELAY_WEIGHT (0.1)		QDELAY_WEIGHT (0.1)
	Averaging factor for qdelay_fraction_avg.		Averaging factor for qdelay_fraction_avg.
	QDELAY_TREND_TH (0.2)		QDELAY_TREND_TH (0.2)
	Averaging factor for qdelay_fraction_avg.		Averaging factor for qdelay_fraction_avg.
			QDELAY_TREND_TH (0.2)
			Averaging factor for qdelay_fraction_avg.
			MIN_CWND (3000byte)
			Min CWND.
	MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)		MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1)
	Headroom for the limitation of CWND.		Headroom for the limitation of CWND.
	GAIN (1.0)		GAIN (1.0)
	Gain factor for congestion window adjustment.		Gain factor for congestion window adjustment.
	BETA_LOSS (0.8)		BETA_LOSS (0.8)
	CWND scale factor due to loss event.		CWND scale factor due to loss event.
	BETA_ECN (0.8)		BETA_ECN (0.8)
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 32 ¶
	for evaluation of a real implementation.		for evaluation of a real implementation.
	RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate		RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate
	reduction.		reduction.
	TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP		TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP
	qdelay threshold exceeds.		qdelay threshold exceeds.
	QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.		QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
	T_RESUME_FAST_INCREASE Time span until fast increase can be resumed,		T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be
	given that the qdelay_trend is below QDELAY_TREND_LO.		resumed, given that the qdelay_trend is below QDELAY_TREND_LO.
			RATE_PACE_MIN (50000bps) Minimum pacing rate.
	4.1.1.2. State variables		4.1.1.2. State variables
	The values within () indicate initial values.		The values within () indicate initial values.
	qdelay_target (QDELAY_TARGET_LO)		qdelay_target (QDELAY_TARGET_LO)
	qdelay target, a variable qdelay target is introduced to manage		qdelay target, a variable qdelay target is introduced to manage
	cases where e.g. FTP competes for the bandwidth over the same		cases where e.g. FTP competes for the bandwidth over the same
	bottleneck, a fixed qdelay target would otherwise starve the RMCAT		bottleneck, a fixed qdelay target would otherwise starve the RMCAT
	flow under such circumstances. The qdelay target is allowed to		flow under such circumstances. The qdelay target is allowed to
	skipping to change at page 14, line 48 ¶		skipping to change at page 15, line 7 ¶
	# of congestion in the past		# of congestion in the past
	qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend)		qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend)
	<CODE ENDS>		<CODE ENDS>
	The qdelay fraction is sampled every 50ms and the last 20 samples are		The qdelay fraction is sampled every 50ms and the last 20 samples are
	stored in a vector (qdelay_fraction_hist). This vector is used in		stored in a vector (qdelay_fraction_hist). This vector is used in
	the computation of an qdelay trend that gives a value between 0.0 and		the computation of an qdelay trend that gives a value between 0.0 and
	1.0 depending on the estimated congestion level. The prediction		1.0 depending on the estimated congestion level. The prediction
	coefficient 'a' has positive values if qdelay shows an increasing		coefficient 'a' has positive values if qdelay shows an increasing
	trend, thus an indication of congestion is obtained before the qdelay		trend, thus an indication of congestion is obtained before the qdelay
	target is reached. The autocorrelation function 'R' is defined in		target is reached.
	Appendix A.2. The prediction coefficient is further multiplied with
			The autocorrelation function 'R' is defined as follows. Let x be a
			vector constituting N values, the biased autocorrelation function for
			a given lag=k for the vector x is given by.
			n=N-k
			R(x,k) = SUM x(n)*x(n+k)
			n=1
			The prediction coefficient is further multiplied with
	qdelay_fraction_avg to reduce sensitivity to increasing qdelay when		qdelay_fraction_avg to reduce sensitivity to increasing qdelay when
	it is very small. The 50ms sampling is a simplification and MAY have		it is very small. The 50ms sampling is a simplification and MAY have
	the effect that the same qdelay is sampled several times, this does		the effect that the same qdelay is sampled several times, this does
	however not pose any problem as the vector is only used to determine		however not pose any problem as the vector is only used to determine
	if the qdelay is increasing or decreasing. The qdelay_trend is		if the qdelay is increasing or decreasing. The qdelay_trend is
	utilized in the media rate control to indicate incipient congestion		utilized in the media rate control to indicate incipient congestion
	and to determine when to exit from fast increase mode.		and to determine when to exit from fast increase mode.
	qdelay_trend_mem is used to enforce a less aggressive rate increase		qdelay_trend_mem is used to enforce a less aggressive rate increase
	after congestion events. The function		after congestion events. The function
	update_qdelay_fraction_hist(..) removes the oldest element and adds		update_qdelay_fraction_hist(..) removes the oldest element and adds
	the latest qdelay_fraction element to the qdelay_fraction_hist		the latest qdelay_fraction element to the qdelay_fraction_hist
	vector.		vector.
			4.1.2.1. Reaction to packets loss and ECN
	A loss event is indicated if one or more RTP packets are declared		A loss event is indicated if one or more RTP packets are declared
	missing. The loss detection is described in Section 4.1.2.3. Once a		missing. The loss detection is described in Section 4.1.2.4. Once a
	loss event is detected, further detected lost RTP packets are ignored		loss event is detected, further detected lost RTP packets SHOULD be
	for a full smoothed round trip time, the intention of this is to		ignored for a full smoothed round trip time, the intention of this is
	limit the congestion window decrease to at most once per round trip.		to limit the congestion window decrease to at most once per round
			trip.
	The congestion window back off due to loss events is deliberately a		The congestion window back off due to loss events is deliberately a
	bit less than is the case with e.g. TCP Reno. The reason is that		bit less than is the case with e.g. TCP Reno. The reason is that
	TCP is generally used to transmit whole files, which can be		TCP is generally used to transmit whole files, which can be
	translated to an infinite source bitrate. SCReAM on the other hand		translated to an infinite source bitrate. SCReAM on the other hand
	has a source whose rate is limited to a value close to the available		has a source whose rate is limited to a value close to the available
	transmit rate and often below that value, the effect of this is that		transmit rate and often below that value, the effect of this is that
	SCReAM has less opportunity to grab free capacity than a TCP based		SCReAM has less opportunity to grab free capacity than a TCP based
	file transfer. To compensate for this it is RECOMMENDED to let		file transfer. To compensate for this it is RECOMMENDED to let
	SCReAM reduce the congestion window less than what is the case with		SCReAM reduce the congestion window less than what is the case with
	TCP when loss events occur.		TCP when loss events occur.
	skipping to change at page 15, line 40 ¶		skipping to change at page 16, line 12 ¶
	An ECN event is detected if the n_ECN counter in the feedback report		An ECN event is detected if the n_ECN counter in the feedback report
	has increased since the previous received feedback. Once an ECN		has increased since the previous received feedback. Once an ECN
	event is detected, the n_ECN counter is ignored for a full smoothed		event is detected, the n_ECN counter is ignored for a full smoothed
	round trip time, the intention of this is to limit the congestion		round trip time, the intention of this is to limit the congestion
	window decrease to at most once per round trip. The congestion		window decrease to at most once per round trip. The congestion
	window back off due to an ECN event MAY be smaller than if a loss		window back off due to an ECN event MAY be smaller than if a loss
	event occurs. This is in line with the idea outlined in		event occurs. This is in line with the idea outlined in
	[I-D.ietf-tcpm-alternativebackoff-ecn] to enable ECN marking		[I-D.ietf-tcpm-alternativebackoff-ecn] to enable ECN marking
	thresholds lower than the corresponding packet drop thresholds.		thresholds lower than the corresponding packet drop thresholds.
			4.1.2.2. Congestion window update
	The update of the congestion window depends on whether loss or ECN-		The update of the congestion window depends on whether loss or ECN-
	marking or neither occurs. The pseudo code below describes actions		marking or neither occurs. The pseudo code below describes actions
	taken in case of the different events.		taken in case of the different events.
	<CODE BEGINS>		<CODE BEGINS>
	on congestion event(qdelay):		on congestion event(qdelay):
	# Either loss or ECN mark is detected		# Either loss or ECN mark is detected
	in_fast_increase = false		in_fast_increase = false
	if (is loss)		if (is loss)
	# loss is detected		# loss is detected
	cwnd = max(min_cwnd,cwnd*BETA_LOSS)		cwnd = max(MIN_CWND,cwnd*BETA_LOSS)
	else		else
	# No loss, so it is then an ECN mark		# No loss, so it is then an ECN mark
	cwnd = max(min_cwnd,cwnd*BETA_ECN)		cwnd = max(MIN_CWND,cwnd*BETA_ECN)
	end		end
	adjust_qdelay_target(qdelay) #compensating for competing flows		adjust_qdelay_target(qdelay) #compensating for competing flows
	calculate_send_window(qdelay,qdelay_target)		calculate_send_window(qdelay,qdelay_target)
	# when no congestion event		# when no congestion event
	on acknowledgement(qdelay):		on acknowledgement(qdelay):
	update_bytes_newly_acked()		update_bytes_newly_acked()
	update_cwnd(bytes_newly_acked)		update_cwnd(bytes_newly_acked)
	adjust_qdelay_target(qdelay) #compensating for competing flows		adjust_qdelay_target(qdelay) #compensating for competing flows
	calculate_send_window(qdelay, qdelay_target)		calculate_send_window(qdelay, qdelay_target)
	check_to_resume_fast_increase()		check_to_resume_fast_increase()
	<CODE ENDS>		<CODE ENDS>
	The methods are further described in detail below.		The methods are further described in detail below.
	4.1.2.1. Congestion window update
	The congestion window update is based on qdelay, except for the		The congestion window update is based on qdelay, except for the
	occurrence of loss events (one or more lost RTP packets in one RTT),		occurrence of loss events (one or more lost RTP packets in one RTT),
	or ECN events, which was described earlier.		or ECN events, which was described earlier.
	Pseudo code for the update of the congestion window is found below.		Pseudo code for the update of the congestion window is found below.
	<CODE BEGINS>		<CODE BEGINS>
	update_cwnd(bytes_newly_acked):		update_cwnd(bytes_newly_acked):
	# in fast increase ?		# in fast increase ?
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 19 ¶
	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. Sparse feedback can potentially limit congestion		sufficiently used. Sparse feedback can potentially limit congestion
	window growth, an additional slack is therefore added, given by the		window growth, an additional slack is therefore added, given by the
	number of newly acknowledged bytes.		number of newly acknowledged 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]. However, [RFC6817] specifies that the CWND increase is
			limited by an additional function controlled by a constant
	o [RFC6817] specifies a constant GAIN, this specification however		ALLOWED_INCREASE. This additional limitation is removed in this
	limits the gain when CWND is increased dependent on near		specification.
	congestion state and the relation to the last known max CWND
	value.
	o [RFC6817] specifies that the CWND increase is limited by an
	additional function controlled by a constant ALLOWED_INCREASE.
	This additional limitation is removed in this specification.
	Further the CWND is limited by max_bytes_in_flight and min_cwnd. The		Further the CWND is limited by max_bytes_in_flight and min_cwnd. The
	limitation of the congestion window by the maximum number of bytes in		limitation of the congestion window by the maximum number of bytes in
	flight over the last 5 seconds (max_bytes_in_flight) avoids possible		flight over the last 5 seconds (max_bytes_in_flight) avoids possible
	over-estimation of the throughput after for example, idle periods.		over-estimation of the throughput after for example, idle periods.
	An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to		An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to
	allow for a certain amount of media coder output rate variability.		allow for a certain amount of media coder output rate variability.
	4.1.2.2. Competing flows compensation		4.1.2.3. Competing flows compensation
	It is likely that a flow using SCReAM algorithm will have to share		It is likely that a flow using SCReAM algorithm will have to share
	congested bottlenecks with other flows that use a more aggressive		congested bottlenecks with other flows that use a more aggressive
	congestion control algorithm. SCReAM takes care of such situations		congestion control algorithm. SCReAM takes care of such situations
	by adjusting the qdelay_target.		by adjusting the qdelay_target.
	<CODE BEGINS>		<CODE BEGINS>
	adjust_qdelay_target(qdelay)		adjust_qdelay_target(qdelay)
	qdelay_norm_t = qdelay / QDELAY_TARGET_LOW		qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
	update_qdelay_norm_history(qdelay_norm_t)		update_qdelay_norm_history(qdelay_norm_t)
	# Compute variance		# Compute variance
	qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))		qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
	# Compensation for competing traffic		# Compensation for competing traffic
	# Compute average		# Compute average
	qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))		qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
	# Compute upper limit to target delay		# Compute upper limit to target delay
	oh_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)		new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
	oh_t *= QDELAY_TARGET_LO		new_target_t *= QDELAY_TARGET_LO
	if (loss_event_rate > 0.002)		if (loss_event_rate > 0.002)
	# Packet losses detected		# Packet losses detected
	qdelay_target = 1.5*oh_t		qdelay_target = 1.5*new_target_t
	else		else
	if (qdelay_norm_var_t < 0.2)		if (qdelay_norm_var_t < 0.2)
	# Reasonably safe to set target qdelay		# Reasonably safe to set target qdelay
	qdelay_target = oh_t		qdelay_target = new_target_t
	else		else
	# Check if target delay can be reduced, this helps to avoid		# Check if target delay can be reduced, this helps to avoid
	# that the target delay is locked to high values for ever		# that the target delay is locked to high values for ever
	if (oh_t < QDELAY_TARGET_LO)		if (new_target_t < QDELAY_TARGET_LO)
	# Decrease target delay quickly as measured queueing		# Decrease target delay quickly as measured queueing
	# delay is lower than target		# delay is lower than target
	qdelay_target = max(qdelay_target*0.5,oh_t)		qdelay_target = max(qdelay_target*0.5,new_target_t)
	else		else
	# Decrease target delay slowly		# Decrease target delay slowly
	qdelay_target *= 0.9		qdelay_target *= 0.9
	end		end
	end		end
	end		end
	# Apply limits		# Apply limits
	qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)		qdelay_target = min(QDELAY_TARGET_HI, qdelay_target)
	qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)		qdelay_target = max(QDELAY_TARGET_LO, qdelay_target)
	skipping to change at page 20, line 6 ¶		skipping to change at page 20, line 6 ¶
	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 to avoid the case that the qdelay		change rapidly. It is desired to avoid the case that the qdelay
	target is increased due to self-congestion, indicated by a changing		target is increased due to self-congestion, indicated by a changing
	qdelay and consequently an increased qdelay_norm_var_t. Still it		qdelay and consequently an increased qdelay_norm_var_t. Still it
	SHOULD be possible to increase the qdelay target if the qdelay		SHOULD be possible to increase the qdelay target if the qdelay
	continues to be high. This is a simple function with a certain risk		continues to be high. This is a simple function with a certain risk
	of both false positives and negatives. In the simulated LTE test		of both false positives and negatives. In the simulated LTE test
	cases it manages competing FTP flows reasonably well at the same time		cases it manages competing FTP flows reasonably well at the same time
	as generally avoiding accidental increases in the qdelay target. The		as generally avoiding accidental increases in the qdelay target. The
	algorithm can however accidentally increase the qdelay target and		algorithm can however accidentally increase the qdelay target and
	cause self-inflicted congestion in certain cases. It is therefore		cause self-inflicted congestion in certain cases. If it is deemed
	RECOMMENDED that the algorithm described in this section is turned		unlikely that competing flows occur over the same bottleneck, the
	off it is deemed unlikely that competing flows occur over the same		algorithm described in this section MAY be turned off. However, when
	bottleneck		sending over the Internet, often the network conditions are not known
			for sure. Therefore turning this algorithm off must be considered
			with caution as that can lead to basically zero throughput if
			competing with other, loss based, traffic.
	4.1.2.3. Lost packet detection		4.1.2.4. Lost packet detection
	Lost packet detection is based on the received sequence number list.		Lost packet detection is based on the received sequence number list.
	A reordering window SHOULD be applied to avoid packet reordering		A reordering window SHOULD be applied to avoid that packet reordering
	triggering 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) [I-D.ietf-tcpm-rack]. The		ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. The
	computation of the reordering window is made possible by means of a		computation of the reordering window is made possible by means of a
	lost flag in the list of transmitted RTP packets. This flag is set		lost flag in the list of transmitted RTP packets. This flag is set
	if the received sequence number list indicates that the given RTP		if the received sequence number list indicates that the given RTP
	packet is missing. If a later feedback indicates that a previously		packet is missing. If a later feedback indicates that a previously
	lost marked packet was indeed received, then the reordering window is		lost marked packet was indeed received, then the reordering window is
	updated to reflect the reordering delay. The reordering window is		updated to reflect the reordering delay. The reordering window is
	given by the difference in time between the event that the packet was		given by the difference in time between the event that the packet was
	marked as lost and the event that it was indicated as successfully		marked as lost and the event that it was indicated as successfully
	received.		received.
	Loss is detected if a given RTP packet is not acknowledged within a		Loss is detected if a given RTP packet is not acknowledged within a
	time window (indicated by the reordering window) after an RTP packet		time window (indicated by the reordering window) after an RTP packet
	with higher sequence number was acknowledged.		with higher sequence number was acknowledged.
	4.1.2.4. Send window calculation		4.1.2.5. Send window calculation
	The basic design principle behind packet transmission in SCReAM is to		The basic design principle behind packet transmission in SCReAM is to
	allow transmission only if the number of bytes in flight is less than		allow transmission only if the number of bytes in flight is less than
	the congestion window. There are however two reasons why this strict		the congestion window. There are however two reasons why this strict
	rule will not work optimally:		rule will not work optimally:
	o Bitrate variations: The media frame size is always varying to a		o Bitrate variations: The media frame size is always varying to a
	larger or smaller extent. A strict rule can lead to that the		larger or smaller extent. A strict rule can lead to that the
	media bitrate will have difficulties to increase as the congestion		media bitrate will have difficulties to increase as the congestion
	window puts a too hard restriction on the media frame size		window puts a too hard restriction on the media frame size
	variation. This can lead to occasional queuing of RTP packets in		variation. This can lead to occasional queuing of RTP packets in
	the RTP packet queue that will prevent bitrate increase.		the RTP packet queue that will prevent bitrate increase.
	o Reverse (feedback) path congestion: Especially in transport over		o Reverse (feedback) path congestion: Especially in transport over
	buffer-bloated networks, the one way delay in the reverse		buffer-bloated networks, the one way delay in the reverse
	direction MAY jump due to congestion. The effect of this is that		direction can jump due to congestion. The effect of this is that
	the acknowledgements are delayed with the result that the self-		the acknowledgements are delayed with the result that the self-
	clocking is temporarily halted, even though the forward path is		clocking is temporarily halted, even though the forward path is
	not congested.		not congested.
	The send window is adjusted depending on qdelay and its relation to		The send window is adjusted depending on qdelay and its relation to
	the qdelay target and the relation between the congestion window and		the qdelay target and the relation between the congestion window and
	the number of bytes in flight. A strict rule is applied when qdelay		the number of bytes in flight. A strict rule is applied when qdelay
	is higher than qdelay_target, to avoid further queue buildup in the		is higher than qdelay_target, to avoid further queue buildup in the
	network. For cases when qdelay is lower than the qdelay_target, a		network. For cases when qdelay is lower than the qdelay_target, a
	more relaxed rule is applied. This allows the bitrate to increase		more relaxed rule is applied. This allows the bitrate to increase
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 33 ¶
	if (qdelay <= qdelay_target)		if (qdelay <= qdelay_target)
	send_wnd = cwnd+MSS-bytes_in_flight		send_wnd = cwnd+MSS-bytes_in_flight
	else		else
	send_wnd = cwnd-bytes_in_flight		send_wnd = cwnd-bytes_in_flight
	end		end
	<CODE ENDS>		<CODE ENDS>
	The send window is updated whenever an RTP packet is transmitted or		The send window is updated whenever an RTP packet is transmitted or
	an RTCP feedback messaged is received.		an RTCP feedback messaged is received.
	4.1.2.5. Packet pacing		4.1.2.6. Packet pacing
	Packet pacing is used in order to mitigate coalescing i.e. that		Packet pacing is used in order to mitigate coalescing i.e. that
	packets are transmitted in bursts, with the increased risk of more		packets are transmitted in bursts, with the increased risk of more
	jitter and potentially increased packet loss. The time interval		jitter and potentially increased packet loss. Packet pacing also
	between consecutive packet transmissions is enforced to be equal to		mitigates possible issues with queue overflow due to key-frame
	or higher than t_pace where t_pace is given by the equations below :		generation in video coders. The time interval between consecutive
			packet transmissions is enforced to be equal to or higher than t_pace
			where t_pace is given by the equations below :
	<CODE BEGINS>		<CODE BEGINS>
	pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt)		pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt)
	t_pace = rtp_size * 8 / pace_bitrate		t_pace = rtp_size * 8 / pace_bitrate
	<CODE ENDS>		<CODE ENDS>
	rtp_size is the size of the last transmitted RTP packet, s_rtt is the		rtp_size is the size of the last transmitted RTP packet, s_rtt is the
	smoothed round trip time. RATE_PACE_MIN=50000 is the minimum pacing		smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate.
	rate.
	4.1.2.6. Resuming fast increase		4.1.2.7. Resuming fast increase
	Fast increase can resume in order to speed up the bitrate increase in		Fast increase can resume in order to speed up the bitrate increase in
	case congestion abates. The condition to resume fast increase		case congestion abates. The condition to resume fast increase
	(in_fast_increase = true) is that qdelay_trend is less than		(in_fast_increase = true) is that qdelay_trend is less than
	QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.		QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more.
			4.1.2.8. Stream prioritization
			The SCReAM algorithm makes a good distinction between network
			congestion control and the media rate control. This is easily
			extended to many streams, in which case RTP packets from two or more
			RTP queues are scheduled at the rate permitted by the network
			congestion control.
			The scheduling can be done by means of a few different scheduling
			regimes. For example the method applied in
			[I-D.ietf-rmcat-coupled-cc] can be used. The implementation of
			SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In
			credit based scheduling, credit is accumulated by queues as they wait
			for service and are spent while the queues are being serviced. For
			instance, if one queue is allowed to transmit 1000bytes, then a
			credit of 1000bytes is allocated to the other unscheduled queues.
			This principle can be extended to weighted scheduling in which case
			the credit allocated to unscheduled queues depends on the relative
			weights. The latter is also implemented in
			[SCReAM-CPP-implementation].
	4.1.3. Media rate control		4.1.3. Media rate control
	The media rate control algorithm is executed at regular intervals		The media rate control algorithm is executed at regular intervals
	RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to		RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to
	loss events. The media rate control operates based on the size of		loss events. The media rate control operates based on the size of
	the RTP packet send queue and observed loss events. In addition,		the RTP packet send queue and observed loss events. In addition,
	qdelay_trend is also considered in the media rate control to reduce		qdelay_trend is also considered in the media rate control to reduce
	the amount of induced network jitter.		the amount of induced network jitter.
	The role of the media rate control is to strike a reasonable balance		The role of the media rate control is to strike a reasonable balance
	between a low amount of queuing in the RTP queue(s) and a sufficient		between a low amount of queuing in the RTP queue(s) and a sufficient
	amount of data to send in order to keep the data path busy. A too		amount of data to send in order to keep the data path busy. A too
	cautious setting leads to possible under-utilization of network		cautious setting leads to possible under-utilization of network
	capacity leading to the flow being starved out by other more		capacity leading to that the flow can become starved out by other
	opportunistic traffic. On the other hand, a too aggressive setting		more opportunistic traffic. On the other hand, a too aggressive
	leads to increased jitter.		setting leads to increased jitter.
	The target_bitrate is adjusted depending on the congestion state.		The target_bitrate is adjusted depending on the congestion state.
	The target bitrate can vary between a minimum value		The target bitrate can vary between a minimum value
	(TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX).		(TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX).
	TARGET_BITRATE_MIN SHOULD be chosen to a low enough value to avoid		TARGET_BITRATE_MIN SHOULD be chosen to a low enough value to avoid
	RTP packets being queued up when the network throughput becomes low.		that RTP packets become queued up when the network throughput is
	The sender SHOULD also be equipped with a mechanism that discards RTP		reduced. The sender SHOULD also be equipped with a mechanism that
	packets in cases where the network throughput becomes very low and		discards RTP packets in cases where the network throughput becomes
	RTP packets are excessively delayed.		very low and RTP packets are excessively delayed.
	For the overall bitrate adjustment, two network throughput estimates		For the overall bitrate adjustment, two network throughput estimates
	are computed :		are computed :
	o rate_transmit: The measured transmit bitrate.		o rate_transmit: The measured transmit bitrate.
	o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per		o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per
	second.		second.
	Both estimates are updated every 200ms.		Both estimates are updated every 200ms.
	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 can 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 or ECN event has		The rate change behavior depends on whether a loss or ECN event has
	occurred and if the congestion control is in fast increase or not.		occurred and if the congestion control is in fast increase or not.
	<CODE BEGINS>		<CODE BEGINS>
	# 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
	skipping to change at page 24, line 23 ¶		skipping to change at page 24, line 48 ¶
	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 RTP packets being queued up when the transmit		pro actively avoids RTP packets being queued up when the transmit
	rate decreases due to the reduced congestion window. A similar rate		rate decreases due to the reduced congestion window. A similar rate
	reduction happens when ECN events are detected.		reduction happens when ECN events are detected.
	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		life limitations in video coders taken into account
	[SCReAM-CPP-implementation]. A too short interval is shown to make		[SCReAM-CPP-implementation]. A too short interval is shown to make
	the video coder internal rate control loop more unstable, a too long		the rate control loop in video coders more unstable, a too long
	interval makes the overall congestion control sluggish.		interval makes the overall congestion 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
	ramp-up speed is limited when the target bitrate is low to avoid rate		ramp-up speed is limited when the target bitrate is low to avoid rate
	oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED		oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED
	depends on preferences, a high setting such as 1000kbps/s makes it		depends on preferences, a high setting such as 1000kbps/s makes it
	possible to quickly get high quality media, this is however at the		possible to quickly get high quality media, this is however at the
	expense of a increased jitter, which can manifest itself as e.g.		expense of a increased jitter, which can manifest itself as e.g.
	choppy video rendering.		choppy video rendering.
	skipping to change at page 24, line 45 ¶		skipping to change at page 25, line 24 ¶
	When in_fast_increase is false, the bitrate increase is given by the		When in_fast_increase is false, the bitrate increase is given by the
	current bitrate and is also controlled by the estimated RTP queue and		current bitrate and is also controlled by the estimated RTP queue and
	the qdelay trend, thus it is sufficient that an increased congestion		the qdelay trend, thus it is sufficient that an increased congestion
	level is sensed by the network congestion control to limit the		level is sensed by the network congestion control to limit the
	bitrate. The target_bitrate_last_max is updated when congestion is		bitrate. The target_bitrate_last_max is updated when congestion is
	detected.		detected.
	Finally the target_bitrate is enforced to be within the defined min		Finally the target_bitrate is enforced to be within the defined min
	and max values.		and max values.
	The aware reader MAY notice the dependency on the qdelay in the		The aware reader may notice the dependency on the qdelay in the
	computation of the target bitrate, this manifests itself in the use		computation of the target bitrate, this manifests itself in the use
	of the qdelay_trend. As these parameters are used also in the		of the qdelay_trend. As these parameters are used also in the
	network congestion control one MAY suspect some odd interaction		network congestion control one may suspect some odd interaction
	between the media rate control and the network congestion control,		between the media rate control and the network congestion control,
	this is in fact the case if the parameter PRE_CONGESTION_GUARD is set		this is in fact the case if the parameter PRE_CONGESTION_GUARD is set
	to a high value. The use of qdelay_trend in the media rate control		to a high value. The use of qdelay_trend in the media rate control
	is solely to reduce jitter, the dependency can be removed by setting		is solely to reduce jitter, the dependency can be removed by setting
	PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase		PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase
	after congestion, at the expense of increased jitter in congested		after congestion, at the expense of increased jitter in congested
	situations.		situations.
	4.2. SCReAM Receiver		4.2. SCReAM Receiver
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 50 ¶
	SCReAM sender, in addition, the receive time of the RTP packet with		SCReAM sender, in addition, the receive time of the RTP packet with
	the highest sequence number is echoed back. Upon reception of each		the highest sequence number is echoed back. Upon reception of each
	RTP packet the receiver MUST maintain enough information to send the		RTP packet the receiver MUST maintain enough information to send the
	aforementioned values to the SCReAM sender via a RTCP transport layer		aforementioned values to the SCReAM sender via a RTCP transport layer
	feedback message. The frequency of the feedback message depends on		feedback message. The frequency of the feedback message depends on
	the available RTCP bandwidth. The requirements on the feedback		the available RTCP bandwidth. The requirements on the feedback
	elements and the feedback interval is described.		elements and the feedback interval is described.
	4.2.1. Requirements on feedback elements		4.2.1. Requirements on feedback elements
	SCReAM requires the following elements for its basic functionality,		The following feedback elements are REQUIRED for the basic
	i.e. only including features that are strictly necessary in order to		functionality in SCReAM.
	make SCReAM function. ECN is not included as basic functionality as
	it regarded as an additional feature that is not strictly necessary
	even though it can improve quality of experience quite considerably.
	o A list of received RTP packets. This list SHOULD be sufficiently		o A list of received RTP packets. This list SHOULD be sufficiently
	long to cover all received RTP packets. This list can be realized		long to cover all received RTP packets. This list can be realized
	with the Loss RLE report block in [RFC3611].		with the Loss RLE report block in [RFC3611].
	o A wall clock timestamp corresponding to the received RTP packet		o A wall clock timestamp corresponding to the received RTP packet
	with the highest sequence number is required in order to compute		with the highest sequence number is required in order to compute
	the qdelay. This can be realized by means of the Packet Receipt		the qdelay. This can be realized by means of the Packet Receipt
	Times Report Block in [RFC3611]. begin_seq MUST be set to the		Times Report Block in [RFC3611]. begin_seq MUST be set to the
	highest received (possibly wrapped around) sequence number,		highest received (possibly wrapped around) sequence number,
	skipping to change at page 26, line 35 ¶		skipping to change at page 27, line 5 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SSRC of source |		| SSRC of source |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| begin_seq | end_seq |		| begin_seq | end_seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Receipt time of packet begin_seq |		| Receipt time of packet begin_seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Basic feedback message for SCReAM, based on RFC3611		Figure 2: Basic feedback message for SCReAM, based on RFC3611
	In a typical use case, no more than four Loss RLE chunks SHOULD be		In a typical use case, no more than four Loss RLE chunks are needed,
	needed, thus the feedback message will be 44bytes. It is obvious		thus the feedback message will be 44bytes. It is obvious from the
	from the figure that there is a lot of redundant information in the		figure that there is a lot of redundant information in the feedback
	feedback message. A more optimized feedback format, including the		message. A more optimized feedback format, including the additional
	additional feedback elements listed below, could reduce the feedback		feedback elements listed below, could reduce the feedback message
	message size a bit.		size a bit.
	Additional feedback elements that can improve the performance of		Additional feedback elements that can improve the performance of
	SCReAM are:		SCReAM are:
	o Accumulated number of ECN-CE marked packets (n_ECN). This can for		o Accumulated number of ECN-CE marked packets (n_ECN). This can for
	instance be realized with the ECN Feedback Report Format in		instance be realized with the ECN Feedback Report Format in
	[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 ECN-CE code		increments by one for each received packet with the ECN-CE code
	point set. The more bulky format MAY be nevertheless be useful		point set. The more bulky format could nevertheless be useful for
	for e.g ECN black-hole detection.		e.g ECN black-hole detection.
	4.2.2. Requirements on feedback intensity		4.2.2. Requirements on feedback intensity
	SCReAM benefits from a relatively frequent feedback. The feedback		SCReAM benefits from a relatively frequent feedback. It is
	interval depends on the media bitrate. At low bitrates it is		RECOMMENDED that a SCReAM implementation follows the guidelines
	sufficient with a feedback interval of 100 to 400ms, while at high		below.
	bitrates a feedback interval of roughly 20ms is to prefer.
			The feedback interval depends on the media bitrate. At low bitrates
			it is sufficient with a feedback interval of 100 to 400ms, while at
			high bitrates a feedback interval of roughly 20ms is to prefer, at
			very high bitrates, even shorter feedback intervals MAY be needed in
			order to keep the self-clocking in SCReAM working well. One piece of
			evidence of a too sparse feedback is that the SCReAM implementation
			cannot reach high bitrates, even in uncongested links. A more
			frequent feedback MAY solve this issue.
	The numbers above can be formulated as feedback interval function		The numbers above can be formulated as feedback interval function
	that can be useful for the computation of the desired RTCP bandwidth.		that can be useful for the computation of the desired RTCP bandwidth.
	The following equation expresses the feedback rate:		The following equation expresses the feedback rate:
	rate_fb = min(50,max(2.5,rate_media/10000))		rate_fb = min(50,max(2.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:
	skipping to change at page 27, line 32 ¶		skipping to change at page 28, line 13 ¶
	fb_int = 1.0/min(50,max(2.5,rate_media/10000))		fb_int = 1.0/min(50,max(2.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		SCReAM works with AVPF regular mode, immediate or early mode is not
	REQUIRED by SCReAM but MAY nonetheless be useful for e.g RTCP		required by SCReAM but can nonetheless be useful for e.g RTCP
	messages not directly related to SCReAM, such as those specified in		messages not directly related to SCReAM, such as those specified in
	[RFC4585]. It is RECOMMENDED to use reduced size RTCP [RFC5506]		[RFC4585]. It is RECOMMENDED to use reduced size RTCP [RFC5506]
	where regular full compound RTCP transmission is controlled by trr-		where regular full compound RTCP transmission is controlled by trr-
	int as described in [RFC4585].		int as described in [RFC4585].
	5. Discussion		5. Discussion
	This section covers a few discussion points		This section covers a few discussion points
	o Clock drift: SCReAM can suffer from the same issues with clock		o Clock drift: SCReAM can suffer from the same issues with clock
	drift as is the case with LEDBAT [RFC6817]. Section A.2 in		drift as is the case with LEDBAT [RFC6817]. Section A.2 in
	[RFC6817] however describes ways to mitigate issues with clock		[RFC6817] however describes ways to mitigate issues with clock
	drift.		drift.
	o Support for alternate ECN semantics: This specification adopts the		o Support for alternate ECN semantics: This specification adopts the
	proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the		proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the
	congestion window less when ECN based congestion events are		congestion window less when ECN based congestion events are
	detected. Future work on Low Loss Low Latency for Scalable		detected. Future work on Low Loss Low Latency for Scalable
	throughput (L4S) MAY lead to updates in a future RFC that		throughput (L4S) may lead to updates in a future RFC that
	describes SCReAM support for L4S.		describes SCReAM support for L4S.
	o A new RFC4585 transport layer feedback message MAY to be		o A new RFC4585 transport layer feedback message could to be
	standardized if the use of the already existing RTCP extensions as		standardized if the use of the already existing RTCP extensions as
	described in Section 4.2 is not deemed sufficient.		described in Section 4.2 is not deemed sufficient.
	o The target bitrate given by SCReAM depicts the bitrate including		o The target bitrate given by SCReAM depicts the bitrate including
	RTP and FEC overhead. The media encoder SHOULD take this overhead		RTP and FEC overhead. The media encoder SHOULD take this overhead
	into account when the media bitrate is set. This means that the		into account when the media bitrate is set. This means that the
	media coder bitrate SHOULD be computed as		media coder bitrate SHOULD be computed as
	media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate		media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate
	skipping to change at page 30, line 36 ¶		skipping to change at page 31, line 12 ¶
	o Trials with different kinds of media: Audio, Video, slide show		o Trials with different kinds of media: Audio, Video, slide show
	content. Evaluation of multi stream handling in SCReAM.		content. Evaluation of multi stream handling in SCReAM.
	o Evaluation of functionality of competing flows compensation		o Evaluation of functionality of competing flows compensation
	mechanism: Evaluate how SCReAM performs with competing TCP like		mechanism: Evaluate how SCReAM performs with competing TCP like
	traffic and to what extent the competing flows compensation causes		traffic and to what extent the competing flows compensation causes
	self-inflicted congestion.		self-inflicted congestion.
	o Determine proper parameters: A set of default parameters are given		o Determine proper parameters: A set of default parameters are given
	that makes SCReAM work over a reasonably large operation range,		that makes SCReAM work over a reasonably large operation range,
	however for instance for very low or very high bitrates it MAY be		however for instance for very low or very high bitrates it may be
	necessary to use different values for instance for the		necessary to use different values for instance for the
	RAMP_UP_SPEED.		RAMP_UP_SPEED.
	8. Acknowledgements		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 E. E. Nielsen and Mirja		additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja
	Kuehlewind for patiently reading, suggesting improvements and also		Kuehlewind for patiently reading, suggesting improvements and also
	for asking all the difficult but necessary questions. Thanks to		for asking all the difficult but necessary questions. Thanks to
	Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the		Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the
	additional review of this document. Thanks to Ralf Globisch for		additional review of this document. Thanks to Ralf Globisch for
	taking time to try out SCReAM in his challenging low bitrate use		taking time to try out SCReAM in his challenging low bitrate use
	cases.		cases, Robert Hedman for finding a few additional flaws in the
			running code, and Gustavo Garcia and 'miseri' for code contributions.
	9. IANA Considerations		9. IANA Considerations
	There is currently no request to IANA		There is currently no request to IANA
	10. 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. This attack is however mitigated		self-clocking in SCReAM to stall. This attack is however mitigated
	by the minimum send rate maintained by SCReAM when no feedback is		by the minimum send rate maintained by SCReAM when no feedback is
	received.		received.
	11. Change history		11. Change history
	A list of changes:		A list of changes:
			o WG-10 to WG-11: Review comments from Mirja
			o WG-9 to WG-10: Minor edits
	o WG-08 to WG-09: Updated based shepherd review by Martin		o WG-08 to WG-09: Updated based shepherd review by Martin
	Stiemerling, Q-bit semantics are removed as this is superfluous		Stiemerling, Q-bit semantics are removed as this is superfluous
	for the moment. Pacing and RTCP considerations are moved up from		for the moment. Pacing and RTCP considerations are moved up from
	the appendix, FEC discussion moved to discussion section.		the appendix, FEC discussion moved to discussion section.
	o WG-07 to WG-08: Avoid draft expiry		o WG-07 to WG-08: Avoid draft expiry
	o WG-06 to WG-07: Updated based on WGLC review by David Hayes and		o WG-06 to WG-07: Updated based on WGLC review by David Hayes and
	Safiqul Islam		Safiqul Islam
	skipping to change at page 32, line 22 ¶		skipping to change at page 33, line 4 ¶
	o -04 to -05 : ACK vector is replaced by a loss counter, PT is		o -04 to -05 : ACK vector is replaced by a loss counter, PT is
	removed from feedback, references to source code added		removed from feedback, references to source code added
	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
	12. References		12. References
	12.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>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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,		Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
	DOI 10.17487/RFC4585, July 2006,		DOI 10.17487/RFC4585, July 2006,
	<http://www.rfc-editor.org/info/rfc4585>.		<https://www.rfc-editor.org/info/rfc4585>.
	[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, DOI 10.17487/RFC5506, April		and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
	2009, <http://www.rfc-editor.org/info/rfc5506>.		2009, <https://www.rfc-editor.org/info/rfc5506>.
	[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>.		<https://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>.		<https://www.rfc-editor.org/info/rfc6817>.
	12.2. Informative References		12.2. Informative References
	[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-06		control for RTP media", draft-ietf-rmcat-coupled-cc-07
	(work in progress), March 2017.		(work in progress), September 2017.
	[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-		M. 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-04 (work in progress), May 2017.		wireless-tests-04 (work in progress), May 2017.
	[I-D.ietf-tcpm-alternativebackoff-ecn]		[I-D.ietf-tcpm-alternativebackoff-ecn]
	Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,		Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
	"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-		"TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm-
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 33 ¶
	[Packet-conservation]		[Packet-conservation]
	"Congestion Avoidance and Control, ACM SIGCOMM Computer		"Congestion Avoidance and Control, ACM SIGCOMM Computer
	Communication Review 1988", 1988.		Communication Review 1988", 1988.
	[QoS-3GPP]		[QoS-3GPP]
	TS 23.203, 3GPP., "Policy and charging control		TS 23.203, 3GPP., "Policy and charging control
	architecture", June 2011, <http://www.3gpp.org/ftp/specs/		architecture", June 2011, <http://www.3gpp.org/ftp/specs/
	archive/23_series/23.203/23203-990.zip>.		archive/23_series/23.203/23203-990.zip>.
			[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
			Jacobson, "RTP: A Transport Protocol for Real-Time
			Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
			July 2003, <https://www.rfc-editor.org/info/rfc3550>.
	[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,		[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
	"RTP Control Protocol Extended Reports (RTCP XR)",		"RTP Control Protocol Extended Reports (RTCP XR)",
	RFC 3611, DOI 10.17487/RFC3611, November 2003,		RFC 3611, DOI 10.17487/RFC3611, November 2003,
	<http://www.rfc-editor.org/info/rfc3611>.		<https://www.rfc-editor.org/info/rfc3611>.
	[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,		[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
	and K. Carlberg, "Explicit Congestion Notification (ECN)		and K. Carlberg, "Explicit Congestion Notification (ECN)
	for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August		for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
	2012, <http://www.rfc-editor.org/info/rfc6679>.		2012, <https://www.rfc-editor.org/info/rfc6679>.
			[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
			Time Communication Use Cases and Requirements", RFC 7478,
			DOI 10.17487/RFC7478, March 2015,
			<https://www.rfc-editor.org/info/rfc7478>.
	[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating		[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
	TCP to Support Rate-Limited Traffic", RFC 7661,		TCP to Support Rate-Limited Traffic", RFC 7661,
	DOI 10.17487/RFC7661, October 2015,		DOI 10.17487/RFC7661, October 2015,
	<http://www.rfc-editor.org/info/rfc7661>.		<https://www.rfc-editor.org/info/rfc7661>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<http://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	[SCReAM-CPP-implementation]		[SCReAM-CPP-implementation]
	"C++ Implementation of SCReAM",		"C++ Implementation of SCReAM",
	<https://github.com/EricssonResearch/scream>.		<https://github.com/EricssonResearch/scream>.
	[SCReAM-implementation]		[SCReAM-implementation]
	"SCReAM Implementation",		"SCReAM Implementation",
	<https://github.com/EricssonResearch/openwebrtc-gst-		<https://github.com/EricssonResearch/
	plugins>.		openwebrtc-gst-plugins>.
	[SCReAM-implementation-experience]		[SCReAM-implementation-experience]
	"Updates on SCReAM : An implementation experience",		"Updates on SCReAM : An implementation experience",
	<https://www.ietf.org/proceedings/94/slides/slides-94-		<https://www.ietf.org/proceedings/94/slides/
	rmcat-8.pdf>.		slides-94-rmcat-8.pdf>.
	[TFWC] University College London, "Fairer TCP-Friendly Congestion		[TFWC] University College London, "Fairer TCP-Friendly Congestion
	Control Protocol for Multimedia Streaming", December 2007,		Control Protocol for Multimedia Streaming", December 2007,
	<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/		<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/
	tfwc-conext.pdf>.		tfwc-conext.pdf>.
	Appendix A. Additional information
	A.1. Stream prioritization
	The SCReAM algorithm makes a good distinction between network
	congestion control and the media rate control. This is easily
	extended to many streams, in which case RTP packets from two or more
	RTP queues are scheduled at the rate permitted by the network
	congestion control.
	The scheduling can be done by means of a few different scheduling
	regimes. For example the method applied in
	[I-D.ietf-rmcat-coupled-cc] can be used. The implementation of
	SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In
	credit based scheduling, credit is accumulated by queues as they wait
	for service and are spent while the queues are being serviced. For
	instance, if one queue is allowed to transmit 1000bytes, then a
	credit of 1000bytes is allocated to the other unscheduled queues.
	This principle can be extended to weighted scheduling in which case
	the credit allocated to unscheduled queues depends on the relative
	weights.
	A.2. Computation of autocorrelation function
	The autocorrelation function is computed over a vector of values.
	Let x be a vector constituting N values, the biased autocorrelation
	function for a given lag=k for the vector x is given by .
	n=N-k
	R(x,k) = SUM x(n)*x(n+k)
	n=1
	Authors' Addresses		Authors' Addresses
	Ingemar Johansson		Ingemar Johansson
	Ericsson AB		Ericsson AB
	Laboratoriegraend 11		Laboratoriegraend 11
	Luleaa 977 53		Luleaa 977 53
	Sweden		Sweden
	Phone: +46 730783289		Phone: +46 730783289
	Email: ingemar.s.johansson@ericsson.com		Email: ingemar.s.johansson@ericsson.com
End of changes. 74 change blocks.
	171 lines changed or deleted		199 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/