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