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/ |