draft-ietf-rmcat-nada-05.txt		draft-ietf-rmcat-nada-06.txt
	Network Working Group X. Zhu		Network Working Group X. Zhu
	Internet-Draft R. Pan		Internet-Draft Cisco Systems
	Intended status: Experimental M. Ramalho		Intended status: Experimental R. Pan
	Expires: April 1, 2018 S. Mena		Expires: June 6, 2018 Pensando Systems
			M. Ramalho
			S. Mena
	P. Jones		P. Jones
	J. Fu		J. Fu
	Cisco Systems		Cisco Systems
	S. D'Aronco		S. D'Aronco
	EPFL		EPFL
	September 28, 2017		December 3, 2017
	NADA: A Unified Congestion Control Scheme for Real-Time Media		NADA: A Unified Congestion Control Scheme for Real-Time Media
	draft-ietf-rmcat-nada-05		draft-ietf-rmcat-nada-06
	Abstract		Abstract
	This document describes NADA (network-assisted dynamic adaptation), a		This document describes NADA (network-assisted dynamic adaptation), a
	novel congestion control scheme for interactive real-time media		novel congestion control scheme for interactive real-time media
	applications, such as video conferencing. In the proposed scheme,		applications, such as video conferencing. In the proposed scheme,
	the sender regulates its sending rate based on either implicit or		the sender regulates its sending rate based on either implicit or
	explicit congestion signaling, in a unified approach. The scheme can		explicit congestion signaling, in a unified approach. The scheme can
	benefit from explicit congestion notification (ECN) markings from		benefit from explicit congestion notification (ECN) markings from
	network nodes. It also maintains consistent sender behavior in the		network nodes. It also maintains consistent sender behavior in the
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 46 ¶
	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 1, 2018.		This Internet-Draft will expire on June 6, 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 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3		3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5		4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5
	4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5		4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5
	4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8		4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8
	4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10		4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10
	5. Practical Implementation of NADA . . . . . . . . . . . . . . 12		5. Practical Implementation of NADA . . . . . . . . . . . . . . 12
	5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12		5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12
	5.1.1. Estimation of one-way delay and queuing delay . . . . 12		5.1.1. Estimation of one-way delay and queuing delay . . . . 12
	5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12		5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13
	5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13		5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13
	5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13		5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13
	5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14		5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14
	5.2.2. Adjusting video target rate and sending rate . . . . 15		5.2.2. Adjusting video target rate and sending rate . . . . 15
	5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15		5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15
	6. Discussions and Further Investigations . . . . . . . . . . . 16		6. Discussions and Further Investigations . . . . . . . . . . . 16
	6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16		6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16
	6.2. Method for delay, loss, and marking ratio estimation . . 16		6.2. Method for delay, loss, and marking ratio estimation . . 16
	6.3. Impact of parameter values . . . . . . . . . . . . . . . 17		6.3. Impact of parameter values . . . . . . . . . . . . . . . 17
	6.4. Sender-based vs. receiver-based calculation . . . . . . . 18		6.4. Sender-based vs. receiver-based calculation . . . . . . . 18
	6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18		6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
	8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19		8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	11.1. Normative References . . . . . . . . . . . . . . . . . . 20		11.1. Normative References . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . 21		11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Network Node Operations . . . . . . . . . . . . . . 22		Appendix A. Network Node Operations . . . . . . . . . . . . . . 23
	A.1. Default behavior of drop tail queues . . . . . . . . . . 22		A.1. Default behavior of drop tail queues . . . . . . . . . . 23
	A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22		A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23
	A.3. Random Early Marking with Virtual Queues . . . . . . . . 23		A.3. Random Early Marking with Virtual Queues . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Interactive real-time media applications introduce a unique set of		Interactive real-time media applications introduce a unique set of
	challenges for congestion control. Unlike TCP, the mechanism used		challenges for congestion control. Unlike TCP, the mechanism used
	for real-time media needs to adapt quickly to instantaneous bandwidth		for real-time media needs to adapt quickly to instantaneous bandwidth
	changes, accommodate fluctuations in the output of video encoder rate		changes, accommodate fluctuations in the output of video encoder rate
	control, and cause low queuing delay over the network. An ideal		control, and cause low queuing delay over the network. An ideal
	scheme should also make effective use of all types of congestion		scheme should also make effective use of all types of congestion
	signals, including packet loss, queuing delay, and explicit		signals, including packet loss, queuing delay, and explicit
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	| p_mark | Estimated packet ECN marking ratio |		| p_mark | Estimated packet ECN marking ratio |
	| p_loss | Estimated packet loss ratio |		| p_loss | Estimated packet loss ratio |
	| x_curr | Aggregate congestion signal |		| x_curr | Aggregate congestion signal |
	| x_prev | Previous value of aggregate congestion signal |		| x_prev | Previous value of aggregate congestion signal |
	| x_diff | Change in aggregate congestion signal w.r.t. |		| x_diff | Change in aggregate congestion signal w.r.t. |
	| | its previous value: x_diff = x_curr - x_prev |		| | its previous value: x_diff = x_curr - x_prev |
	| rmode | Rate update mode: (0 = accelerated ramp-up; |		| rmode | Rate update mode: (0 = accelerated ramp-up; |
	| | 1 = gradual update) |		| | 1 = gradual update) |
	| gamma | Rate increase multiplier in accelerated ramp-up |		| gamma | Rate increase multiplier in accelerated ramp-up |
	| | mode |		| | mode |
	| tloss_int | Measured average loss interval |		| loss_int | Measured average loss interval in packet count |
	| tloss_exp | Time window for recently observed losses |		| loss_exp | Threshold value for setting the last observed |
			| | packet loss to expiration |
	| rtt | Estimated round-trip-time at sender |		| rtt | Estimated round-trip-time at sender |
	| buffer_len | Rate shaping buffer occupancy measured in bytes |		| buffer_len | Rate shaping buffer occupancy measured in bytes |
	+--------------+-------------------------------------------------+		+--------------+-------------------------------------------------+
	Figure 2: List of variables.		Figure 2: List of variables.
	+--------------+----------------------------------+----------------+		+--------------+----------------------------------+----------------+
	| Notation | Parameter Name | Default Value |		| Notation | Parameter Name | Default Value |
	+--------------+----------------------------------+----------------+		+--------------+----------------------------------+----------------+
	| PRIO | Weight of priority of the flow | 1.0		| PRIO | Weight of priority of the flow | 1.0
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 9 ¶
	| | supported by media encoder | |		| | supported by media encoder | |
	| XREF | Reference congestion level | 10ms |		| XREF | Reference congestion level | 10ms |
	| KAPPA | Scaling parameter for gradual | 0.5 |		| KAPPA | Scaling parameter for gradual | 0.5 |
	| | rate update calculation | |		| | rate update calculation | |
	| ETA | Scaling parameter for gradual | 2.0 |		| ETA | Scaling parameter for gradual | 2.0 |
	| | rate update calculation | |		| | rate update calculation | |
	| TAU | Upper bound of RTT in gradual | 500ms |		| TAU | Upper bound of RTT in gradual | 500ms |
	| | rate update calculation | |		| | rate update calculation | |
	| DELTA | Target feedback interval | 100ms |		| DELTA | Target feedback interval | 100ms |
	+..............+..................................+................+		+..............+..................................+................+
	| DFILT | Bound on filtering delay | 120ms |
	| LOGWIN | Observation window in time for | 500ms |		| LOGWIN | Observation window in time for | 500ms |
	| | calculating packet summary | |		| | calculating packet summary | |
	| | statistics at receiver | |		| | statistics at receiver | |
	| QEPS | Threshold for determining queuing| 10ms |		| QEPS | Threshold for determining queuing| 10ms |
	| | delay build up at receiver | |		| | delay build up at receiver | |
	| GAMMA_MAX | Upper bound on rate increase | 50% |		| DFILT | Bound on filtering delay | 120ms |
			| GAMMA_MAX | Upper bound on rate increase | 0.5 |
	| | ratio for accelerated ramp-up | |		| | ratio for accelerated ramp-up | |
	| QBOUND | Upper bound on self-inflicted | 50ms |		| QBOUND | Upper bound on self-inflicted | 50ms |
	| | queuing delay during ramp up | |		| | queuing delay during ramp up | |
	+..............+..................................+................+		+..............+..................................+................+
	| MULTILOSS | Multiplier for self-scaling the | 7. |		| MULTILOSS | Multiplier for self-scaling the | 7. |
	| | recent observation time window | |		| | expiration threshold of the last | |
	| | (tloss_exp) based on measured | |		| | observed loss (loss_exp) based on| |
	| | average loss interval (tloss_int)| |		| | measured average loss interval | |
			| | (loss_int) | |
	| QTH | Delay threshold for invoking | 50ms |		| QTH | Delay threshold for invoking | 50ms |
	| | non-linear warping | |		| | non-linear warping | |
	| LAMBDA | Scaling parameter in the | 0.5 |		| LAMBDA | Scaling parameter in the | 0.5 |
	| | exponent of non-linear warping | |		| | exponent of non-linear warping | |
	+..............+..................................+................+		+..............+..................................+................+
	| PLRREF | Reference packet loss ratio | 0.01 |		| PLRREF | Reference packet loss ratio | 0.01 |
	| PMRREF | Reference packet marking ratio | 0.01 |		| PMRREF | Reference packet marking ratio | 0.01 |
	| DLOSS | Reference delay penalty for loss | 10ms |		| DLOSS | Reference delay penalty for loss | 10ms |
	| | when packet loss ratio is at | |		| | when packet loss ratio is at | |
	| | PLRREF | |		| | PLRREF | |
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	On time to send a new feedback report (t_curr - t_last > DELTA):		On time to send a new feedback report (t_curr - t_last > DELTA):
	calculate non-linear warping of delay d_tilde if packet loss exists		calculate non-linear warping of delay d_tilde if packet loss exists
	calculate current aggregate congestion signal x_curr		calculate current aggregate congestion signal x_curr
	determine mode of rate adaptation for sender: rmode		determine mode of rate adaptation for sender: rmode
	send RTCP feedback report containing values of: rmode, x_curr, and r_recv		send RTCP feedback report containing values of: rmode, x_curr, and r_recv
	update t_last = t_curr		update t_last = t_curr
	In order for a delay-based flow to hold its ground when competing		In order for a delay-based flow to hold its ground when competing
	against loss-based flows (e.g., loss-based TCP), it is important to		against loss-based flows (e.g., loss-based TCP), it is important to
	distinguish between different levels of observed queuing delay. For		distinguish between different levels of observed queuing delay. For
	instance, a moderate queuing delay value below 100ms is likely self-		instance, over wired connections, a moderate queuing delay value
	inflicted or induced by other delay-based flows, whereas a high		below 100ms is likely self-inflicted or induced by other delay-based
	queuing delay value of several hundreds of milliseconds may indicate		flows, whereas a high queuing delay value of several hundreds of
	the presence of a loss-based flow that does not refrain from		milliseconds may indicate the presence of a loss-based flow that does
	increased delay.		not refrain from increased delay.
	If packet losses are observed within the previous time window of		If the last observed packet loss is within the expiration window of
	tloss_exp, the estimated queuing delay follows a non-linear warping:		loss_exp (measured in terms of packet counts), the estimated queuing
			delay follows a non-linear warping:
	/ d_queue, if d_queue<QTH;		/ d_queue, if d_queue<QTH;
	|		|
	d_tilde = < (1)		d_tilde = < (1)
	| (d_queue-QTH)		| (d_queue-QTH)
	\ QTH exp(-LAMBDA ---------------) , otherwise.		\ QTH exp(-LAMBDA ---------------) , otherwise.
	QTH		QTH
	In (1), the queuing delay value is unchanged when it is below the		In (1), the queuing delay value is unchanged when it is below the
	first threshold QTH; otherwise it is scaled down following a non-		first threshold QTH; otherwise it is scaled down following a non-
	linear curve. This non-linear warping is inspired by the delay-		linear curve. This non-linear warping is inspired by the delay-
	adaptive congestion windown backoff policy in [Budzisz-TON11], so as		adaptive congestion windown backoff policy in [Budzisz-TON11], so as
	to "gradually nudge" the controller to operate based on loss-induced		to "gradually nudge" the controller to operate based on loss-induced
	congestion signals when competing against loss-based flows. The		congestion signals when competing against loss-based flows. The
	exact form of the non-linear function has been simplified with		exact form of the non-linear function has been simplified with
	respect to [Budzisz-TON11].		respect to [Budzisz-TON11]. The value of the threshold QTH may need
			to tuned for different operational enviornments.
	The value of tloss_exp is configured to self-scale with the average		The value of loss_exp is configured to self-scale with the average
	loss interval tloss_int with a multiplier MULTILOSS:		packet loss interval loss_int with a multiplier MULTILOSS:
	tloss_exp = MULTILOSS * tloss_int.		loss_exp = MULTILOSS * loss_int.
	Estimation of the average loss interval tloss_int, in turn, follows		Estimation of the average loss interval loss_int, in turn, follows
	Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol		Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol
	[RFC5348].		[RFC5348].
	In practice, it is recommended to linearly interpolate between the		In practice, it is recommended to linearly interpolate between the
	warped (d_tilde) and non-warped (d_queue) values of the queuing delay		warped (d_tilde) and non-warped (d_queue) values of the queuing delay
	during the transitional period lasting for the duration of tloss_int.		during the transitional period lasting for the duration of loss_int.
	The aggregate congestion signal is:		The aggregate congestion signal is:
	x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2)		x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2)
	Here, DMARK is prescribed reference delay penalty associated with ECN		Here, DMARK is prescribed reference delay penalty associated with ECN
	markings at the reference marking ratio of PMRREF; DLOSS is		markings at the reference marking ratio of PMRREF; DLOSS is
	prescribed reference delay penalty associated with packet losses at		prescribed reference delay penalty associated with packet losses at
	the reference packet loss ratio of PLRREF. The value of DLOSS and		the reference packet loss ratio of PLRREF. The value of DLOSS and
	DMARK does not depend on configurations at the network node. Since		DMARK does not depend on configurations at the network node. Since
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 37 ¶
	The delay estimation process in NADA follows a similar approach as in		The delay estimation process in NADA follows a similar approach as in
	earlier delay-based congestion control schemes, such as LEDBAT		earlier delay-based congestion control schemes, such as LEDBAT
	[RFC6817]. Instead of relying on RTP timestamps, the NADA sender		[RFC6817]. Instead of relying on RTP timestamps, the NADA sender
	generates its own timestamp based on local system clock and embeds		generates its own timestamp based on local system clock and embeds
	that information in the transport packet header. The NADA receiver		that information in the transport packet header. The NADA receiver
	estimates the forward delay as having a constant base delay component		estimates the forward delay as having a constant base delay component
	plus a time varying queuing delay component. The base delay is		plus a time varying queuing delay component. The base delay is
	estimated as the minimum value of one-way delay observed over a		estimated as the minimum value of one-way delay observed over a
	relatively long period (e.g., tens of minutes), whereas the		relatively long period (e.g., tens of minutes), whereas the
	individual queuing delay value is taken to be the difference between		individual queuing delay value is taken to be the difference between
	one-way delay and base delay. All delay estimations are based on		one-way delay and base delay. By re-estimating the base delay
	sender timestamps with higher granularity than RTP timestamps.		periodically, one can avoid the potential issue of base delay
			expiration, whereby an earlier measured base delay value is no longer
			valid due to underlying route changes. All delay estimations are
			based on sender timestamps with a recommended granularity of 100
			microseconds or higher.
	The individual sample values of queuing delay should be further		The individual sample values of queuing delay should be further
	filtered against various non-congestion-induced noise, such as spikes		filtered against various non-congestion-induced noise, such as spikes
	due to processing "hiccup" at the network nodes. Current		due to processing "hiccup" at the network nodes. Therefore, instead
	implementation employs a 15-tap minimum filter over per-packet		of simply calculating the value of base delay using d_base =
	queuing delay estimates.		min(d_base, d_fwd), as expressed in Section 5.1, current
			implementation employs a minimum filter with a window size of 15
			samples over per-packet queuing delay values.
	5.1.2. Estimation of packet loss/marking ratio		5.1.2. Estimation of packet loss/marking ratio
	The receiver detects packet losses via gaps in the RTP sequence		The receiver detects packet losses via gaps in the RTP sequence
	numbers of received packets. Packets arriving out-of-order are		numbers of received packets. Packets arriving out-of-order are
	discarded, and count towards losses. The instantaneous packet loss		discarded, and count towards losses. The instantaneous packet loss
	ratio p_inst is estimated as the ratio between the number of missing		ratio p_inst is estimated as the ratio between the number of missing
	packets over the number of total transmitted packets within the		packets over the number of total transmitted packets within the
	recent observation window LOGWIN. The packet loss ratio p_loss is		recent observation window LOGWIN. The packet loss ratio p_loss is
	obtained after exponential smoothing:		obtained after exponential smoothing:
	skipping to change at page 16, line 50 ¶		skipping to change at page 16, line 50 ¶
	Therefore, comparing the pros and cons regarding which delay metric		Therefore, comparing the pros and cons regarding which delay metric
	to adopt can be kept as an orthogonal direction of investigation.		to adopt can be kept as an orthogonal direction of investigation.
	6.2. Method for delay, loss, and marking ratio estimation		6.2. Method for delay, loss, and marking ratio estimation
	Like other delay-based congestion control schemes, performance of		Like other delay-based congestion control schemes, performance of
	NADA depends on the accuracy of its delay measurement and estimation		NADA depends on the accuracy of its delay measurement and estimation
	module. Appendix A in [RFC6817] provides an extensive discussion on		module. Appendix A in [RFC6817] provides an extensive discussion on
	this aspect.		this aspect.
	The current recommended practice of simply applying a 15-tab minimum		The current recommended practice of applying minimum filter with a
	filter suffices in guarding against processing delay outliers		window size of 15 samples suffices in guarding against processing
	observed in wired connections. For wireless connections with a		delay outliers observed in wired connections. For wireless
	higher packet delay variation (PDV), more sophisticated techniques on		connections with a higher packet delay variation (PDV), more
	de-noising, outlier rejection, and trend analysis may be needed.		sophisticated techniques on de-noising, outlier rejection, and trend
			analysis may be needed.
	More sophisticated methods in packet loss ratio calculation, such as		More sophisticated methods in packet loss ratio calculation, such as
	that adopted by [Floyd-CCR00], will likely be beneficial. These		that adopted by [Floyd-CCR00], will likely be beneficial. These
	alternatives are currently under investigation.		alternatives are currently under investigation.
	6.3. Impact of parameter values		6.3. Impact of parameter values
	In the gradual rate update mode, the parameter TAU indicates the		In the gradual rate update mode, the parameter TAU indicates the
	upper bound of round-trip-time (RTT) in feedback control loop.		upper bound of round-trip-time (RTT) in feedback control loop.
	Typically, the observed feedback interval delta is close to the		Typically, the observed feedback interval delta is close to the
	skipping to change at page 17, line 37 ¶		skipping to change at page 17, line 38 ¶
	offset term. Finally, the scaling parameter KAPPA determines the		offset term. Finally, the scaling parameter KAPPA determines the
	overall speed of the adaptation and needs to strike a balance between		overall speed of the adaptation and needs to strike a balance between
	responsiveness and stability.		responsiveness and stability.
	The choice of the target feedback interval DELTA needs to strike the		The choice of the target feedback interval DELTA needs to strike the
	right balance between timely feedback and low RTCP feedback message		right balance between timely feedback and low RTCP feedback message
	counts. A target feedback interval of DELTA=100ms is recommended,		counts. A target feedback interval of DELTA=100ms is recommended,
	corresponding to a feedback bandwidth of 16Kbps with 200 bytes per		corresponding to a feedback bandwidth of 16Kbps with 200 bytes per
	feedback message --- approximately 1.6% overhead for a 1 Mbps flow.		feedback message --- approximately 1.6% overhead for a 1 Mbps flow.
	Furthermore, both simulation studies and frequency-domain analysis		Furthermore, both simulation studies and frequency-domain analysis
	have established that a feedback interval below 250ms will not break		have established that a feedback interval below 250ms (i.e., more
	up the feedback control loop of NADA congestion control.		frequently than 4 feedback messages per second) will not break up the
			feedback control loop of NADA congestion control.
	In calculating the non-linear warping of delay in (1), the current		In calculating the non-linear warping of delay in (1), the current
	design uses fixed values of QTH for determining whether to perform		design uses fixed values of QTH for determining whether to perform
	the non-linear warping). It is possible to adapt its value based on		the non-linear warping). Its value may need to be tuned for
	past observed patterns of queuing delay in the presence of packet		different operational enviornments (e.g., over wired vs. wireless
	losses.		connections). It is possible to adapt its value based on past
			observed patterns of queuing delay in the presence of packet losses.
			It needs to be noted that the non-linear warping mechanism may lead
			to multiple NADA streams stuck in loss-based mode when competing
			against each other.
	In calculating the aggregate congestion signal x_curr, the choice of		In calculating the aggregate congestion signal x_curr, the choice of
	DMARK and DLOSS influence the steady-state packet loss/marking ratio		DMARK and DLOSS influence the steady-state packet loss/marking ratio
	experienced by the flow at a given available bandwidth. Higher		experienced by the flow at a given available bandwidth. Higher
	values of DMARK and DLOSS result in lower steady-state loss/marking		values of DMARK and DLOSS result in lower steady-state loss/marking
	ratios, but are more susceptible to the impact of individual packet		ratios, but are more susceptible to the impact of individual packet
	loss/marking events. While the value of DMARK and DLOSS are fixed		loss/marking events. While the value of DMARK and DLOSS are fixed
	and predetermined in the current design, a scheme for automatically		and predetermined in the current design, a scheme for automatically
	tuning these values based on desired bandwidth sharing behavior in		tuning these values based on desired bandwidth sharing behavior in
	the presence of other competing loss-based flows (e.g., loss-based		the presence of other competing loss-based flows (e.g., loss-based
	skipping to change at page 18, line 51 ¶		skipping to change at page 19, line 14 ¶
	7. Implementation Status		7. Implementation Status
	The NADA scheme has been implemented in [ns-2] and [ns-3] simulation		The NADA scheme has been implemented in [ns-2] and [ns-3] simulation
	platforms. Extensive ns-2 simulation evaluations of an earlier		platforms. Extensive ns-2 simulation evaluations of an earlier
	version of the draft are documented in [Zhu-PV13]. Evaluation		version of the draft are documented in [Zhu-PV13]. Evaluation
	results of the current draft over several test cases in		results of the current draft over several test cases in
	[I-D.ietf-rmcat-eval-test] have been presented at recent IETF		[I-D.ietf-rmcat-eval-test] have been presented at recent IETF
	meetings [IETF-90][IETF-91]. Evaluation results of the current draft		meetings [IETF-90][IETF-91]. Evaluation results of the current draft
	over several test cases in [I-D.ietf-rmcat-wireless-tests] have been		over several test cases in [I-D.ietf-rmcat-wireless-tests] have been
	presented at [IETF-93].		presented at [IETF-93]. An open source implementation of NADA as
			part of a ns-3 module is available at [ns3-rmcat]
	The scheme has also been implemented and evaluated in a lab setting		The scheme has also been implemented and evaluated in a lab setting
	as described in [IETF-90]. Preliminary evaluation results of NADA in		as described in [IETF-90]. Preliminary evaluation results of NADA in
	single-flow and multi-flow scenarios have been presented in		single-flow and multi-flow scenarios have been presented in
	[IETF-91].		[IETF-91].
	8. Suggested Experiments		8. Suggested Experiments
	NADA has been extensively evaluated under various test scenarios,		NADA has been extensively evaluated under various test scenarios,
	including the collection of test cases specified by		including the collection of test cases specified by
	skipping to change at page 19, line 47 ¶		skipping to change at page 20, line 13 ¶
	slide shows).		slide shows).
	9. IANA Considerations		9. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank Randell Jesup, Luca De Cicco, Piers		The authors would like to thank Randell Jesup, Luca De Cicco, Piers
	O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes,		O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes,
	Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for		Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede
	their valuable questions and comments on earlier versions of this		Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their
	draft. Thanks to Charles Ganzhorn for contributing to the testbed-		various valuable review comments and feedback. Thanks to Charles
	based evaluation of NADA during an early stage of its development.		Ganzhorn for contributing to the testbed-based evaluation of NADA
			during an early stage of its development.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-rmcat-cc-codec-interactions]
	Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
	"Congestion Control and Codec interactions in RTP
	Applications", draft-ietf-rmcat-cc-codec-interactions-02
	(work in progress), March 2016.
	[I-D.ietf-rmcat-cc-requirements]
	Jesup, R. and Z. Sarker, "Congestion Control Requirements
	for Interactive Real-Time Media", draft-ietf-rmcat-cc-
	requirements-09 (work in progress), December 2014.
	[I-D.ietf-rmcat-eval-test]
	Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
	Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
	eval-test-05 (work in progress), April 2017.
	[I-D.ietf-rmcat-video-traffic-model]
	Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
	Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
	traffic-model-03 (work in progress), July 2017.
	[I-D.ietf-rmcat-wireless-tests]
	Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
	M. Ramalho, "Evaluation Test Cases for Interactive Real-
	Time Media over Wireless Networks", draft-ietf-rmcat-
	wireless-tests-04 (work in progress), May 2017.
	[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>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <https://www.rfc-editor.org/info/rfc3550>.		July 2003, <https://www.rfc-editor.org/info/rfc3550>.
			[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
			Friendly Rate Control (TFRC): Protocol Specification",
			RFC 5348, DOI 10.17487/RFC5348, September 2008,
			<https://www.rfc-editor.org/info/rfc5348>.
	[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>.
	11.2. Informative References		11.2. Informative References
	[Budzisz-TON11]		[Budzisz-TON11]
	Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and		Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
	R. Shorten, "On the Fair Coexistence of Loss- and Delay-		R. Shorten, "On the Fair Coexistence of Loss- and Delay-
	Based TCP", IEEE/ACM Transactions on Networking vol. 19,		Based TCP", IEEE/ACM Transactions on Networking vol. 19,
	no. 6, pp. 1811-1824, December 2011.		no. 6, pp. 1811-1824, December 2011.
	[Floyd-CCR00]		[Floyd-CCR00]
	Floyd, S., Handley, M., Padhye, J., and J. Widmer,		Floyd, S., Handley, M., Padhye, J., and J. Widmer,
	"Equation-based Congestion Control for Unicast		"Equation-based Congestion Control for Unicast
	Applications", ACM SIGCOMM Computer Communications		Applications", ACM SIGCOMM Computer Communications
	Review vol. 30, no. 4, pp. 43-56, October 2000.		Review vol. 30, no. 4, pp. 43-56, October 2000.
			[I-D.ietf-rmcat-cc-codec-interactions]
			Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
			"Congestion Control and Codec interactions in RTP
			Applications", draft-ietf-rmcat-cc-codec-interactions-02
			(work in progress), March 2016.
			[I-D.ietf-rmcat-cc-requirements]
			Jesup, R. and Z. Sarker, "Congestion Control Requirements
			for Interactive Real-Time Media", draft-ietf-rmcat-cc-
			requirements-09 (work in progress), December 2014.
			[I-D.ietf-rmcat-eval-test]
			Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
			Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
			eval-test-05 (work in progress), April 2017.
			[I-D.ietf-rmcat-video-traffic-model]
			Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
			Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
			traffic-model-03 (work in progress), July 2017.
			[I-D.ietf-rmcat-wireless-tests]
			Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
			M. Ramalho, "Evaluation Test Cases for Interactive Real-
			Time Media over Wireless Networks", draft-ietf-rmcat-
			wireless-tests-04 (work in progress), May 2017.
	[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,		[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
	"NADA Update: Algorithm, Implementation, and Test Case		"NADA Update: Algorithm, Implementation, and Test Case
	Evalua6on Results", July 2014,		Evalua6on Results", July 2014,
	<https://tools.ietf.org/agenda/90/slides/		<https://tools.ietf.org/agenda/90/slides/
	slides-90-rmcat-6.pdf>.		slides-90-rmcat-6.pdf>.
	[IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,		[IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
	Jones, P., and S. D'Aronco, "NADA Algorithm Update and		Jones, P., and S. D'Aronco, "NADA Algorithm Update and
	Test Case Evaluations", November 2014,		Test Case Evaluations", November 2014,
	<http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/		<http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/
	skipping to change at page 21, line 46 ¶		skipping to change at page 22, line 21 ¶
	[IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,		[IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C.,
	Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA",		Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA",
	July 2015, <https://www.ietf.org/proceedings/93/slides/		July 2015, <https://www.ietf.org/proceedings/93/slides/
	slides-93-rmcat-0.pdf>.		slides-93-rmcat-0.pdf>.
	[ns-2] "The Network Simulator - ns-2",		[ns-2] "The Network Simulator - ns-2",
	<http://www.isi.edu/nsnam/ns/>.		<http://www.isi.edu/nsnam/ns/>.
	[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.		[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.
			[ns3-rmcat]
			Fu, J., Mena, S., and X. Zhu, "NS3 open source module of
			IETF RMCAT congestion control protocols", November 2017,
			<https://github.com/cisco/ns3-rmcat>.
	[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,		[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
	S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,		S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
	Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,		Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
	S., Wroclawski, J., and L. Zhang, "Recommendations on		S., Wroclawski, J., and L. Zhang, "Recommendations on
	Queue Management and Congestion Avoidance in the		Queue Management and Congestion Avoidance in the
	Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,		Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
	<https://www.rfc-editor.org/info/rfc2309>.		<https://www.rfc-editor.org/info/rfc2309>.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification",
	RFC 5348, DOI 10.17487/RFC5348, September 2008,
	<https://www.rfc-editor.org/info/rfc5348>.
	[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three		[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
	Pre-Congestion Notification (PCN) States in the IP Header		Pre-Congestion Notification (PCN) States in the IP Header
	Using a Single Diffserv Codepoint (DSCP)", RFC 6660,		Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
	DOI 10.17487/RFC6660, July 2012,		DOI 10.17487/RFC6660, July 2012,
	<https://www.rfc-editor.org/info/rfc6660>.		<https://www.rfc-editor.org/info/rfc6660>.
	[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,
	<https://www.rfc-editor.org/info/rfc6817>.		<https://www.rfc-editor.org/info/rfc6817>.
	skipping to change at page 22, line 33 ¶		skipping to change at page 23, line 11 ¶
	Scheme for Low-Latency Interactive Video", in Proc. IEEE		Scheme for Low-Latency Interactive Video", in Proc. IEEE
	International Packet Video Workshop (PV'13) San Jose, CA,		International Packet Video Workshop (PV'13) San Jose, CA,
	USA, December 2013.		USA, December 2013.
	Appendix A. Network Node Operations		Appendix A. Network Node Operations
	NADA can work with different network queue management schemes and		NADA can work with different network queue management schemes and
	does not assume any specific network node operation. As an example,		does not assume any specific network node operation. As an example,
	this appendix describes three variants of queue management behavior		this appendix describes three variants of queue management behavior
	at the network node, leading to either implicit or explicit		at the network node, leading to either implicit or explicit
	congestion signals.		congestion signals. It needs to be acknowledged that NADA has not
			yet been tested with non-probabilistic ECN marking behaviors.
	In all three flavors described below, the network queue operates with		In all three flavors described below, the network queue operates with
	the simple first-in-first-out (FIFO) principle. There is no need to		the simple first-in-first-out (FIFO) principle. There is no need to
	maintain per-flow state. The system can scale easily with a large		maintain per-flow state. The system can scale easily with a large
	number of video flows and at high link capacity.		number of video flows and at high link capacity.
	A.1. Default behavior of drop tail queues		A.1. Default behavior of drop tail queues
	In a conventional network with drop tail or RED queues, congestion is		In a conventional network with drop tail or RED queues, congestion is
	inferred from the estimation of end-to-end delay and/or packet loss.		inferred from the estimation of end-to-end delay and/or packet loss.
	skipping to change at page 24, line 43 ¶		skipping to change at page 25, line 16 ¶
	Xiaoqing Zhu		Xiaoqing Zhu
	Cisco Systems		Cisco Systems
	12515 Research Blvd., Building 4		12515 Research Blvd., Building 4
	Austin, TX 78759		Austin, TX 78759
	USA		USA
	Email: xiaoqzhu@cisco.com		Email: xiaoqzhu@cisco.com
	Rong Pan		Rong Pan
	Cisco Systems		Pensando Systems
	3625 Cisco Way		1730 Technology Drive
	San Jose, CA 95134		San Jose, CA 95110
	USA		USA
	Email: ropan@cisco.com		Email: rong@pensando.io
	Michael A. Ramalho		Michael A. Ramalho
	Cisco Systems, Inc.		Cisco Systems, Inc.
	8000 Hawkins Road		8000 Hawkins Road
	Sarasota, FL 34241		Sarasota, FL 34241
	USA		USA
	Phone: +1 919 476 2038		Phone: +1 919 476 2038
	Email: mramalho@cisco.com		Email: mramalho@cisco.com
	Sergio Mena de la Cruz		Sergio Mena de la Cruz
End of changes. 34 change blocks.
	93 lines changed or deleted		120 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/