draft-ietf-tcpm-cubic-04.txt		draft-ietf-tcpm-cubic-05.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: August 8, 2017 UNL		Expires: January 18, 2018 UNL
	S. Ha		S. Ha
	Colorado		Colorado
	A. Zimmermann		A. Zimmermann
	L. Eggert		L. Eggert
	NetApp		NetApp
	R. Scheffenegger		R. Scheffenegger
	February 4, 2017		July 17, 2017
	CUBIC for Fast Long-Distance Networks		CUBIC for Fast Long-Distance Networks
	draft-ietf-tcpm-cubic-04		draft-ietf-tcpm-cubic-05
	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 function of the		cubic function instead of a linear window increase function of the
	current TCP standards to improve scalability and stability under fast		current TCP standards to improve scalability and stability under fast
	and long distance networks. CUBIC and its predecessor algorithm have		and long distance networks. CUBIC and its predecessor algorithm have
	been adopted as default by Linux and have been used for many years.		been adopted as default by Linux and have been used for many years.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 August 8, 2017.		This Internet-Draft will expire on January 18, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(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 33 ¶		skipping to change at page 2, line 33 ¶
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4		3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4
	4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5		4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5
	4.1. Window growth function . . . . . . . . . . . . . . . . . 6		4.1. Window growth function . . . . . . . . . . . . . . . . . 6
	4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7		4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7
	4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7		4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7		4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7
	4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8		4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8
	4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8		4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8
	4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9
			4.8. Slowstart . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 9		5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 10
	5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11		5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11
	5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12		5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12
	5.4. Investigating a Range of Environments . . . . . . . . . . 12		5.4. Investigating a Range of Environments . . . . . . . . . . 12
	5.5. Protection against Congestion Collapse . . . . . . . . . 12		5.5. Protection against Congestion Collapse . . . . . . . . . 13
	5.6. Fairness within the Alternative Congestion Control		5.6. Fairness within the Alternative Congestion Control
	Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 12		Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 13
	5.7. Performance with Misbehaving Nodes and Outside Attackers 12		5.7. Performance with Misbehaving Nodes and Outside Attackers 13
	5.8. Behavior for Application-Limited Flows . . . . . . . . . 12		5.8. Behavior for Application-Limited Flows . . . . . . . . . 13
	5.9. Responses to Sudden or Transient Events . . . . . . . . . 13		5.9. Responses to Sudden or Transient Events . . . . . . . . . 13
	5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13		5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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
	the range of congestion window sizes over several hundreds of packets		the range of congestion window sizes over several hundreds of packets
	(each packet is sized around 1000 bytes) especially under a network		(each packet is sized around 1000 bytes) especially under a network
	path with over 100ms round-trip times (RTTs). This problem is		path with over 100ms round-trip times (RTTs). This problem is
	equally applicable to all Reno style TCP standards and their		equally applicable to all Reno style TCP standards and their
	variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP-		variants, including TCP-RENO [RFC5681], TCP-NewReno
	SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same		[RFC6582][RFC6675], 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. Specifically, it uses		Standard TCP senders, to remedy this problem. Specifically, it uses
	a cubic function instead of a linear window increase function of the		a cubic function instead of a linear window increase function of the
	Standrad TCP to improve scalability and stability under fast and long		Standrad TCP to improve scalability and stability under fast and long
	distance networks.		distance networks.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	4. CUBIC Congestion Control		4. CUBIC Congestion Control
	The unit of all window sizes in this document is segments of the		The unit of all window sizes in this document is segments of the
	maximum segment size (MSS), and the unit of all times is seconds.		maximum segment size (MSS), and the unit of all times is seconds.
	4.1. Window growth function		4.1. Window growth function
	CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by		CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by
	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] [RFC6675]. During congestion
	congestion avoidance after fast recovery, CUBIC changes the window		avoidance after fast recovery, CUBIC changes the window update
	update algorithm of Standard TCP. Suppose that W_max is the window		algorithm of Standard TCP. Suppose that W_max is the window size
	size before the window is reduced in the last fast retransmit and		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 that is measured right after the fast recovery in		window reduction that is measured right after the fast recovery in
	response to duplicate ACKs or after the congestion window reduction		response to duplicate ACKs or after the congestion window reduction
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	function takes to increase the current window size to W_max if there		function takes to increase the current window size to W_max if there
	is no further loss event and is calculated by using the following		is no further loss event and is calculated by using the following
	equation:		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 detected by duplicate ACKs or a network		is, when a packet loss detected by duplicate ACKs or a network
	congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its		congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its
	current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how		current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how
	we set C in the next Section in more details.		we set beta_cubic in Section 4.5 and how we set C in Section 5.
	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.		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
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	(1.5/p)^0.5, as the Standard TCP is a special case of AIMD with		(1.5/p)^0.5, as the Standard TCP is a special case of AIMD with
	alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as		alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as
	that of Standard TCP, alpha_aimd must be equal to		that of Standard TCP, alpha_aimd must be equal to
	3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by		3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by
	alpha_aimd per RTT, we can get the window size of AIMD in terms of		alpha_aimd per RTT, we can get the window size of AIMD in terms of
	the elapsed time t as follows:		the elapsed time t as follows:
	W_aimd(t) = W_max*beta_aimd +		W_aimd(t) = W_max*beta_aimd +
	[3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)		[3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)
	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) (it does not matter whether cwnd
			is greater than or less than W_max), 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.
	4.3. Concave region		4.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.		where W_cubic(t+RTT) is calculated using Eq. 1.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	room for growth if the existing flows have been using all the		room for growth if the existing flows have been using all the
	bandwidth of the network. To increase this release of bandwidth by		bandwidth of the network. To increase this release of bandwidth by
	existing flows, the following mechanism called fast convergence		existing flows, the following mechanism called fast convergence
	SHOULD be implemented.		SHOULD be implemented.
	With fast convergence, when a loss event occurs, before a window		With fast convergence, when a loss event occurs, before a window
	reduction of congestion window, a flow remembers the last value of		reduction of congestion window, a flow remembers the last value of
	W_max before it updates W_max for the current loss event. Let us		W_max before it updates W_max for the current loss event. Let us
	call the last value of W_max to be W_last_max.		call the last value of W_max to be W_last_max.
	if (W_max < W_last_max){ // check downward trend		if (W_max < W_last_max){ // should we make room for others
	W_last_max = W_max; // remember the last W_max		W_last_max = W_max; // remember the last W_max
	W_max = W_max*(1+beta_cubic)/2; // further reduce W_max		W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
	} else { // check upward trend		} else {
	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		At a loss event, if the current value of W_max is less than
	flows spend most of time around their W_max, flows with larger		W_last_max, this indicates that the saturation point experienced by
	bandwidth shares tend to spend more time around the plateau allowing		this flow is getting reduced because of the change in available
	more time for flows with smaller shares to increase their windows.		bandwidth. Then we allow this flow to release more bandwidth by
			reducing W_max further. This action effectively lengthens the time
			for this flow to increase its window because the reduced W_max forces
			the flow to have the plateau earlier. This allows more time for the
			new flow to catch up its window size
			The fast convergence is designed for network environments with
			multiple CUBIC flows. In network environments with only a single
			CUBIC flow and without any other traffic, the fast convergence SHOULD
			be disabled.
	4.7. Timeout		4.7. Timeout
	In case of timeout, CUBIC follows the standard TCP to reduce cwnd,		In case of timeout, CUBIC follows the standard TCP to reduce cwnd,
	but sets ssthresh using beta_cubic (same as in Section 4.5).		but sets ssthresh using beta_cubic (same as in Section 4.5).
			4.8. Slowstart
			CUBIC MUST employ a slow start algorithm, when the cwnd is no more
			than ssthresh. Among the slow start algorithms, CUBIC MAY choose the
			standard TCP slow start[RFC5681] in general networks, or the limited
			slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth
			and long-distance networks.
	5. Discussion		5. Discussion
	In this section, we further discuss the safety features of CUBIC		In this section, we further discuss the safety features of CUBIC
	following the guidelines specified in [RFC5033].		following the guidelines specified in [RFC5033].
	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:
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 38 ¶
	packets. If the packet size is 1500 bytes, then TCP can achieve an		packets. If the packet size is 1500 bytes, then TCP can achieve an
	average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4		average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4
	achieves exactly the same rate as Standard TCP, whereas HSTCP is		achieves exactly the same rate as Standard TCP, whereas HSTCP is
	about ten times more aggressive than Standard TCP.		about ten times more aggressive than Standard TCP.
	We can see that C determines the aggressiveness of CUBIC in competing		We can see that C determines the aggressiveness of CUBIC in competing
	with other protocols for the bandwidth. CUBIC is more friendly to		with other protocols for the bandwidth. CUBIC is more friendly to
	the Standard TCP, if the value of C is lower. However, we do not		the Standard TCP, if the value of C is lower. However, we do not
	recommend to set C to a very low value like 0.04, since CUBIC with a		recommend to set C to a very low value like 0.04, since CUBIC with a
	low C cannot efficiently use the bandwidth in long RTT and high		low C cannot efficiently use the bandwidth in long RTT and high
	bandwidth networks. Based on these observations, we find C=0.4 gives		bandwidth networks. Based on these observations and our experiments,
	a good balance between TCP-friendliness and aggressiveness of window		we find C=0.4 gives a good balance between TCP-friendliness and
	growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6		aggressiveness of window growth. Therefore, C SHOULD be set to 0.4.
	is reduced to:		With C set to 0.4, Eq. 6 is reduced to:
	AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)		AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)
	Eq. 7 is then used in the next subsection to show the scalability of		Eq. 7 is then used in the next subsection to show the scalability of
	CUBIC.		CUBIC.
	5.2. Using Spare Capacity		5.2. Using Spare Capacity
	CUBIC uses a more aggressive window growth function than Standard TCP		CUBIC uses a more aggressive window growth function than Standard TCP
	under long RTT and high bandwidth networks.		under long RTT and high bandwidth networks.
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 42 ¶
	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.		distance networks.
	5.4. Investigating a Range of Environments		5.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].
	Same as Standard TCP, CUBIC is a loss-based congestion control		Same as Standard TCP, CUBIC is a loss-based congestion control
	algorithm. Therefore, CUBIC, which is designed to be more aggressive		algorithm. Because CUBIC is designed to be more aggressive (due to
	than Standard TCP in fast and long distance networks, can fill large		faster window growth function and bigger multiplicative decrease
	drop-tail buffers more quickly than Standard TCP. In this case,		factor) than Standard TCP in fast and long distance networks, it can
	proper queue sizing and management [RFC7567] could be used to reduce		fill large drop-tail buffers more quickly than Standard TCP and
	the packet queueing delay.		increase the risk of a standing queue[KWAF16]. In this case, proper
			queue sizing and management [RFC7567] could be used to reduce the
			packet queueing delay.
	5.5. Protection against Congestion Collapse		5.5. Protection against Congestion Collapse
	With regard to the potential of causing congestion collapse, CUBIC		With regard to the potential of causing congestion collapse, CUBIC
	behaves like standard TCP since CUBIC modifies only the window		behaves like standard TCP since CUBIC modifies only the window
	adjustment algorithm of TCP. Thus, it does not modify the ACK		adjustment algorithm of TCP. Thus, it does not modify the ACK
	clocking and Timeout behaviors of Standard TCP.		clocking and Timeout behaviors of Standard TCP.
	5.6. Fairness within the Alternative Congestion Control Algorithm.		5.6. Fairness within the Alternative Congestion Control Algorithm.
	skipping to change at page 12, line 52 ¶		skipping to change at page 13, line 29 ¶
	link.		link.
	5.7. Performance with Misbehaving Nodes and Outside Attackers		5.7. Performance with Misbehaving Nodes and Outside Attackers
	This is not considered in the current CUBIC.		This is not considered in the current CUBIC.
	5.8. Behavior for Application-Limited Flows		5.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 MUST NOT include the		window. In case of long periods when cwnd is not updated due to the
	idle time; otherwise, W_cubic(t) might be very high after restarting		application rate limit, such as idle periods, t in Eq. 1 MUST NOT
	from a long idle time.		include these periods; otherwise, W_cubic(t) might be very high after
			restarting from these periods.
	5.9. Responses to Sudden or Transient Events		5.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.
	5.10. Incremental Deployment		5.10. Incremental Deployment
	CUBIC requires only the change of TCP senders, and does not require		CUBIC requires only the change of TCP senders, and does not require
	any assistant of routers.		any assistant of routers.
	skipping to change at page 13, line 38 ¶		skipping to change at page 14, line 18 ¶
	European Union's Horizon 2020 research and innovation program		European Union's Horizon 2020 research and innovation program
	2014-2018 under grant agreement No. 644866 (SSICLOPS). This document		2014-2018 under grant agreement No. 644866 (SSICLOPS). This document
	reflects only the authors' views and the European Commission is not		reflects only the authors' views and the European Commission is not
	responsible for any use that may be made of the information it		responsible for any use that may be made of the information it
	contains.		contains.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
	Selective Acknowledgment Options", RFC 2018,
	DOI 10.17487/RFC2018, October 1996,
	<http://www.rfc-editor.org/info/rfc2018>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",		[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
	RFC 3649, DOI 10.17487/RFC3649, December 2003,		RFC 3649, DOI 10.17487/RFC3649, December 2003,
	<http://www.rfc-editor.org/info/rfc3649>.		<http://www.rfc-editor.org/info/rfc3649>.
			[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
			Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March
			2004, <http://www.rfc-editor.org/info/rfc3742>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<http://www.rfc-editor.org/info/rfc4960>.		<http://www.rfc-editor.org/info/rfc4960>.
	[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion		[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
	Control Algorithms", BCP 133, RFC 5033,		Control Algorithms", BCP 133, RFC 5033,
	DOI 10.17487/RFC5033, August 2007,		DOI 10.17487/RFC5033, August 2007,
	<http://www.rfc-editor.org/info/rfc5033>.		<http://www.rfc-editor.org/info/rfc5033>.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP		[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	skipping to change at page 14, line 28 ¶		skipping to change at page 15, line 5 ¶
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<http://www.rfc-editor.org/info/rfc5681>.		<http://www.rfc-editor.org/info/rfc5681>.
	[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The		[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
	NewReno Modification to TCP's Fast Recovery Algorithm",		NewReno Modification to TCP's Fast Recovery Algorithm",
	RFC 6582, DOI 10.17487/RFC6582, April 2012,		RFC 6582, DOI 10.17487/RFC6582, April 2012,
	<http://www.rfc-editor.org/info/rfc6582>.		<http://www.rfc-editor.org/info/rfc6582>.
			[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
			and Y. Nishida, "A Conservative Loss Recovery Algorithm
			Based on Selective Acknowledgment (SACK) for TCP",
			RFC 6675, DOI 10.17487/RFC6675, August 2012,
			<http://www.rfc-editor.org/info/rfc6675>.
	[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF		[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
	Recommendations Regarding Active Queue Management",		Recommendations Regarding Active Queue Management",
	BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,		BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
	<http://www.rfc-editor.org/info/rfc7567>.		<http://www.rfc-editor.org/info/rfc7567>.
	9.2. Informative References		9.2. Informative References
	[CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic		[CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic
	Ordering for Internet Congestion Control and its		Ordering for Internet Congestion Control and its
	Applications", In Proceedings of IEEE INFOCOM , May 2007.		Applications", In Proceedings of IEEE INFOCOM , May 2007.
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 35 ¶
	[GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary		[GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary
	Adjustment Algorithms", Technical Report TR2002-29,		Adjustment Algorithms", Technical Report TR2002-29,
	Department of Computer Sciences , The University of Texas		Department of Computer Sciences , The University of Texas
	at Austin , August 2002.		at Austin , August 2002.
	[HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step		[HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step
	toward Realistic Performance Evaluation of High-Speed TCP		toward Realistic Performance Evaluation of High-Speed TCP
	Variants", International Workshop on Protocols for Fast		Variants", International Workshop on Protocols for Fast
	Long-Distance Networks , February 2006.		Long-Distance Networks , February 2006.
			[HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth
			and Long-Distance Networks", International Workshop on
			Protocols for Fast Long-Distance Networks , 2008.
	[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly		[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly
	High-Speed TCP Variant", ACM SIGOPS Operating System		High-Speed TCP Variant", ACM SIGOPS Operating System
	Review , 2008.		Review , 2008.
	[K03] Kelly, T., "Scalable TCP: Improving Performance in		[K03] Kelly, T., "Scalable TCP: Improving Performance in
	HighSpeed Wide Area Networks", ACM SIGCOMM Computer		HighSpeed Wide Area Networks", ACM SIGCOMM Computer
	Communication Review , April 2003.		Communication Review , April 2003.
			[KWAF16] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
			"TCP Alternative Backoff with ECN (ABE)", Internet-draft,
			IETF work-in-progress draft-khademi-tcpm-
			alternativebackoff-ecn-01 , October 2016.
	[LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control		[LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control
	for High Bandwidth-Delay Product Paths", Internet-draft		for High Bandwidth-Delay Product Paths", Internet-draft
	draft-leith-tcp-htcp-06 , April 2008.		draft-leith-tcp-htcp-06 , April 2008.
	[XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase		[XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase
	Congestion Control for Fast, Long Distance Networks", In		Congestion Control for Fast, Long Distance Networks", In
	Proceedings of IEEE INFOCOM , March 2004.		Proceedings of IEEE INFOCOM , March 2004.
	Authors' Addresses		Authors' Addresses
End of changes. 25 change blocks.
	46 lines changed or deleted		82 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/