draft-ietf-tcpm-cubic-01.txt		draft-ietf-tcpm-cubic-02.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: July 21, 2016 UNL		Expires: February 6, 2017 UNL
	S. Ha		S. Ha
	Colorado		Colorado
	A. Zimmermann		A. Zimmermann
	L. Eggert		L. Eggert
	R. Scheffenegger		R. Scheffenegger
	NetApp		NetApp
	January 18, 2016		August 5, 2016
	CUBIC for Fast Long-Distance Networks		CUBIC for Fast Long-Distance Networks
	draft-ietf-tcpm-cubic-01		draft-ietf-tcpm-cubic-02
	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 7 ¶
	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 July 21, 2016.		This Internet-Draft will expire on February 6, 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 44 ¶		skipping to change at page 2, line 44 ¶
	3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7		3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8		4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8
	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 11
	4.8. Responses to Sudden or Transient Events . . . . . . . . . 11		4.8. Behavior for Application-Limited Flows . . . . . . . . . 11
	4.9. Incremental Deployment . . . . . . . . . . . . . . . . . 11		4.9. Responses to Sudden or Transient Events . . . . . . . . . 11
			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 . . . . . . . . . . . . . . . . . . 12
	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
	the range of congestion window sizes over several hundreds of packets		the range of congestion window sizes over several hundreds of packets
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	3. CUBIC Congestion Control		3. 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.
	3.1. Window growth function		3.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-NewReno [RFC6582] and TCP-SACK [RFC2018]. During congestion		of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During
	avoidance after fast recovery, CUBIC changes the window update		congestion avoidance after fast recovery, CUBIC changes the window
	algorithm of Standard TCP. Suppose that W_max is the window size		update algorithm of Standard TCP. Suppose that W_max is the window
	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,and K is the time period that the above function		window reduction (measured right after the fast recovery), and K is
	takes to increase the current window size to W_max when there is no		the time period that the above function takes to increase the current
	further loss event and is calculated by using the following equation:		window size to W_max if there is no further loss event and is
			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 occurs, CUBIC reduces its current window cwnd
	to cwnd*beta_cubic. We discuss how we set C in the next Section in		to cwnd*beta_cubic. We discuss how we set C in the next Section in
	more details.		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
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 29 ¶
	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
	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 as follows.		the protocol is in the TCP region or not. This is done by estimating
	We can analyze the window size of a TCP-friendly AIMD in terms of the		the average rate of the Standard TCP using a simple analysis
	elapsed time t. Using a simple analysis in [FHP00], we can analyze		described in [FHP00]. It considers the Standard TCP as a special
	the average window size of additive increase and multiplicative		case of an Additive Increase and Multiplicative Decrease algorithm
	decrease (AIMD) with an additive factor alpha_aimd and a		(AIMD), which has an additive factor alpha_aimd and a multiplicative
	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)
	By the same analysis, the average window size of Standard TCP is		By the same analysis, the average window size of Standard TCP is
	(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
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	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. Responses to Sudden or Transient Events		4.8. Behavior for Application-Limited Flows
			CUBIC does not raise its congestion window size if the flow is
			currently limited by the application instead of the congestion
			window. In cases of idle periods, t in Eq. 1 should not include the
			idle time; otherwise, W_cubic(t) might be very high after restarting
			from a long idle time.
			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.9. Incremental Deployment		4.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.
	5. Security Considerations		5. Security Considerations
	This proposal makes no changes to the underlying security of TCP.		This proposal makes no changes to the underlying security of TCP.
	6. IANA Considerations		6. IANA Considerations
End of changes. 11 change blocks.
	22 lines changed or deleted		31 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/