draft-ietf-rmcat-scream-cc-12.txt		draft-ietf-rmcat-scream-cc-13.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: April 26, 2018 October 23, 2017		Expires: April 29, 2018 October 26, 2017
	Self-Clocked Rate Adaptation for Multimedia		Self-Clocked Rate Adaptation for Multimedia
	draft-ietf-rmcat-scream-cc-12		draft-ietf-rmcat-scream-cc-13
	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 interactive video. The solution conforms to
	conservation principle and uses a hybrid loss and delay based		the packet conservation principle and uses a hybrid loss and delay
	congestion control algorithm. The algorithm is evaluated over both		based congestion control algorithm. The algorithm is evaluated over
	simulated Internet bottleneck scenarios as well as in a Long Term		both simulated Internet bottleneck scenarios as well as in a Long
	Evolution (LTE) system simulator and is shown to achieve both low		Term Evolution (LTE) system simulator and is shown to achieve both
	latency and high video throughput in these scenarios.		low 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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 26, 2018.		This Internet-Draft will expire on April 29, 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
	(https://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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	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 . . . . . . . . . . . . . . . . . . . . 10		4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 10
	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. Reaction to packets loss and ECN . . . . . . . . 16		4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 16
	4.1.2.2. Congestion window update . . . . . . . . . . . . 16		4.1.2.2. Congestion window update . . . . . . . . . . . . 16
	4.1.2.3. Competing flows compensation . . . . . . . . . . 19		4.1.2.3. Competing flows compensation . . . . . . . . . . 19
	4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21		4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21
	4.1.2.5. Send window calculation . . . . . . . . . . . . . 21		4.1.2.5. Send window calculation . . . . . . . . . . . . . 22
	4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 22		4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 23
	4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23		4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23
	4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23		4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23
	4.1.3. Media rate control . . . . . . . . . . . . . . . . . 23		4.1.3. Media rate control . . . . . . . . . . . . . . . . . 24
	4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 26		4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 27
	4.2.1. Requirements on feedback elements . . . . . . . . . . 26		4.2.1. Requirements on feedback elements . . . . . . . . . . 27
	4.2.2. Requirements on feedback intensity . . . . . . . . . 28		4.2.2. Requirements on feedback intensity . . . . . . . . . 29
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29
	6. Implementation status . . . . . . . . . . . . . . . . . . . . 30		6. Implementation status . . . . . . . . . . . . . . . . . . . . 30
	6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 30		6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 31
	6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31		6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31
	7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 31		7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 32
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 32		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	11. Change history . . . . . . . . . . . . . . . . . . . . . . . 32		11. Change history . . . . . . . . . . . . . . . . . . . . . . . 33
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.1. Normative References . . . . . . . . . . . . . . . . . . 34		12.1. Normative References . . . . . . . . . . . . . . . . . . 35
	12.2. Informative References . . . . . . . . . . . . . . . . . 34		12.2. Informative References . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	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 have to employ		Applications that are deployed in the Internet have to employ
	congestion control, to achieve robust performance and to avoid		congestion control, to achieve robust performance and to avoid
	congestion collapse in the Internet. Interactive realtime		congestion collapse in the Internet. Interactive realtime
	communication imposes a lot of requirements on the transport,		communication imposes a lot of requirements on the transport,
	therefore a robust, efficient rate adaptation for all access types is		therefore a robust, efficient rate adaptation for all access types is
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	operate over a large range in channel capacity. This memo describes		operate over a large range in channel capacity. This memo describes
	SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that		SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that
	implements congestion control for RTP streams [RFC3550]. While		implements congestion control for RTP streams [RFC3550]. While
	SCReAM was originally devised for WebRTC (Web Real-Time		SCReAM was originally devised for WebRTC (Web Real-Time
	Communication) [RFC7478], it can also be used for other applications		Communication) [RFC7478], it can also be used for other applications
	where congestion control of RTP streams is necessary. SCReAM is		where congestion control of RTP streams is necessary. SCReAM is
	based on the self-clocking principle of TCP and uses techniques		based on the self-clocking principle of TCP and uses techniques
	similar to what is used in the LEDBAT based rate adaptation algorithm		similar to what is used in the LEDBAT based rate adaptation algorithm
	[RFC6817]. SCReAM is not entirely self-clocked as it augments self-		[RFC6817]. SCReAM is not entirely self-clocked as it augments self-
	clocking with pacing and a minimum send rate.		clocking with pacing and a minimum send rate.
			SCReAM can take advantage of ECN (Explicit Congestion Notification)
			in cases where ECN is supported by the network and the hosts. ECN is
			however not required for the basic congestion control functionality
			in SCReAM.
	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 can 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
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 27 ¶
	denoted qdelay) along the transmission path. This information is		denoted qdelay) along the transmission path. This information is
	used to adjust the congestion window. The use of LEDBAT ensures that		used to adjust the congestion window. The use of LEDBAT ensures that
	the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that		the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that
	LEDBAT has certain inherent issues that makes it counteract its		LEDBAT has certain inherent issues that makes it counteract its
	purpose to achieve low delay. The general problem described in the		purpose to achieve low delay. The general problem described in the
	paper is that the base delay is offset by LEDBAT's own queue buildup.		paper is that the base delay is offset by LEDBAT's own queue buildup.
	The big difference with using LEDBAT in the SCReAM context lies in		The big difference with using LEDBAT in the SCReAM context lies in
	the fact that the source is rate limited and that it is required that		the fact that the source is rate limited and that it is required that
	the RTP queue is kept short (preferably empty). In addition the		the RTP queue is kept short (preferably empty). In addition the
	output from a video encoder is rarely constant bitrate, static		output from a video encoder is rarely constant bitrate, static
	content (talking heads) for instance gives almost zero video rate.		content (talking heads) for instance gives almost zero video bitrate.
	This gives two useful properties when LEDBAT is used with SCReAM that		This gives two useful properties when LEDBAT is used with SCReAM that
	help to avoid the issues described in [LEDBAT-delay-impact]:		help to avoid the issues described in [LEDBAT-delay-impact]:
	1. There is always a certain probability that SCReAM is short of		1. There is always a certain probability that SCReAM is short of
	data to transmit, which means that the network queue will run		data to transmit, which means that the network queue will run
	empty every once in a while.		empty every once in a while.
	2. The max video bitrate can be lower than the link capacity. If		2. The max video bitrate can be lower than the link capacity. If
	the max video bitrate is 5Mbps and the capacity is 10Mbps then		the max video bitrate is 5Mbps and the capacity is 10Mbps then
	the network queue will run empty.		the network queue will run empty.
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 25 ¶
	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 does not have to be initialized to this high value		target qdelay does not have to be initialized to this high value
	however as it would increase e2e delay and also make the rate		however as it would increase e2e delay and also make the rate
	control and 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.		Threshold for the detection of incipient congestion.
	QDELAY_TREND_TH (0.2)
	Averaging factor for qdelay_fraction_avg.
	MIN_CWND (3000byte)		MIN_CWND (3000byte)
	Minimum congestion window.		Minimum congestion window.
	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.9)
	CWND scale factor due to ECN event.		CWND scale factor due to ECN event.
	BETA_R (0.9)		BETA_R (0.9)
	Target rate scale factor due to loss event.		Target rate scale factor due to loss event.
	MSS (1000 byte)		MSS (1000 byte)
	Maximum segment size = Max RTP packet size.		Maximum segment size = Max RTP packet size.
	RATE_ADJUST_INTERVAL (0.2s)		RATE_ADJUST_INTERVAL (0.2s)
	Interval between media bitrate adjustments.		Interval between media bitrate adjustments.
	skipping to change at page 12, line 6 ¶		skipping to change at page 12, line 4 ¶
	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
	vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.		vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
	qdelay_fraction_avg (0.0)		qdelay_fraction_avg (0.0)
	EWMA filtered fractional qdelay.		EWMA (Exponentially Weighted Moving Average) filtered fractional
			qdelay.
	qdelay_fraction_hist[20] ({0,..,0})		qdelay_fraction_hist[20] ({0,..,0})
	Vector of the last 20 fractional qdelay samples.		Vector of the last 20 fractional qdelay samples.
	qdelay_trend (0.0)		qdelay_trend (0.0)
	qdelay trend, indicates incipient congestion.		qdelay trend, indicates incipient congestion.
	qdelay_trend_mem (0.0)		qdelay_trend_mem (0.0)
	Low pass filtered version of qdelay_trend.		Low pass filtered version of qdelay_trend.
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	Measured bitrate from the media encoder.		Measured bitrate from the media encoder.
	rate_media_median (0.0 bps)		rate_media_median (0.0 bps)
	Median value of rate_media, computed over more than 10s.		Median value of rate_media, computed over more than 10s.
	s_rtt (0.0s)		s_rtt (0.0s)
	Smoothed RTT [s], computed with a similar method to that described		Smoothed RTT [s], computed with a similar method to that described
	in [RFC6298].		in [RFC6298].
	rtp_queue_size (0 bits)		rtp_queue_size (0 bits)
	Size of RTP packets in queue.		Sum of the sizes of RTP packets in queue.
	rtp_size (0 byte)		rtp_size (0 byte)
	Size of the last transmitted RTP packet.		Size of the last transmitted RTP packet.
	loss_event_rate (0.0)		loss_event_rate (0.0)
	The estimated fraction of RTTs with lost packets detected.		The estimated fraction of RTTs with lost packets detected.
	4.1.2. Network congestion control		4.1.2. Network congestion control
	This section explains the network congestion control, it contains two		This section explains the network congestion control, it contains two
	skipping to change at page 14, line 34 ¶		skipping to change at page 14, line 34 ¶
	with the highest sequence number.		with the highest sequence number.
	o Accumulated number of ECN-CE marked packets (n_ECN).		o Accumulated number of ECN-CE marked packets (n_ECN).
	When the sender receives RTCP feedback, the qdelay is calculated as		When the sender receives RTCP feedback, the qdelay is calculated as
	outlined in [RFC6817]. A qdelay sample is obtained for each received		outlined in [RFC6817]. A qdelay sample is obtained for each received
	acknowledgement. No smoothing of the qdelay samples occur, however		acknowledgement. No smoothing of the qdelay samples occur, however
	some smoothing occurs anyway as the computation of the CWND is a low		some smoothing occurs anyway as the computation of the CWND is a low
	pass filter function. A number of variables are updated as		pass filter function. A number of variables are updated as
	illustrated by the pseudo code below, temporary variables are		illustrated by the pseudo code below, temporary variables are
	appended with '_t'. Note that the pseudo code does not show all		appended with '_t'. As mentioned in Section 7 , calculation of the
	details for reasons of readability, the reader is encouraged to look		proper congestion window and media bitrate may benefit from
	into the C++ code in [SCReAM-CPP-implementation] for the details.		additional optimizations for handling of very high and very low
			bitrates, and from additional damping to handle periodic packet
			bursts. Some such optimizations are implemented in
			[SCReAM-CPP-implementation], but they do not form part of the
			specification of SCReAM at this time.
	<CODE BEGINS>		<CODE BEGINS>
	update_variables(qdelay):		update_variables(qdelay):
	qdelay_fraction_t = qdelay/qdelay_target		qdelay_fraction_t = qdelay/qdelay_target
	# Calculate moving average		# Calculate moving average
	qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+		qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+
	QDELAY_WEIGHT*qdelay_fraction_t		QDELAY_WEIGHT*qdelay_fraction_t
	update_qdelay_fraction_hist(qdelay_fraction_t)		update_qdelay_fraction_hist(qdelay_fraction_t)
	# Compute the average of the values in qdelay_fraction_hist		# Compute the average of the values in qdelay_fraction_hist
	avg_t = average(qdelay_fraction_hist)		avg_t = average(qdelay_fraction_hist)
	skipping to change at page 15, line 49 ¶		skipping to change at page 15, line 49 ¶
	The autocorrelation function 'R' is defined as follows. Let x be a		The autocorrelation function 'R' is defined as follows. Let x be a
	vector constituting N values, the biased autocorrelation function for		vector constituting N values, the biased autocorrelation function for
	a given lag=k for the vector x is given by.		a given lag=k for the vector x is given by.
	n=N-k		n=N-k
	R(x,k) = SUM x(n)*x(n+k)		R(x,k) = SUM x(n)*x(n+k)
	n=1		n=1
	The prediction coefficient is further multiplied with		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 that could
	the effect that the same qdelay is sampled several times, this does		have the effect that the same qdelay is sampled several times, this
	however not pose any problem as the vector is only used to determine		does however not pose any problem as the vector is only used to
	if the qdelay is increasing or decreasing. The qdelay_trend is		determine if the qdelay is increasing or decreasing. The
	utilized in the media rate control to indicate incipient congestion		qdelay_trend is utilized in the media rate control to indicate
	and to determine when to exit from fast increase mode.		incipient congestion and to determine when to exit from fast increase
	qdelay_trend_mem is used to enforce a less aggressive rate increase		mode. qdelay_trend_mem is used to enforce a less aggressive rate
	after congestion events. The function		increase 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		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.4. 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 SHOULD be		loss event is detected, further detected lost RTP packets SHOULD be
	ignored for a full smoothed round trip time, the intention of this is		ignored for a full smoothed round trip time, the intention of this is
	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 32 ¶
	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.3. 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, examples are large FTP flows using loss
	by adjusting the qdelay_target.		based congestion control. The worst condition occurs when the
			bottleneck queues are of tail-drop type with a large buffer size.
			SCReAM takes care of such situations by adjusting the qdelay_target
			when loss based flows are detected, as given by the pseudo code
			below.
	<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))
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 43 ¶
	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)
	<CODE ENDS>		<CODE ENDS>
	The qdelay_target is adjusted differently, depending on if		Two temporary variables are calculated. qdelay_norm_avg_t is the long
	qdelay_norm_var_t is above or below a given value.		term average queue delay, qdelay_norm_var_t is the long term variance
	A low qdelay_norm_avg_t value indicates that the qdelay does not		of the queue delay. A high qdelay_norm_var_t indicates that the
	change rapidly. It is desired to avoid the case that the qdelay		queue delay changes, this can be an indication of reduced bottleneck
	target is increased due to self-congestion, indicated by a changing		bandwidth or that a competing flow has just entered. Thus, it
	qdelay and consequently an increased qdelay_norm_var_t. Still it		indicates that it is not safe to adjust the queue delay target.
	SHOULD be possible to increase the qdelay target if the qdelay
	continues to be high. This is a simple function with a certain risk		A low qdelay_norm_var_t indicates that the queue delay is relatively
	of both false positives and negatives. In the simulated LTE test		stable, the reason can be that the queue delay is low but it can also
	cases it manages competing FTP flows reasonably well at the same time		be an indication that a competing flow is filling up the bottleneck
	as generally avoiding accidental increases in the qdelay target. The		to the limit where packet losses may start to occur, in which case
	algorithm can however accidentally increase the qdelay target and		the queue delay will stay relatively high for a longer time.
	cause self-inflicted congestion in certain cases. If it is deemed
	unlikely that competing flows occur over the same bottleneck, the		The queue delay target is allowed to be increased if, either the loss
	algorithm described in this section MAY be turned off. However, when		event rate is above a given threshold or that qdelay_norm_var_t is
	sending over the Internet, often the network conditions are not known		low. Both these conditions indicate that a competing flow may be
	for sure. Therefore turning this algorithm off must be considered		present. In all other cases the queue delay target is decreased.
	with caution as that can lead to basically zero throughput if
	competing with other, loss based, traffic.		The function that adjusts the qdelay_target is simple and has a
			certain risk to produce both false positive and negatives, The case
			that self-inflicted congestion by the SCReAM algorithm may be falsely
			interpreted as the presence of competing loss based FTP flows is a
			false positive. The opposite case where the algorithm fails to
			detect the presence of a competing FTP flow is a false negative.
			Extensive simulations have shown that the algorithm performs well in
			LTE test cases and that it also performs well in simple bandwidth
			limited bottleneck test cases with competing FTP flows. It can
			however not be completely ruled out that this algorithm can fail.
			Especially the false positives can be problematic as the end to end
			delay can increase dramatically if the target queue delay is
			increased by accident as a result of self-inflicted congestion.
			If it is deemed unlikely that competing flows occur over the same
			bottleneck, the algorithm described in this section MAY be turned
			off. One such case can be QoS enabled bearers in 3GPP based access
			such as LTE. However, when sending over the Internet, often the
			network conditions are not known for sure and it is in general not
			possible to make safe assumptions on how a network is used and
			whether or not competing flows share the same bottleneck. 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.4. 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 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) [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
	skipping to change at page 21, line 41 ¶		skipping to change at page 22, line 17 ¶
	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.5. 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: Media sources such as video encoders generally
	larger or smaller extent. A strict rule can lead to that the		produce frames whose size always vary to a larger or smaller
	media bitrate will have difficulties to increase as the congestion		extent. The RTP queue absorbs the natural variations in frame
	window puts a too hard restriction on the media frame size		sizes. The RTP queue should however be as short as possible, to
	variation. This can lead to occasional queuing of RTP packets in		avoid that the end to end delay increases. To achieve that, the
	the RTP packet queue that will prevent bitrate increase.		media rate control takes the RTP queue size into account when the
			target bitrate for the media is computed. A strict 'send only
			when bytes in flight is less than the congestion window' rule can
			lead to that the RTP queue grows simply because the send window is
			limited, the effect of which would be that the target bitrate is
			pushed down. The consequence of this is that the congestion
			window will not increase, or will increase very slowly, because
			the congestion window is only allowed to increase when there is a
			sufficient amount of data in flight. The end effect is then that
			the media bitrate increases very slowly or not at all.
	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 can 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
	skipping to change at page 32, line 16 ¶		skipping to change at page 32, line 46 ¶
	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.
			o Experimentation with further improvements to the congestion window
			and media bitrate calculation. [SCReAM-CPP-implementation]
			implements some optimizations, not described in this memo, that
			improve performance slightly. Further experiments are likely to
			lead to more optimizations of the algorithm.
	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
	skipping to change at page 32, line 51 ¶		skipping to change at page 33, line 40 ¶
	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-11 to WG-12: Review comments from Joel Halbern and Mirja		o WG-12 to WG-13: IESG comments addressed
			o WG-11 to WG-12: Review comments from Joel Halpern and Mirja
	o WG-10 to WG-11: Review comments from Mirja		o WG-10 to WG-11: Review comments from Mirja
	o WG-9 to WG-10: Minor edits		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
	skipping to change at page 34, line 10 ¶		skipping to change at page 35, line 4 ¶
	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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[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.,
			"RTP Control Protocol Extended Reports (RTCP XR)",
			RFC 3611, DOI 10.17487/RFC3611, November 2003,
			<https://www.rfc-editor.org/info/rfc3611>.
	[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,
	<https://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, <https://www.rfc-editor.org/info/rfc5506>.		2009, <https://www.rfc-editor.org/info/rfc5506>.
	skipping to change at page 35, line 34 ¶		skipping to change at page 36, line 40 ¶
	[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.,
	"RTP Control Protocol Extended Reports (RTCP XR)",
	RFC 3611, DOI 10.17487/RFC3611, November 2003,
	<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, <https://www.rfc-editor.org/info/rfc6679>.		2012, <https://www.rfc-editor.org/info/rfc6679>.
	[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use Cases and Requirements", RFC 7478,		Time Communication Use Cases and Requirements", RFC 7478,
	DOI 10.17487/RFC7478, March 2015,		DOI 10.17487/RFC7478, March 2015,
	<https://www.rfc-editor.org/info/rfc7478>.		<https://www.rfc-editor.org/info/rfc7478>.
End of changes. 25 change blocks.
	82 lines changed or deleted		133 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/