draft-ietf-tcpm-cubic-02.txt		draft-ietf-tcpm-cubic-03.txt
	TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee		TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee
	Internet-Draft NCSU		Internet-Draft NCSU
	Intended status: Informational L. Xu		Intended status: Informational L. Xu
	Expires: February 6, 2017 UNL		Expires: June 5, 2017 UNL
	S. Ha		S. Ha
	Colorado		Colorado
	A. Zimmermann		A. Zimmermann
	L. Eggert		L. Eggert
	R. Scheffenegger
	NetApp		NetApp
	August 5, 2016		R. Scheffenegger
			December 2, 2016
	CUBIC for Fast Long-Distance Networks		CUBIC for Fast Long-Distance Networks
	draft-ietf-tcpm-cubic-02		draft-ietf-tcpm-cubic-03
	Abstract		Abstract
	CUBIC is an extension to the current TCP standards. The protocol		CUBIC is an extension to the current TCP standards. The protocol
	differs from the current TCP standards only in the congestion window		differs from the current TCP standards only in the congestion window
	adjustment function in the sender side. In particular, it uses a		adjustment function in the sender side. In particular, it uses a
	cubic function instead of a linear window increase of the current TCP		cubic function instead of a linear window increase of the current TCP
	standards to improve scalability and stability under fast and long		standards to improve scalability and stability under fast and long
	distance networks. BIC-TCP, a predecessor of CUBIC, has been a		distance networks. BIC-TCP, a predecessor of CUBIC, has been a
	default TCP adopted by Linux since year 2005 and has already been		default TCP adopted by Linux since year 2005 and has already been
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 6, 2017.		This Internet-Draft will expire on June 5, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 37 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5		3. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5
	3.1. Window growth function . . . . . . . . . . . . . . . . . 5		3.1. Window growth function . . . . . . . . . . . . . . . . . 5
	3.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 6		3.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 6
	3.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7		3.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7		3.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7
	3.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 7		3.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 7
	3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7		3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8
			3.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8		4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 9
	4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10		4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10
	4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11		4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11
	4.4. Investigating a Range of Environments . . . . . . . . . . 11		4.4. Investigating a Range of Environments . . . . . . . . . . 11
	4.5. Protection against Congestion Collapse . . . . . . . . . 11		4.5. Protection against Congestion Collapse . . . . . . . . . 11
	4.6. Fairness within the Alternative Congestion Control		4.6. Fairness within the Alternative Congestion Control
	Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11		Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11
	4.7. Performance with Misbehaving Nodes and Outside Attackers 11		4.7. Performance with Misbehaving Nodes and Outside Attackers 12
	4.8. Behavior for Application-Limited Flows . . . . . . . . . 11		4.8. Behavior for Application-Limited Flows . . . . . . . . . 12
	4.9. Responses to Sudden or Transient Events . . . . . . . . . 11		4.9. Responses to Sudden or Transient Events . . . . . . . . . 12
	4.10. Incremental Deployment . . . . . . . . . . . . . . . . . 12		4.10. Incremental Deployment . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The low utilization problem of TCP in fast long-distance networks is		The low utilization problem of TCP in fast long-distance networks is
	well documented in [K03][RFC3649]. This problem arises from a slow		well documented in [K03][RFC3649]. This problem arises from a slow
	increase of congestion window following a congestion event in a		increase of congestion window following a congestion event in a
	network with a large bandwidth delay product (BDP). Our experience		network with a large bandwidth delay product (BDP). Our experience
	[HKLRX06] indicates that this problem is frequently observed even in		[HKLRX06] indicates that this problem is frequently observed even in
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 31 ¶
	variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP-		variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP-
	SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same		SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same
	linear increase function for window growth, which we refer to		linear increase function for window growth, which we refer to
	collectively as Standard TCP below.		collectively as Standard TCP below.
	CUBIC [HRX08] is a modification to the congestion control mechanism		CUBIC [HRX08] is a modification to the congestion control mechanism
	of Standard TCP, in particular, to the window increase function of		of Standard TCP, in particular, to the window increase function of
	Standard TCP senders, to remedy this problem. It uses a cubic		Standard TCP senders, to remedy this problem. It uses a cubic
	increase function in terms of the elapsed time from the last		increase function in terms of the elapsed time from the last
	congestion event. While most alternative algorithms to Standard TCP		congestion event. While most alternative algorithms to Standard TCP
	uses a convex increase function where after a loss event, the window		uses a convex increase function where during congestion avoidance the
	increment is always increasing, CUBIC uses both the concave and		window increment is always increasing, CUBIC uses both the concave
	convex profiles of a cubic function for window increase. After a		and convex profiles of a cubic function for window increase. After a
	window reduction following a loss event, it registers the window size		window reduction following a loss event detected by duplicate ACKs,
	where it got the loss event as W_max and performs a multiplicative		it registers the window size where it got the loss event as W_max and
	decrease of congestion window and the regular fast recovery and		performs a multiplicative decrease of congestion window and the
	retransmit of Standard TCP. After it enters into congestion		regular fast recovery and retransmit of Standard TCP. After it
	avoidance from fast recovery, it starts to increase the window using		enters into congestion avoidance from fast recovery, it starts to
	the concave profile of the cubic function. The cubic function is set		increase the window using the concave profile of the cubic function.
	to have its plateau at W_max so the concave growth continues until		The cubic function is set to have its plateau at W_max so the concave
	the window size becomes W_max. After that, the cubic function turns		growth continues until the window size becomes W_max. After that,
	into a convex profile and the convex window growth begins. This		the cubic function turns into a convex profile and the convex window
	style of window adjustment (concave and then convex) improves		growth begins. This style of window adjustment (concave and then
	protocol and network stability while maintaining high network		convex) improves protocol and network stability while maintaining
	utilization [CEHRX07]. This is because the window size remains		high network utilization [CEHRX07]. This is because the window size
	almost constant, forming a plateau around W_max where network		remains almost constant, forming a plateau around W_max where network
	utilization is deemed highest and under steady state, most window		utilization is deemed highest and under steady state, most window
	size samples of CUBIC are close to W_max, thus promoting high network		size samples of CUBIC are close to W_max, thus promoting high network
	utilization and protocol stability. Note that protocols with convex		utilization and protocol stability. Note that protocols with convex
	increase functions have the maximum increments around W_max and		increase functions have the maximum increments around W_max and
	introduces a large number of packet bursts around the saturation		introduces a large number of packet bursts around the saturation
	point of the network, likely causing frequent global loss		point of the network, likely causing frequent global loss
	synchronizations.		synchronizations.
	Another notable feature of CUBIC is that its window increase rate is		Another notable feature of CUBIC is that its window increase rate is
	mostly independent of RTT, and follows a (cubic) function of the		mostly independent of RTT, and follows a (cubic) function of the
	elapsed time since the last loss event. This feature promotes per-		elapsed time from the beginning of congestion avoidance. This
	flow fairness to Standard TCP as well as RTT-fairness. Note that		feature promotes per-flow fairness to Standard TCP as well as RTT-
	Standard TCP performs well under short RTT and small bandwidth (or		fairness. Note that Standard TCP performs well under short RTT and
	small BDP) networks. Only in a large long RTT and large bandwidth		small bandwidth (or small BDP) networks. Only in a large long RTT
	(or large BDP) networks, it has the scalability problem. An		and large bandwidth (or large BDP) networks, it has the scalability
	alternative protocol to Standard TCP designed to be friendly to		problem. An alternative protocol to Standard TCP designed to be
	Standard TCP at a per-flow basis must operate to increase its window		friendly to Standard TCP at a per-flow basis must operate to increase
	much less aggressively in small BDP networks than in large BDP		its window much less aggressively in small BDP networks than in large
	networks. In CUBIC, its window growth rate is slowest around the		BDP networks. In CUBIC, its window growth rate is slowest around the
	inflection point of the cubic function and this function does not		inflection point of the cubic function and this function does not
	depend on RTT. In a smaller BDP network where Standard TCP flows are		depend on RTT. In a smaller BDP network where Standard TCP flows are
	working well, the absolute amount of the window decrease at a loss		working well, the absolute amount of the window decrease at a loss
	event is always smaller because of the multiplicative decrease.		event is always smaller because of the multiplicative decrease.
	Therefore, in CUBIC, the starting window size after a loss event from		Therefore, in CUBIC, the starting window size after a loss event from
	which the window starts to increase, is smaller in a smaller BDP		which the window starts to increase, is smaller in a smaller BDP
	network, thus falling nearer to the plateau of the cubic function		network, thus falling nearer to the plateau of the cubic function
	where the growth rate is slowest. By setting appropriate values of		where the growth rate is slowest. By setting appropriate values of
	the cubic function parameters, CUBIC sets its growth rate always no		the cubic function parameters, CUBIC sets its growth rate always no
	faster than Standard TCP around its inflection point. When the cubic		faster than Standard TCP around its inflection point. When the cubic
	function grows slower than the window of Standard TCP, CUBIC simply		function grows slower than the window of Standard TCP, CUBIC simply
	follows the window size of Standard TCP to ensure fairness to		follows the window size of Standard TCP to ensure fairness to
	Standard TCP in a small BDP network. We call this region where CUBIC		Standard TCP in a small BDP network. We call this region where CUBIC
	behaves like Standard TCP, the TCP-friendly region.		behaves like Standard TCP, the TCP-friendly region.
	CUBIC maintains the same window growth rate independent of RTTs		CUBIC maintains the same window growth rate independent of RTTs
	outside of the TCP-friendly region, and flows with different RTTs		outside of the TCP-friendly region, and flows with different RTTs
	have the similar window sizes under steady state when they operate		have the similar window sizes under steady state when they operate
	outside the TCP-friendly region. This ensures CUBIC flows with		outside the TCP-friendly region. This ensures CUBIC flows with
	different RTTs to have their bandwidth shares linearly proportional		different RTTs to have their bandwidth shares (approximately, window/
	to the inverse of their RTT ratio (the longer RTT, the smaller the		RTT) linearly proportional to the inverse of their RTT ratio (the
	share). This behavior is the same as that of Standard TCP under high		longer RTT, the smaller the share). This behavior is the same as
	statistical multiplexing environments where packet losses are		that of Standard TCP under high statistical multiplexing environments
	independent of individual flow rates. However, under low statistical		where packet losses are independent of individual flow rates.
	multiplexing environments, the bandwidth share ratio of Standard TCP		However, under low statistical multiplexing environments, the
	flows with different RTTs is squarely proportional to the inverse of		bandwidth share ratio of Standard TCP flows with different RTTs is
	their RTT ratio [XHR04]. CUBIC always ensures the linear ratio		squarely proportional to the inverse of their RTT ratio [XHR04].
	independent of the levels of statistical multiplexing. This is an		CUBIC always ensures the linear ratio independent of the levels of
	improvement over Standard TCP. While there is no consensus on a		statistical multiplexing. This is an improvement over Standard TCP.
	particular bandwidth share ratios of different RTT flows, we believe		While there is no consensus on a particular bandwidth share ratios of
	that under wired Internet, use of the linear share notion seems more		different RTT flows, we believe that under wired Internet, use of the
	reasonable than equal share or a higher order shares. HTCP [LS08]		linear share notion seems more reasonable than equal share or a
	currently uses the equal share.		higher order shares. HTCP [LS08] currently uses the equal share.
	CUBIC sets the multiplicative window decrease factor to 0.7 while		CUBIC sets the multiplicative window decrease factor to 0.7 while
	Standard TCP uses 0.5. While this improves the scalability of the		Standard TCP uses 0.5. While this improves the scalability of the
	protocol, a side effect of this decision is slower convergence		protocol, a side effect of this decision is slower convergence
	especially under low statistical multiplexing environments. This		especially under low statistical multiplexing environments. This
	design choice is following the observation that the author of HSTCP		design choice is following the observation that the author of HSTCP
	[RFC3649] has made along with other researchers (e.g., [GV02]): the		[RFC3649] has made along with other researchers (e.g., [GV02]): the
	current Internet becomes more asynchronous with less frequent loss		current Internet becomes more asynchronous with less frequent loss
	synchronizations with high statistical multiplexing. Under this		synchronizations with high statistical multiplexing. Under this
	environment, even strict MIMD can converge. CUBIC flows with the		environment, even strict MIMD can converge. CUBIC flows with the
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 47 ¶
	increasing congestion window only at the reception of ACK. The		increasing congestion window only at the reception of ACK. The
	protocol does not make any change to the fast recovery and retransmit		protocol does not make any change to the fast recovery and retransmit
	of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During		of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During
	congestion avoidance after fast recovery, CUBIC changes the window		congestion avoidance after fast recovery, CUBIC changes the window
	update algorithm of Standard TCP. Suppose that W_max is the window		update algorithm of Standard TCP. Suppose that W_max is the window
	size before the window is reduced in the last fast retransmit and		size before the window is reduced in the last fast retransmit and
	recovery.		recovery.
	The window growth function of CUBIC uses the following function:		The window growth function of CUBIC uses the following function:
	W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)		W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)
	where C is a constant fixed to determine the aggressiveness of window		where C is a constant fixed to determine the aggressiveness of window
	growth in high BDP networks, t is the elapsed time from the last		growth in high BDP networks, t is the elapsed time from the last
	window reduction (measured right after the fast recovery), and K is		window reduction (measured right after the fast recovery), and K is
	the time period that the above function takes to increase the current		the time period that the above function takes to increase the current
	window size to W_max if there is no further loss event and is		window size to W_max if there is no further loss event and is
	calculated by using the following equation:		calculated by using the following equation:
	K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)		K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)
	where beta_cubic is the CUBIC multiplication decrease factor, that		where beta_cubic is the CUBIC multiplication decrease factor, that
	is, when a packet loss occurs, CUBIC reduces its current window cwnd		is, when a packet loss (detected by duplicate ACKs) occurs, CUBIC
	to cwnd*beta_cubic. We discuss how we set C in the next Section in		reduces its current window cwnd to W_cubic(0)=W_max*beta_cubic. We
	more details.		discuss how we set C in the next Section in more details.
	Upon receiving an ACK during congestion avoidance, CUBIC computes the		Upon receiving an ACK during congestion avoidance, CUBIC computes the
	window growth rate during the next RTT period using Eq. 1. It sets		window growth rate during the next RTT period using Eq. 1. It sets
	W_cubic(t+RTT) as the candidate target value of congestion window.		W_cubic(t+RTT) as the candidate target value of congestion window,
			where RTT is the weithed average RTT calculated by the standard TCP.
	Depending on the value of the current window size cwnd, CUBIC runs in		Depending on the value of the current window size cwnd, CUBIC runs in
	three different modes. First, if cwnd is less than the window size		three different modes. First, if cwnd is less than the window size
	that Standard TCP would reach at time t after the last loss event,		that Standard TCP would reach at time t after the last loss event,
	then CUBIC is in the TCP friendly region (we describe below how to		then CUBIC is in the TCP friendly region (we describe below how to
	determine this window size of Standard TCP in term of time t).		determine this window size of Standard TCP in term of time t).
	Otherwise, if cwnd is less than W_max, then CUBIC is the concave		Otherwise, if cwnd is less than W_max, then CUBIC is the concave
	region, and if cwnd is larger than W_max, CUBIC is in the convex		region, and if cwnd is larger than W_max, CUBIC is in the convex
	region. Below, we describe the exact actions taken by CUBIC in each		region. Below, we describe the exact actions taken by CUBIC in each
	region.		region.
	3.2. TCP-friendly region		3.2. TCP-friendly region
			Standard TCP performs well in certain types of networks, for example,
			under short RTT and small bandwidth (or small BDP) networks. In
			these networks, we use the TCP-friendly region to ensure that CUBIC
			achieves at least the same throughput as the standard TCP.
	When receiving an ACK in congestion avoidance, we first check whether		When receiving an ACK in congestion avoidance, we first check whether
	the protocol is in the TCP region or not. This is done by estimating		the protocol is in the TCP region or not. This is done by estimating
	the average rate of the Standard TCP using a simple analysis		the average rate of the Standard TCP using a simple analysis
	described in [FHP00]. It considers the Standard TCP as a special		described in [FHP00]. It considers the Standard TCP as a special
	case of an Additive Increase and Multiplicative Decrease algorithm		case of an Additive Increase and Multiplicative Decrease algorithm
	(AIMD), which has an additive factor alpha_aimd and a multiplicative		(AIMD), which has an additive factor alpha_aimd and a multiplicative
	factor beta_aimd with the following function:		factor beta_aimd with the following function:
	AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /		AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
	(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)		(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 19 ¶
	If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP		If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP
	friendly region and cwnd SHOULD be set to W_aimd(t) at each reception		friendly region and cwnd SHOULD be set to W_aimd(t) at each reception
	of ACK.		of ACK.
	3.3. Concave region		3.3. Concave region
	When receiving an ACK in congestion avoidance, if the protocol is not		When receiving an ACK in congestion avoidance, if the protocol is not
	in the TCP-friendly region and cwnd is less than W_max, then the		in the TCP-friendly region and cwnd is less than W_max, then the
	protocol is in the concave region. In this region, cwnd MUST be		protocol is in the concave region. In this region, cwnd MUST be
	incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK.		incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK,
			where W_cubic(t+RTT) is calculated using Eq. 1.
	3.4. Convex region		3.4. Convex region
	When the current window size of CUBIC is larger than W_max, it passes		When the current window size of CUBIC is larger than W_max, it passes
	the plateau of the cubic function after which CUBIC follows the		the plateau of the cubic function after which CUBIC follows the
	convex profile of the cubic function. Since cwnd is larger than the		convex profile of the cubic function. Since cwnd is larger than the
	previous saturation point W_max, this indicates that the network		previous saturation point W_max, this indicates that the network
	conditions might have been perturbed since the last loss event,		conditions might have been perturbed since the last loss event,
	possibly implying more available bandwidth after some flow		possibly implying more available bandwidth after some flow
	departures. Since the Internet is highly asynchronous, some amount		departures. Since the Internet is highly asynchronous, some amount
	of perturbation is always possible without causing a major change in		of perturbation is always possible without causing a major change in
	available bandwidth. In this phase, CUBIC is being very careful by		available bandwidth. In this phase, CUBIC is being very careful by
	very slowly increasing its window size. The convex profile ensures		very slowly increasing its window size. The convex profile ensures
	that the window increases very slowly at the beginning and gradually		that the window increases very slowly at the beginning and gradually
	increases its growth rate. We also call this phase as the maximum		increases its growth rate. We also call this phase as the maximum
	probing phase since CUBIC is searching for a new W_max. In this		probing phase since CUBIC is searching for a new W_max. In this
	region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for		region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for
	each received ACK.		each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1.
	3.5. Multiplicative decrease		3.5. Multiplicative decrease
	When a packet loss occurs, CUBIC reduces its window size by a factor		When a packet loss (detected by duplicate ACKs) occurs, CUBIC updates
	of beta. Parameter beta_cubic SHOULD be set to 0.7.		its W_max, cwnd, and ssthresh (slow start threshold) as follows.
			Parameter beta_cubic SHOULD be set to 0.7.
	W_max = cwnd; // save window size before reduction		W_max = cwnd; // save window size before reduction
	cwnd = cwnd * beta_cubic; // window reduction		ssthresh = cwnd * beta_cubic; // new slow start threshold
			cwnd = cwnd * beta_cubic; // window reduction
	A side effect of setting beta_cubic to a bigger value than 0.5 is		A side effect of setting beta_cubic to a bigger value than 0.5 is
	slower convergence. We believe that while a more adaptive setting of		slower convergence. We believe that while a more adaptive setting of
	beta_cubic could result in faster convergence, it will make the		beta_cubic could result in faster convergence, it will make the
	analysis of the protocol much harder. This adaptive adjustment of		analysis of the protocol much harder. This adaptive adjustment of
	beta_cubic is an item for the next version of CUBIC.		beta_cubic is an item for the next version of CUBIC.
	3.6. Fast convergence		3.6. Fast convergence
	To improve the convergence speed of CUBIC, we add a heuristic in the		To improve the convergence speed of CUBIC, we add a heuristic in the
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 35 ¶
	W_max = W_max*(1+beta_cubic)/2; // further reduce W_max		W_max = W_max*(1+beta_cubic)/2; // further reduce W_max
	} else { // check upward trend		} else { // check upward trend
	W_last_max = W_max // remember the last W_max		W_last_max = W_max // remember the last W_max
	}		}
	This allows W_max to be slightly less than the original W_max. Since		This allows W_max to be slightly less than the original W_max. Since
	flows spend most of time around their W_max, flows with larger		flows spend most of time around their W_max, flows with larger
	bandwidth shares tend to spend more time around the plateau allowing		bandwidth shares tend to spend more time around the plateau allowing
	more time for flows with smaller shares to increase their windows.		more time for flows with smaller shares to increase their windows.
			3.7. Timeout
			In case of timeout, CUBIC follows the standard TCP to reduce cwnd,
			but sets ssthresh using beta_cubic (same as in Section 3.5).
	4. Discussion		4. Discussion
	With a deterministic loss model where the number of packets between		With a deterministic loss model where the number of packets between
	two successive lost events is always 1/p, CUBIC always operates with		two successive lost events is always 1/p, CUBIC always operates with
	the concave window profile which greatly simplifies the performance		the concave window profile which greatly simplifies the performance
	analysis of CUBIC. The average window size of CUBIC can be obtained		analysis of CUBIC. The average window size of CUBIC can be obtained
	by the following function:		by the following function:
	AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 *		AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 *
	(RTT^0.75) / (p^0.75) (Eq. 5)		(RTT^0.75) / (p^0.75) (Eq. 5)
	With beta_cubic set to 0.7, the above formula is reduced to:		With beta_cubic set to 0.7, the above formula is reduced to:
	AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6)		AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6)
	We will determine the value of C in the following subsection using		We will determine the value of C in the following subsection using
	Eq. 6.		Eq. 6.
	4.1. Fairness to standard TCP		4.1. Fairness to standard TCP
	In environments where standard TCP is able to make reasonable use of		In environments where standard TCP is able to make reasonable use of
	the available bandwidth, CUBIC does not significantly change this		the available bandwidth, CUBIC does not significantly change this
	state.		state.
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 33 ¶
	Table 3		Table 3
	Our test results in [HKLRX06] indicate that CUBIC uses the spare		Our test results in [HKLRX06] indicate that CUBIC uses the spare
	bandwidth left unused by existing Standard TCP flows in the same		bandwidth left unused by existing Standard TCP flows in the same
	bottleneck link without taking away much bandwidth from the existing		bottleneck link without taking away much bandwidth from the existing
	flows.		flows.
	4.3. Difficult Environments		4.3. Difficult Environments
	CUBIC is designed to remedy the poor performance of TCP in fast long-		CUBIC is designed to remedy the poor performance of TCP in fast long-
	distance networks. It is not designed for wireless networks.		distance networks.
	4.4. Investigating a Range of Environments		4.4. Investigating a Range of Environments
	CUBIC has been extensively studied by using both NS-2 simulation and		CUBIC has been extensively studied by using both NS-2 simulation and
	test-bed experiments covering a wide range of network environments.		test-bed experiments covering a wide range of network environments.
	More information can be found in [HKLRX06].		More information can be found in [HKLRX06].
	4.5. Protection against Congestion Collapse		4.5. Protection against Congestion Collapse
	In case that there is congestion collapse, CUBIC behaves likely		With regard to the potential of causing congestion collapse, CUBIC
	standard TCP since CUBIC modifies only the window adjustment		behaves like standard TCP since CUBIC modifies only the window
	algorithm of TCP. Thus, it does not modify the ACK clocking and		adjustment algorithm of TCP. Thus, it does not modify the ACK
	Timeout behaviors of Standard TCP.		clocking and Timeout behaviors of Standard TCP.
	4.6. Fairness within the Alternative Congestion Control Algorithm.		4.6. Fairness within the Alternative Congestion Control Algorithm.
	CUBIC ensures convergence of competing CUBIC flows with the same RTT		CUBIC ensures convergence of competing CUBIC flows with the same RTT
	in the same bottleneck links to an equal bandwidth share. When		in the same bottleneck links to an equal bandwidth share. When
	competing flows have different RTTs, their bandwidth shares are		competing flows have different RTTs, their bandwidth shares are
	linearly proportional to the inverse of their RTT ratios. This is		linearly proportional to the inverse of their RTT ratios. This is
	true independent of the level of statistical multiplexing in the		true independent of the level of statistical multiplexing in the
	link.		link.
	4.7. Performance with Misbehaving Nodes and Outside Attackers		4.7. Performance with Misbehaving Nodes and Outside Attackers
	This is not considered in the current CUBIC.		This is not considered in the current CUBIC.
	4.8. Behavior for Application-Limited Flows		4.8. Behavior for Application-Limited Flows
	CUBIC does not raise its congestion window size if the flow is		CUBIC does not raise its congestion window size if the flow is
	currently limited by the application instead of the congestion		currently limited by the application instead of the congestion
	window. In cases of idle periods, t in Eq. 1 should not include the		window. In cases of idle periods, t in Eq. 1 MUST NOT include the
	idle time; otherwise, W_cubic(t) might be very high after restarting		idle time; otherwise, W_cubic(t) might be very high after restarting
	from a long idle time.		from a long idle time.
	4.9. Responses to Sudden or Transient Events		4.9. Responses to Sudden or Transient Events
	In case that there is a sudden congestion, a routing change, or a		In case that there is a sudden congestion, a routing change, or a
	mobility event, CUBIC behaves the same as Standard TCP.		mobility event, CUBIC behaves the same as Standard TCP.
	4.10. Incremental Deployment		4.10. Incremental Deployment
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 44 ¶
	North Carolina State University		North Carolina State University
	Department of Computer Science		Department of Computer Science
	Raleigh, NC 27695-7534		Raleigh, NC 27695-7534
	US		US
	Email: rhee@ncsu.edu		Email: rhee@ncsu.edu
	Lisong Xu		Lisong Xu
	University of Nebraska-Lincoln		University of Nebraska-Lincoln
	Department of Computer Science and Engineering		Department of Computer Science and Engineering
	Lincoln, NE 68588-01150		Lincoln, NE 68588-0115
	US		US
	Email: xu@unl.edu		Email: xu@unl.edu
	Sangtae Ha		Sangtae Ha
	University of Colorado at Boulder		University of Colorado at Boulder
	Department of Computer Science		Department of Computer Science
	Boulder, CO 80309-0430		Boulder, CO 80309-0430
	US		US
	Email: sangtae.ha@colorado.edu		Email: sangtae.ha@colorado.edu
	Alexander Zimmermann		Alexander Zimmermann
	NetApp
	Sonnenallee 1
	Kirchheim 85551
	Germany
	Phone: +49 89 900594712		Phone: +49 175 5766838
	Email: alexander.zimmermann@netapp.com		Email: alexander.zimmermann@rwth-aachen.de
	Lars Eggert		Lars Eggert
	NetApp		NetApp
	Sonnenallee 1		Sonnenallee 1
	Kirchheim 85551		Kirchheim 85551
	Germany		Germany
	Phone: +49 151 12055791		Phone: +49 151 12055791
	Email: lars@netapp.com		Email: lars@netapp.com
	Richard Scheffenegger		Richard Scheffenegger
	NetApp
	Am Euro Platz 2
	Vienna 1120
	Austria
	Phone: +43 1 3676811 3146		Email: rscheff@gmx.at
	Email: rs@netapp.com
End of changes. 34 change blocks.
	81 lines changed or deleted		89 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/