draft-ietf-rmcat-scream-cc-11.txt		draft-ietf-rmcat-scream-cc-12.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 12, 2018 October 9, 2017		Expires: April 26, 2018 October 23, 2017
	Self-Clocked Rate Adaptation for Multimedia		Self-Clocked Rate Adaptation for Multimedia
	draft-ietf-rmcat-scream-cc-11		draft-ietf-rmcat-scream-cc-12
	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.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 12, 2018.		This Internet-Draft will expire on April 26, 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 20 ¶		skipping to change at page 2, line 20 ¶
	1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3		1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
	1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4		1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 15		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 . . . . . . . . . . 18		4.1.2.3. Competing flows compensation . . . . . . . . . . 19
	4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 20		4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21
	4.1.2.5. Send window calculation . . . . . . . . . . . . . 20		4.1.2.5. Send window calculation . . . . . . . . . . . . . 21
	4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 21		4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 22
	4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 22		4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23
	4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 22		4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23
	4.1.3. Media rate control . . . . . . . . . . . . . . . . . 22		4.1.3. Media rate control . . . . . . . . . . . . . . . . . 23
	4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25		4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 26
	4.2.1. Requirements on feedback elements . . . . . . . . . . 25		4.2.1. Requirements on feedback elements . . . . . . . . . . 26
	4.2.2. Requirements on feedback intensity . . . . . . . . . 27		4.2.2. Requirements on feedback intensity . . . . . . . . . 28
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29
	6. Implementation status . . . . . . . . . . . . . . . . . . . . 29		6. Implementation status . . . . . . . . . . . . . . . . . . . . 30
	6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29		6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 30
	6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 30		6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31
	7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30		7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 31
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 31		10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31		11. Change history . . . . . . . . . . . . . . . . . . . . . . . 32
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.1. Normative References . . . . . . . . . . . . . . . . . . 33		12.1. Normative References . . . . . . . . . . . . . . . . . . 34
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.2. Informative References . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	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 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	The network congestion control sets an upper limit on how much data		The network congestion control sets an upper limit on how much data
	can be in the network (bytes in flight); this limit is called CWND		can be in the network (bytes in flight); this limit is called CWND
	(congestion window) and is used in the sender transmission control.		(congestion window) and is used in the sender transmission control.
	The SCReAM congestion control method, uses techniques similar to		The SCReAM congestion control method, uses techniques similar to
	LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT,		LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT,
	it is not necessary to use synchronized clocks in sender and receiver		it is not necessary to use synchronized clocks in sender and receiver
	in order to compute the qdelay. It is however necessary that they		in order to compute the qdelay. It is however necessary that they
	use the same clock frequency, or that the clock frequency at the		use the same clock frequency, or that the clock frequency at the
	receiver can be inferred reliably by the sender.		receiver can be inferred reliably by the sender. Failure to meet
			this requirement leads to malfunction in the SCReAM congestion
			control algorithm due to incorrect estimation of the network queue
			delay.
	The SCReAM sender calculates the congestion window based on the		The SCReAM sender calculates the congestion window based on the
	feedback from the SCReAM receiver. The congestion window is allowed		feedback from the SCReAM receiver. The congestion window is allowed
	to increase if the qdelay is below a predefined qdelay target,		to increase if the qdelay is below a predefined qdelay target,
	otherwise the congestion window decreases. The qdelay target is		otherwise the congestion window decreases. The qdelay target is
	typically set to 50-100ms. This ensures that the queuing delay is		typically set to 50-100ms. This ensures that the queuing delay is
	kept low. The reaction to loss or ECN events leads to an instant		kept low. The reaction to loss or ECN events leads to an instant
	reduction of CWND. Note that the source rate limited nature of real		reduction of CWND. Note that the source rate limited nature of real
	time media such as video, typically means that the queuing delay will		time media such as video, typically means that the queuing delay will
	mostly be below the given delay target, this is contrary to the case		mostly be below the given delay target, this is contrary to the case
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 31 ¶
	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)		QDELAY_TREND_TH (0.2)
	Averaging factor for qdelay_fraction_avg.		Averaging factor for qdelay_fraction_avg.
	MIN_CWND (3000byte)		MIN_CWND (3000byte)
	Min CWND.		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.
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 34 ¶
	Guard factor against RTP queue buildup. This value MAY be subject		Guard factor against RTP queue buildup. This value MAY be subject
	to tuning depending on e.g media coder characteristics, experiments		to tuning depending on e.g media coder characteristics, experiments
	with H264 and VP8 indicate that 1.0 is a suitable value. See		with H264 and VP8 indicate that 1.0 is a suitable value. See
	[SCReAM-CPP-implementation] and [SCReAM-implementation-experience]		[SCReAM-CPP-implementation] and [SCReAM-implementation-experience]
	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 RTP_QDELAY_TH.
	QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.		QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend.
	T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be		T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be
	resumed, 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.		RATE_PACE_MIN (50000bps) Minimum pacing rate.
	4.1.1.2. State variables		4.1.1.2. State variables
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 20 ¶
	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.
	qdelay_norm_hist[100] ({0,..,0})		qdelay_norm_hist[100] ({0,..,0})
	Vector of the last 100 normalized qdelay samples.		Vector of the last 100 normalized qdelay samples.
	min_cwnd (2*MSS)
	Minimum congestion window.
	in_fast_increase (true)		in_fast_increase (true)
	True if in fast increase state.		True if in fast increase state.
	cwnd (min_cwnd)		cwnd (MIN_CWND)
	Congestion window.		Congestion window.
	bytes_newly_acked (0)		bytes_newly_acked (0)
	The number of bytes that was acknowledged with the last received		The number of bytes that was acknowledged with the last received
	acknowledgement i.e. bytes acknowledged since the last CWND update.		acknowledgement i.e. bytes acknowledged since the last CWND update.
			max_bytes_in_flight (0)
			The maximum number of bytes in flight over a sliding time window,
			i.e. transmitted but not yet acknowledged bytes.
	send_wnd (0)		send_wnd (0)
	Upper limit to how many bytes that can currently be transmitted.		Upper limit to how many bytes that can currently be transmitted.
	Updated when cwnd is updated and when RTP packet is transmitted.		Updated when cwnd is updated and when RTP packet is transmitted.
	target_bitrate (0 bps)		target_bitrate (0 bps)
	Media target bitrate.		Media target bitrate.
	target_bitrate_last_max (1 bps)		target_bitrate_last_max (1 bps)
	Media target bitrate inflection point i.e. the last known highest		Media target bitrate inflection point i.e. the last known highest
	target_bitrate. Used to limit bitrate increase speed close to the		target_bitrate. Used to limit bitrate increase speed close to the
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 8 ¶
	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'. Note that the pseudo code does not show all
	details for reasons of readability, the reader is encouraged to look		details for reasons of readability, the reader is encouraged to look
	into the C++ code in [SCReAM-CPP-implementation] for the details.		into the C++ code in [SCReAM-CPP-implementation] for the details.
	<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)
	# R is an autocorrelation function of qdelay_fraction_hist		# Compute the average of the values in qdelay_fraction_hist
	# at lag K		avg_t = average(qdelay_fraction_hist)
	a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0)		# R is an autocorrelation function of qdelay_fraction_hist,
	#calculate qdelay trend		# with the mean (DC component) removed, at lag K
	qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg))		# The subtraction of the scalar avg_t from
	#calculate a 'peak-hold' qdelay_trend, this gives a memory		# qdelay_fraction_hist is performed element-wise
	# of congestion in the past		a_t = R(qdelay_fraction_hist-avg_t,1)/
			R(qdelay_fraction_hist-avg_t,0)
			# Calculate qdelay trend
			qdelay_trend = min(1.0,max(0.0,a_t*qdelay_fraction_avg))
			# Calculate a 'peak-hold' qdelay_trend, this gives a memory
			# 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_t' has positive values if qdelay shows an increasing
	trend, thus an indication of congestion is obtained before the qdelay		or decreasing trend, thus an indication of congestion is obtained
	target is reached.		before the qdelay target is reached. As a side effect, also the case
			that qdelay decreases is taken as a sign of congestion, experiments
			have however shown that this is beneficial as varying queue delay up
			or down is an indication that the transmit rate is very close to the
			path capacity.
	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
	skipping to change at page 16, line 23 ¶		skipping to change at page 17, line 10 ¶
	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.
	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 ?
	if (in_fast_increase)		if (in_fast_increase)
	if (qdelay_trend >= QDELAY_TREND_TH)		if (qdelay_trend >= QDELAY_TREND_TH)
	# incipient congestion detected, exit fast increase		# Incipient congestion detected, exit fast increase
	in_fast_increase = false		in_fast_increase = false
	else		else
	# no congestion yet, increase cwnd if it		# No congestion yet, increase cwnd if it
	# is sufficiently used		# is sufficiently used
	# an additional slack of bytes_newly_acked is		# An additional slack of bytes_newly_acked is
	# added to ensure that CWND growth occurs		# added to ensure that CWND growth occurs
	# even when feedback is sparse		# even when feedback is sparse
	if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)		if (bytes_in_flight*1.5+bytes_newly_acked > cwnd)
	cwnd = cwnd+bytes_newly_acked		cwnd = cwnd+bytes_newly_acked
	end		end
	return		return
	end		end
	end		end
	# not in fast increase phase		# Not in fast increase phase
	# off_target calculated as with LEDBAT		# off_target calculated as with LEDBAT
	off_target_t = (qdelay_target - qdelay) / qdelay_target		off_target_t = (qdelay_target - qdelay) / qdelay_target
	gain_t = GAIN		gain_t = GAIN
	# adjust congestion window		# Adjust congestion window
	cwnd_delta_t =		cwnd_delta_t =
	gain_t * off_target_t * bytes_newly_acked * MSS / cwnd		gain_t * off_target_t * bytes_newly_acked * MSS / cwnd
	if (off_target_t > 0 &&		if (off_target_t > 0 &&
	bytes_in_flight*1.25+bytes_newly_acked <= cwnd)		bytes_in_flight*1.25+bytes_newly_acked <= cwnd)
	# no cwnd increase if window is underutilized		# No cwnd increase if window is underutilized
	# an additional slack of bytes_newly_acked is		# An additional slack of bytes_newly_acked is
	# added to ensure that CWND growth occurs		# added to ensure that CWND growth occurs
	# even when feedback is sparse		# even when feedback is sparse
	cwnd_delta_t = 0;		cwnd_delta_t = 0;
	end		end
	# apply delta		# Apply delta
	cwnd += cwnd_delta_t		cwnd += cwnd_delta_t
	# limit cwnd to the maximum number of bytes in flight		# limit cwnd to the maximum number of bytes in flight
	cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)		cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM)
	cwnd = max(cwnd, MIN_CWND)		cwnd = max(cwnd, MIN_CWND)
	<CODE ENDS>		<CODE ENDS>
	CWND is updated differently depending on whether the congestion		CWND is updated differently depending on whether the congestion
	control is in fast increase state or not, as controlled by the		control is in fast increase state or not, as controlled by the
	variable in_fast_increase.		variable in_fast_increase.
	When in fast increase state, the congestion window is increased with		When in fast increase state, the congestion window is increased with
	the number of newly acknowledged bytes as long as the window is		the number of newly acknowledged bytes as long as the window is
	sufficiently used. 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.
	skipping to change at page 18, line 24 ¶		skipping to change at page 19, line 21 ¶
	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]. However, [RFC6817] specifies that the CWND increase is		[RFC6817]. However, [RFC6817] specifies that the CWND increase is
	limited by an additional function controlled by a constant		limited by an additional function controlled by a constant
	ALLOWED_INCREASE. This additional limitation is removed in this		ALLOWED_INCREASE. This additional limitation is removed in this
	specification.		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.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
	skipping to change at page 24, line 10 ¶		skipping to change at page 25, line 10 ¶
	scale_t = max(0.2, min(1.0, (scale_t*4)^2))		scale_t = max(0.2, min(1.0, (scale_t*4)^2))
	# min scale_t value 0.2 as the bitrate should be allowed to		# min scale_t value 0.2 as the bitrate should be allowed to
	# increase at least slowly --> avoid locking the rate to		# increase at least slowly --> avoid locking the rate to
	# target_bitrate_last_max		# target_bitrate_last_max
	if (in_fast_increase = true)		if (in_fast_increase = true)
	increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL		increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL
	increment_t *= scale_t		increment_t *= scale_t
	target_bitrate += increment_t		target_bitrate += increment_t
	else		else
	current_rate_t = max(rate_transmit, rate_ack)		current_rate_t = max(rate_transmit, rate_ack)
	# compute a bitrate change		# Compute a bitrate change
	delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD*		delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD*
	queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size		queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size
	# limit a positive increase if close to target_bitrate_last_max		# Limit a positive increase if close to target_bitrate_last_max
	if (delta_rate_t > 0)		if (delta_rate_t > 0)
	delta_rate_t *= scale_t		delta_rate_t *= scale_t
	delta_rate_t =		delta_rate_t =
	min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL)		min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL)
	end		end
	target_bitrate += delta_rate_t		target_bitrate += delta_rate_t
	# force a slight reduction in bitrate if RTP queue		# Force a slight reduction in bitrate if RTP queue
	# builds up		# builds up
	rtp_queue_delay_t = rtp_queue_size/current_rate_t		rtp_queue_delay_t = rtp_queue_size/current_rate_t
	if (rtp_queue_delay_t > RTP_QDELAY_TH)		if (rtp_queue_delay_t > RTP_QDELAY_TH)
	target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY		target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY
	end		end
	end		end
	rate_media_limit_t =		rate_media_limit_t =
	max(current_rate_t, max(rate_media,rtp_rate_median))		max(current_rate_t, max(rate_media,rtp_rate_median))
	rate_media_limit_t *= (2.0-qdelay_trend_mem)		rate_media_limit_t *= (2.0-qdelay_trend_mem)
	skipping to change at page 27, line 36 ¶		skipping to change at page 28, line 36 ¶
	RECOMMENDED that a SCReAM implementation follows the guidelines		RECOMMENDED that a SCReAM implementation follows the guidelines
	below.		below.
	The feedback interval depends on the media bitrate. At low bitrates		The feedback interval depends on the media bitrate. At low bitrates
	it is sufficient with a feedback interval of 100 to 400ms, while at		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		high bitrates a feedback interval of roughly 20ms is to prefer, at
	very high bitrates, even shorter feedback intervals MAY be needed in		very high bitrates, even shorter feedback intervals MAY be needed in
	order to keep the self-clocking in SCReAM working well. One piece of		order to keep the self-clocking in SCReAM working well. One piece of
	evidence of a too sparse feedback is that the SCReAM implementation		evidence of a too sparse feedback is that the SCReAM implementation
	cannot reach high bitrates, even in uncongested links. A more		cannot reach high bitrates, even in uncongested links. A more
	frequent feedback MAY solve this issue.		frequent feedback might 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 31, line 51 ¶		skipping to change at page 32, line 51 ¶
	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-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
	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
	skipping to change at page 34, line 8 ¶		skipping to change at page 35, line 8 ¶
	[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-
	alternativebackoff-ecn-01 (work in progress), May 2017.		alternativebackoff-ecn-02 (work in progress), October
			2017.
	[I-D.ietf-tcpm-rack]		[I-D.ietf-tcpm-rack]
	Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-		Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time-
	based fast loss detection algorithm for TCP", draft-ietf-		based fast loss detection algorithm for TCP", draft-ietf-
	tcpm-rack-02 (work in progress), March 2017.		tcpm-rack-02 (work in progress), March 2017.
	[LEDBAT-delay-impact]		[LEDBAT-delay-impact]
	"Assessing LEDBAT's Delay Impact, IEEE communications		"Assessing LEDBAT's Delay Impact, IEEE communications
	letters, vol. 17, no. 5, May 2013", May 2013,		letters, vol. 17, no. 5, May 2013", May 2013,
	<http://home.ifi.uio.no/michawe/research/publications/		<http://home.ifi.uio.no/michawe/research/publications/
End of changes. 34 change blocks.
	64 lines changed or deleted		80 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/