draft-ietf-tcpm-cubic-00.txt | draft-ietf-tcpm-cubic-01.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: December 20, 2015 UNL | Expires: July 21, 2016 UNL | |||
S. Ha | S. Ha | |||
NCSU | Colorado | |||
A. Zimmermann | A. Zimmermann | |||
L. Eggert | L. Eggert | |||
R. Scheffenegger | R. Scheffenegger | |||
NetApp | NetApp | |||
June 18, 2015 | January 18, 2016 | |||
CUBIC for Fast Long-Distance Networks | CUBIC for Fast Long-Distance Networks | |||
draft-ietf-tcpm-cubic-00 | draft-ietf-tcpm-cubic-01 | |||
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 December 20, 2015. | This Internet-Draft will expire on July 21, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
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 . . . . . . . . . . . . . . . . . . . . . 6 | 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 10 | 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. Responses to Sudden or Transient Events . . . . . . . . . 11 | |||
4.9. Incremental Deployment . . . . . . . . . . . . . . . . . 11 | 4.9. Incremental Deployment . . . . . . . . . . . . . . . . . 11 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 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 . . . . . . . . . . . . . . . . . 12 | 8.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Appendix A. ToDo List . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
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 | |||
skipping to change at page 4, line 13 | skipping to change at page 4, line 13 | |||
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 since the last loss event. This feature promotes per- | |||
flow fairness to Standard TCP as well as RTT-fairness. Note that | flow fairness to Standard TCP as well as RTT-fairness. Note that | |||
Standard TCP performs well under short RTT and small bandwidth (or | Standard TCP performs well under short RTT and small bandwidth (or | |||
small BDP) networks. Only in a large long RTT and large bandwidth | small BDP) networks. Only in a large long RTT and large bandwidth | |||
(or large BDP) networks, it has the scalability problem. An | (or large BDP) networks, it has the scalability problem. An | |||
alternative protocol to Standard TCP designed to be friendly to | alternative protocol to Standard TCP designed to be friendly to | |||
Standard TCP at a per-flow basis must operate must increase its | Standard TCP at a per-flow basis must operate to increase its window | |||
window much less aggressively in small BDP networks than in large BDP | much less aggressively in small BDP networks than in large BDP | |||
networks. In CUBIC, its window growth rate is slowest around the | 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 | |||
skipping to change at page 4, line 50 | skipping to change at page 4, line 50 | |||
multiplexing environments, the bandwidth share ratio of Standard TCP | multiplexing environments, the bandwidth share ratio of Standard TCP | |||
flows with different RTTs is squarely proportional to the inverse of | flows with different RTTs is squarely proportional to the inverse of | |||
their RTT ratio [XHR04]. CUBIC always ensures the linear ratio | their RTT ratio [XHR04]. CUBIC always ensures the linear ratio | |||
independent of the levels of statistical multiplexing. This is an | independent of the levels of statistical multiplexing. This is an | |||
improvement over Standard TCP. While there is no consensus on a | improvement over Standard TCP. While there is no consensus on a | |||
particular bandwidth share ratios of different RTT flows, we believe | particular bandwidth share ratios of different RTT flows, we believe | |||
that under wired Internet, use of the linear share notion seems more | that under wired Internet, use of the linear share notion seems more | |||
reasonable than equal share or a higher order shares. HTCP [LS08] | reasonable than equal share or a higher order shares. HTCP [LS08] | |||
currently uses the equal share. | currently uses the equal share. | |||
CUBIC sets the multiplicative window decrease factor to 0.2 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 | |||
same RTT always converge to the same share of bandwidth independent | same RTT always converge to the same share of bandwidth independent | |||
of statistical multiplexing, thus achieving intra-protocol fairness. | of statistical multiplexing, thus achieving intra-protocol fairness. | |||
skipping to change at page 5, line 27 | skipping to change at page 5, line 27 | |||
specified in [RFC5033]. | specified in [RFC5033]. | |||
2. Conventions | 2. Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. CUBIC Congestion Control | 3. CUBIC Congestion Control | |||
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. | ||||
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-NewReno [RFC6582] and TCP-SACK [RFC2018]. During congestion | |||
avoidance after fast recovery, CUBIC changes the window update | avoidance after fast recovery, CUBIC changes the window update | |||
algorithm of Standard TCP. Suppose that W_max is the window size | algorithm of Standard TCP. Suppose that W_max is the window 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(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,and K is the time period that the above function | |||
takes to increase W to W_max when there is no further loss event and | takes to increase the current window size to W_max when there is no | |||
is calculated by using the following equation: | further loss event and is calculated by using the following equation: | |||
K = cubic_root(W_max*beta/C) (Eq. 2) | K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) | |||
where beta is the multiplication decrease factor. We discuss how we | where beta_cubic is the CUBIC multiplication decrease factor, that | |||
set C in the next Section in more details. | 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 | ||||
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(t+RTT) as the candidate target value of congestion window. Suppose | W_cubic(t+RTT) as the candidate target value of congestion window. | |||
that the current window size is cwnd. Depending on the value of | ||||
cwnd, CUBIC runs in three different modes. First, if cwnd is less | Depending on the value of the current window size cwnd, CUBIC runs in | |||
than the window size that Standard TCP would reach at time t after | three different modes. First, if cwnd is less than the window size | |||
the last loss event, then CUBIC is in the TCP friendly region (we | that Standard TCP would reach at time t after the last loss event, | |||
describe below how to determine this window size of Standard TCP in | then CUBIC is in the TCP friendly region (we describe below how to | |||
term of time t). Otherwise, if cwnd is less than W_max, then CUBIC | determine this window size of Standard TCP in term of time t). | |||
is the concave region, and if cwnd is larger than W_max, CUBIC is in | Otherwise, if cwnd is less than W_max, then CUBIC is the concave | |||
the convex region. Below, we describe the exact actions taken by | region, and if cwnd is larger than W_max, CUBIC is in the convex | |||
CUBIC in each region. | region. Below, we describe the exact actions taken by CUBIC in each | |||
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 as follows. | |||
We can analyze the window size of Standard TCP in terms of the | We can analyze the window size of a TCP-friendly AIMD in terms of the | |||
elapsed time t. Using a simple analysis in [FHP00], we can analyze | elapsed time t. Using a simple analysis in [FHP00], we can analyze | |||
the average window size of additive increase and multiplicative | the average window size of additive increase and multiplicative | |||
decrease (AIMD) with an additive factor alpha and a multiplicative | decrease (AIMD) with an additive factor alpha_aimd and a | |||
factor beta to be the following function: | multiplicative factor beta_aimd with the following function: | |||
(alpha/2 * (2-beta)/beta * 1/p)^0.5 (Eq. 3) | AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / | |||
(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) | ||||
By the same analysis, the average window size of Standard TCP with | By the same analysis, the average window size of Standard TCP is | |||
alpha 1 and beta 0.5 is (3/2 *1/p)^0.5. Thus, for Eq. 3 to be the | (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with | |||
same as that of Standard TCP, alpha must be equal to 3*beta/(2-beta). | alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as | |||
As Standard TCP increases its window by alpha per RTT, we can get the | that of Standard TCP, alpha_aimd must be equal to | |||
window size of Standard TCP in terms of the elapsed time t as | 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by | |||
follows: | alpha_aimd per RTT, we can get the window size of AIMD in terms of | |||
the elapsed time t as follows: | ||||
W_tcp(t) = W_max*(1-beta) + 3*beta/(2-beta)* t/RTT (Eq. 4) | W_aimd(t) = W_max*beta_aimd + | |||
[3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) | ||||
If cwnd is less than W_tcp(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_tcp(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(t+RTT) - cwnd)/cwnd. | incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK. | |||
3.4. Convex region | 3.4. Convex region | |||
When the window size of CUBIC is larger than W_max, it passes the | When the current window size of CUBIC is larger than W_max, it passes | |||
plateau of the cubic function after which CUBIC follows the convex | the plateau of the cubic function after which CUBIC follows the | |||
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(t+RTT) - cwnd)/cwnd for each | region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for | |||
received ACK. | each received ACK. | |||
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 occurs, CUBIC reduces its window size by a factor | |||
of beta. Parameter beta SHOULD be set to 0.2. | of beta. 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 * (1-beta); // window reduction | cwnd = cwnd * beta_cubic; // window reduction | |||
A side effect of setting beta to a smaller value than 0.5 is slower | A side effect of setting beta_cubic to a bigger value than 0.5 is | |||
convergence. We believe that while a more adaptive setting of beta | slower convergence. We believe that while a more adaptive setting of | |||
could result in faster convergence, it will make the analysis of the | beta_cubic could result in faster convergence, it will make the | |||
protocol much harder. This adaptive adjustment of beta is an item | analysis of the protocol much harder. This adaptive adjustment of | |||
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 | |||
protocol. When a new flow joins the network, existing flows in the | protocol. When a new flow joins the network, existing flows in the | |||
network need to give up their bandwidth shares to allow the flow some | network need to give up their bandwidth shares to allow the flow some | |||
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){ // check downward trend | |||
W_last_max = W_max; // remember the last W_max | W_last_max = W_max; // remember the last W_max | |||
W_max = W_max*(2-beta)/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. | |||
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: | |||
(C*(4-beta)/4/beta)^0.25 * RTT^0.75 / p^0.75 (Eq. 5) | AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * | |||
(RTT^0.75) / (p^0.75) (Eq. 5) | ||||
With beta set to 0.2, the above formula is reduced to: | With beta_cubic set to 0.7, the above formula is reduced to: | |||
(C*3.8/0.8)^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 9, line 10 | skipping to change at page 9, line 17 | |||
average window size of standard TCP, HSTCP, and CUBIC. The average | average window size of standard TCP, HSTCP, and CUBIC. The average | |||
window size of standard TCP and HSTCP is from [RFC3649]. The average | window size of standard TCP and HSTCP is from [RFC3649]. The average | |||
window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP | window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP | |||
friendly mode for three different values of C. | friendly mode for three different values of C. | |||
+----------+-------+--------+-------------+-------------+-----------+ | +----------+-------+--------+-------------+-------------+-----------+ | |||
| Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | | | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | | |||
| Rate P | | | (C=0.04) | (C=0.4) | (C=4) | | | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | | |||
+----------+-------+--------+-------------+-------------+-----------+ | +----------+-------+--------+-------------+-------------+-----------+ | |||
| 10^-2 | 12 | 12 | 12 | 12 | 12 | | | 10^-2 | 12 | 12 | 12 | 12 | 12 | | |||
| 10^-3 | 38 | 38 | 38 | 38 | 66 | | | 10^-3 | 38 | 38 | 38 | 38 | 59 | | |||
| 10^-4 | 120 | 263 | 120 | 209 | 371 | | | 10^-4 | 120 | 263 | 120 | 187 | 333 | | |||
| 10^-5 | 379 | 1795 | 660 | 1174 | 2087 | | | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | | |||
| 10^-6 | 1200 | 12279 | 3713 | 6602 | 11740 | | | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | | |||
| 10^-7 | 3795 | 83981 | 20878 | 37126 | 66022 | | | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | | |||
| 10^-8 | 12000 | 574356 | 117405 | 208780 | 371269 | | | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | | |||
+----------+-------+--------+-------------+-------------+-----------+ | +----------+-------+--------+-------------+-------------+-----------+ | |||
Response function of standard TCP, HSTCP, and CUBIC in networks with | Response function of standard TCP, HSTCP, and CUBIC in networks with | |||
RTT = 100ms. The average window size W is in MSS-sized segments. | RTT = 0.1 seconds. The average window size is in MSS-sized segments. | |||
Table 1 | Table 1 | |||
+--------+-----------+-----------+------------+-----------+---------+ | +--------+-----------+-----------+------------+-----------+---------+ | |||
| Loss | Average | Average | CUBIC | CUBIC | CUBIC | | | Loss | Average | Average | CUBIC | CUBIC | CUBIC | | |||
| Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | | | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | | |||
+--------+-----------+-----------+------------+-----------+---------+ | +--------+-----------+-----------+------------+-----------+---------+ | |||
| 10^-2 | 12 | 12 | 12 | 12 | 12 | | | 10^-2 | 12 | 12 | 12 | 12 | 12 | | |||
| 10^-3 | 38 | 38 | 38 | 38 | 38 | | | 10^-3 | 38 | 38 | 38 | 38 | 38 | | |||
| 10^-4 | 120 | 263 | 120 | 120 | 120 | | | 10^-4 | 120 | 263 | 120 | 120 | 120 | | |||
| 10^-5 | 379 | 1795 | 379 | 379 | 379 | | | 10^-5 | 379 | 1795 | 379 | 379 | 379 | | |||
| 10^-6 | 1200 | 12279 | 1200 | 1200 | 2087 | | | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | | |||
| 10^-7 | 3795 | 83981 | 3795 | 6603 | 11740 | | | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | | |||
| 10^-8 | 12000 | 574356 | 20878 | 37126 | 66022 | | | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | | |||
+--------+-----------+-----------+------------+-----------+---------+ | +--------+-----------+-----------+------------+-----------+---------+ | |||
Response function of standard TCP, HSTCP, and CUBIC in networks with | Response function of standard TCP, HSTCP, and CUBIC in networks with | |||
RTT = 10ms. The average window size W is in MSS-sized segments. | RTT = 0.01 seconds. The average window size is in MSS-sized | |||
segments. | ||||
Table 2 | Table 2 | |||
Both tables show that CUBIC with any of these three C values is more | Both tables show that CUBIC with any of these three C values is more | |||
friendly to TCP than HSTCP, especially in networks with a short RTT | friendly to TCP than HSTCP, especially in networks with a short RTT | |||
where TCP performs reasonably well. For example, in a network with | where TCP performs reasonably well. For example, in a network with | |||
RTT = 10ms and p=10^-6, TCP has an average window of 1200 packets. | RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 | |||
If the packet size is 1500 bytes, then TCP can achieve an average | packets. If the packet size is 1500 bytes, then TCP can achieve an | |||
rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 achieves | average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 | |||
exactly the same rate as Standard TCP, whereas HSTCP is about ten | achieves exactly the same rate as Standard TCP, whereas HSTCP is | |||
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, we find C=0.4 gives | |||
a good balance between TCP-friendliness and aggressiveness of window | a good balance between TCP-friendliness and aggressiveness of window | |||
growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 | growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 | |||
is reduced to: | is reduced to: | |||
1.17 * 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. | |||
4.2. Using Spare Capacity | 4.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. | |||
The following table shows that to achieve 10Gbps rate, standard TCP | The following table shows that to achieve 10Gbps rate, standard TCP | |||
requires a packet loss rate of 2.0e-10, while CUBIC requires a packet | requires a packet loss rate of 2.0e-10, while CUBIC requires a packet | |||
loss rate of 3.4e-8. | loss rate of 2.9e-8. | |||
+------------------+-----------+---------+---------+---------+ | +------------------+-----------+---------+---------+---------+ | |||
| Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | | | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | | |||
+------------------+-----------+---------+---------+---------+ | +------------------+-----------+---------+---------+---------+ | |||
| 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | | | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | | |||
| 10 | 83.3 | 2.0e-4 | 3.9e-4 | 3.3e-4 | | | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | | |||
| 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.6e-5 | | | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | | |||
| 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 7.3e-7 | | | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | | |||
| 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 3.4e-8 | | | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | | |||
+------------------+-----------+---------+---------+---------+ | +------------------+-----------+---------+---------+---------+ | |||
Required packet loss rate for Standard TCP, HSTCP, and CUBIC to | Required packet loss rate for Standard TCP, HSTCP, and CUBIC to | |||
achieve a certain throughput. We use 1500-byte packets and an RTT of | achieve a certain throughput. We use 1500-byte packets and an RTT of | |||
0.1 seconds. | 0.1 seconds. | |||
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 | |||
skipping to change at page 12, line 19 | skipping to change at page 12, line 27 | |||
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. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP | [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP | |||
Selective Acknowledgment Options", RFC 2018, October 1996. | 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, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<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, December 2003. | RFC 3649, DOI 10.17487/RFC3649, December 2003, | |||
<http://www.rfc-editor.org/info/rfc3649>. | ||||
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC | [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | |||
4960, September 2007. | RFC 4960, DOI 10.17487/RFC4960, September 2007, | |||
<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, August 2007. | Control Algorithms", BCP 133, RFC 5033, | |||
DOI 10.17487/RFC5033, August 2007, | ||||
<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 | |||
Friendly Rate Control (TFRC): Protocol Specification", RFC | Friendly Rate Control (TFRC): Protocol Specification", | |||
5348, September 2008. | RFC 5348, DOI 10.17487/RFC5348, September 2008, | |||
<http://www.rfc-editor.org/info/rfc5348>. | ||||
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion | [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion | |||
Control", RFC 5681, September 2009. | Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, | |||
<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, April 2012. | RFC 6582, DOI 10.17487/RFC6582, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6582>. | ||||
8.2. Informative References | 8.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. | |||
[FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of | [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of | |||
Equation-Based and AIMD Congestion Control", May 2000. | Equation-Based and AIMD Congestion Control", May 2000. | |||
skipping to change at page 13, line 31 | skipping to change at page 14, line 5 | |||
Communication Review , April 2003. | Communication Review , April 2003. | |||
[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. | |||
Appendix A. ToDo List | ||||
o Incorporate ICCRG's feedback (see | ||||
http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic) | ||||
o ncorporate feedback from Neal Cardwell (see http://www.ietf.org/ | ||||
mail-archive/web/tcpm/current/msg09508.html) | ||||
Authors' Addresses | Authors' Addresses | |||
Injong Rhee | Injong Rhee | |||
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-01150 | |||
US | US | |||
Email: xu@unl.edu | Email: xu@unl.edu | |||
Sangtae Ha | Sangtae Ha | |||
University of Colorado at Boulder | University of Colorado at Boulder | |||
End of changes. 53 change blocks. | ||||
106 lines changed or deleted | 120 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |