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