draft-ietf-tcpm-cubic-04.txt | draft-ietf-tcpm-cubic-05.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: August 8, 2017 UNL | Expires: January 18, 2018 UNL | |||
S. Ha | S. Ha | |||
Colorado | Colorado | |||
A. Zimmermann | A. Zimmermann | |||
L. Eggert | L. Eggert | |||
NetApp | NetApp | |||
R. Scheffenegger | R. Scheffenegger | |||
February 4, 2017 | July 17, 2017 | |||
CUBIC for Fast Long-Distance Networks | CUBIC for Fast Long-Distance Networks | |||
draft-ietf-tcpm-cubic-04 | draft-ietf-tcpm-cubic-05 | |||
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 function of the | cubic function instead of a linear window increase function of the | |||
current TCP standards to improve scalability and stability under fast | current TCP standards to improve scalability and stability under fast | |||
and long distance networks. CUBIC and its predecessor algorithm have | and long distance networks. CUBIC and its predecessor algorithm have | |||
been adopted as default by Linux and have been used for many years. | been adopted as default by Linux and have been used for many years. | |||
skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
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 August 8, 2017. | This Internet-Draft will expire on January 18, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 33 ¶ | skipping to change at page 2, line 33 ¶ | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4 | 3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4 | |||
4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 | 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 | |||
4.1. Window growth function . . . . . . . . . . . . . . . . . 6 | 4.1. Window growth function . . . . . . . . . . . . . . . . . 6 | |||
4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7 | 4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 | 4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 | 4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8 | 4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8 | |||
4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8 | 4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8 | |||
4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.8. Slowstart . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 9 | 5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 10 | |||
5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11 | 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11 | |||
5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 | 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 | |||
5.4. Investigating a Range of Environments . . . . . . . . . . 12 | 5.4. Investigating a Range of Environments . . . . . . . . . . 12 | |||
5.5. Protection against Congestion Collapse . . . . . . . . . 12 | 5.5. Protection against Congestion Collapse . . . . . . . . . 13 | |||
5.6. Fairness within the Alternative Congestion Control | 5.6. Fairness within the Alternative Congestion Control | |||
Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 12 | Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.7. Performance with Misbehaving Nodes and Outside Attackers 12 | 5.7. Performance with Misbehaving Nodes and Outside Attackers 13 | |||
5.8. Behavior for Application-Limited Flows . . . . . . . . . 12 | 5.8. Behavior for Application-Limited Flows . . . . . . . . . 13 | |||
5.9. Responses to Sudden or Transient Events . . . . . . . . . 13 | 5.9. Responses to Sudden or Transient Events . . . . . . . . . 13 | |||
5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13 | 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 14 | 9.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
The low utilization problem of TCP in fast long-distance networks is | The low utilization problem of TCP in fast long-distance networks is | |||
well documented in [K03][RFC3649]. This problem arises from a slow | well documented in [K03][RFC3649]. This problem arises from a slow | |||
increase of congestion window following a congestion event in a | increase of congestion window following a congestion event in a | |||
network with a large bandwidth delay product (BDP). Our experience | network with a large bandwidth delay product (BDP). Our experience | |||
[HKLRX06] indicates that this problem is frequently observed even in | [HKLRX06] indicates that this problem is frequently observed even in | |||
the range of congestion window sizes over several hundreds of packets | the range of congestion window sizes over several hundreds of packets | |||
(each packet is sized around 1000 bytes) especially under a network | (each packet is sized around 1000 bytes) especially under a network | |||
path with over 100ms round-trip times (RTTs). This problem is | path with over 100ms round-trip times (RTTs). This problem is | |||
equally applicable to all Reno style TCP standards and their | equally applicable to all Reno style TCP standards and their | |||
variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- | variants, including TCP-RENO [RFC5681], TCP-NewReno | |||
SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same | [RFC6582][RFC6675], 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. Specifically, it uses | Standard TCP senders, to remedy this problem. Specifically, it uses | |||
a cubic function instead of a linear window increase function of the | a cubic function instead of a linear window increase function of the | |||
Standrad TCP to improve scalability and stability under fast and long | Standrad TCP to improve scalability and stability under fast and long | |||
distance networks. | distance networks. | |||
skipping to change at page 6, line 10 ¶ | skipping to change at page 6, line 10 ¶ | |||
4. CUBIC Congestion Control | 4. 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. | |||
4.1. Window growth function | 4.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, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During | of TCP, such as TCP-NewReno [RFC6582] [RFC6675]. During congestion | |||
congestion avoidance after fast recovery, CUBIC changes the window | avoidance after fast recovery, CUBIC changes the window update | |||
update algorithm of Standard TCP. Suppose that W_max is the window | algorithm of Standard TCP. Suppose that W_max is the window size | |||
size before the window is reduced in the last fast retransmit and | before the window is reduced in the last fast retransmit and | |||
recovery. | recovery. | |||
The window growth function of CUBIC uses the following function: | The window growth function of CUBIC uses the following function: | |||
W_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 that is measured right after the fast recovery in | window reduction that is measured right after the fast recovery in | |||
response to duplicate ACKs or after the congestion window reduction | response to duplicate ACKs or after the congestion window reduction | |||
skipping to change at page 6, line 35 ¶ | skipping to change at page 6, line 35 ¶ | |||
function takes to increase the current window size to W_max if there | function takes to increase the current window size to W_max if there | |||
is no further loss event and is calculated by using the following | is no further loss event and is calculated by using the following | |||
equation: | 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 detected by duplicate ACKs or a network | is, when a packet loss detected by duplicate ACKs or a network | |||
congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its | congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its | |||
current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how | current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how | |||
we set C in the next Section in more details. | we set beta_cubic in Section 4.5 and how we set C in Section 5. | |||
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. | 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 | |||
skipping to change at page 7, line 34 ¶ | skipping to change at page 7, line 34 ¶ | |||
(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 | |||
the elapsed time t as follows: | the elapsed time t as follows: | |||
W_aimd(t) = W_max*beta_aimd + | W_aimd(t) = W_max*beta_aimd + | |||
[3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) | [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) | |||
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) (it does not matter whether cwnd | |||
is greater than or less than W_max), 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. | |||
4.3. Concave region | 4.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. | where W_cubic(t+RTT) is calculated using Eq. 1. | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 5 ¶ | |||
room for growth if the existing flows have been using all the | room for growth if the existing flows have been using all the | |||
bandwidth of the network. To increase this release of bandwidth by | bandwidth of the network. To increase this release of bandwidth by | |||
existing flows, the following mechanism called fast convergence | existing flows, the following mechanism called fast convergence | |||
SHOULD be implemented. | SHOULD be implemented. | |||
With fast convergence, when a loss event occurs, before a window | With fast convergence, when a loss event occurs, before a window | |||
reduction of congestion window, a flow remembers the last value of | reduction of congestion window, a flow remembers the last value of | |||
W_max before it updates W_max for the current loss event. Let us | W_max before it updates W_max for the current loss event. Let us | |||
call the last value of W_max to be W_last_max. | call the last value of W_max to be W_last_max. | |||
if (W_max < W_last_max){ // check downward trend | if (W_max < W_last_max){ // should we make room for others | |||
W_last_max = W_max; // remember the last W_max | W_last_max = W_max; // remember the last W_max | |||
W_max = W_max*(1+beta_cubic)/2; // further reduce W_max | W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max | |||
} else { // check upward trend | } else { | |||
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 | At a loss event, if the current value of W_max is less than | |||
flows spend most of time around their W_max, flows with larger | W_last_max, this indicates that the saturation point experienced by | |||
bandwidth shares tend to spend more time around the plateau allowing | this flow is getting reduced because of the change in available | |||
more time for flows with smaller shares to increase their windows. | bandwidth. Then we allow this flow to release more bandwidth by | |||
reducing W_max further. This action effectively lengthens the time | ||||
for this flow to increase its window because the reduced W_max forces | ||||
the flow to have the plateau earlier. This allows more time for the | ||||
new flow to catch up its window size | ||||
The fast convergence is designed for network environments with | ||||
multiple CUBIC flows. In network environments with only a single | ||||
CUBIC flow and without any other traffic, the fast convergence SHOULD | ||||
be disabled. | ||||
4.7. Timeout | 4.7. Timeout | |||
In case of timeout, CUBIC follows the standard TCP to reduce cwnd, | In case of timeout, CUBIC follows the standard TCP to reduce cwnd, | |||
but sets ssthresh using beta_cubic (same as in Section 4.5). | but sets ssthresh using beta_cubic (same as in Section 4.5). | |||
4.8. Slowstart | ||||
CUBIC MUST employ a slow start algorithm, when the cwnd is no more | ||||
than ssthresh. Among the slow start algorithms, CUBIC MAY choose the | ||||
standard TCP slow start[RFC5681] in general networks, or the limited | ||||
slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth | ||||
and long-distance networks. | ||||
5. Discussion | 5. Discussion | |||
In this section, we further discuss the safety features of CUBIC | In this section, we further discuss the safety features of CUBIC | |||
following the guidelines specified in [RFC5033]. | following the guidelines specified in [RFC5033]. | |||
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: | |||
skipping to change at page 11, line 16 ¶ | skipping to change at page 11, line 38 ¶ | |||
packets. If the packet size is 1500 bytes, then TCP can achieve an | packets. If the packet size is 1500 bytes, then TCP can achieve an | |||
average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 | average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 | |||
achieves exactly the same rate as Standard TCP, whereas HSTCP is | achieves exactly the same rate as Standard TCP, whereas HSTCP is | |||
about ten times more aggressive than Standard TCP. | about ten times more aggressive than Standard TCP. | |||
We can see that C determines the aggressiveness of CUBIC in competing | We can see that C determines the aggressiveness of CUBIC in competing | |||
with other protocols for the bandwidth. CUBIC is more friendly to | with other protocols for the bandwidth. CUBIC is more friendly to | |||
the Standard TCP, if the value of C is lower. However, we do not | the Standard TCP, if the value of C is lower. However, we do not | |||
recommend to set C to a very low value like 0.04, since CUBIC with a | recommend to set C to a very low value like 0.04, since CUBIC with a | |||
low C cannot efficiently use the bandwidth in long RTT and high | low C cannot efficiently use the bandwidth in long RTT and high | |||
bandwidth networks. Based on these observations, we find C=0.4 gives | bandwidth networks. Based on these observations and our experiments, | |||
a good balance between TCP-friendliness and aggressiveness of window | we find C=0.4 gives a good balance between TCP-friendliness and | |||
growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 | aggressiveness of window growth. Therefore, C SHOULD be set to 0.4. | |||
is reduced to: | With C set to 0.4, Eq. 6 is reduced to: | |||
AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) | AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) | |||
Eq. 7 is then used in the next subsection to show the scalability of | Eq. 7 is then used in the next subsection to show the scalability of | |||
CUBIC. | CUBIC. | |||
5.2. Using Spare Capacity | 5.2. Using Spare Capacity | |||
CUBIC uses a more aggressive window growth function than Standard TCP | CUBIC uses a more aggressive window growth function than Standard TCP | |||
under long RTT and high bandwidth networks. | under long RTT and high bandwidth networks. | |||
skipping to change at page 12, line 22 ¶ | skipping to change at page 12, line 42 ¶ | |||
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. | distance networks. | |||
5.4. Investigating a Range of Environments | 5.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]. | |||
Same as Standard TCP, CUBIC is a loss-based congestion control | Same as Standard TCP, CUBIC is a loss-based congestion control | |||
algorithm. Therefore, CUBIC, which is designed to be more aggressive | algorithm. Because CUBIC is designed to be more aggressive (due to | |||
than Standard TCP in fast and long distance networks, can fill large | faster window growth function and bigger multiplicative decrease | |||
drop-tail buffers more quickly than Standard TCP. In this case, | factor) than Standard TCP in fast and long distance networks, it can | |||
proper queue sizing and management [RFC7567] could be used to reduce | fill large drop-tail buffers more quickly than Standard TCP and | |||
the packet queueing delay. | increase the risk of a standing queue[KWAF16]. In this case, proper | |||
queue sizing and management [RFC7567] could be used to reduce the | ||||
packet queueing delay. | ||||
5.5. Protection against Congestion Collapse | 5.5. Protection against Congestion Collapse | |||
With regard to the potential of causing congestion collapse, CUBIC | With regard to the potential of causing congestion collapse, CUBIC | |||
behaves like standard TCP since CUBIC modifies only the window | behaves like standard TCP since CUBIC modifies only the window | |||
adjustment algorithm of TCP. Thus, it does not modify the ACK | adjustment algorithm of TCP. Thus, it does not modify the ACK | |||
clocking and Timeout behaviors of Standard TCP. | clocking and Timeout behaviors of Standard TCP. | |||
5.6. Fairness within the Alternative Congestion Control Algorithm. | 5.6. Fairness within the Alternative Congestion Control Algorithm. | |||
skipping to change at page 12, line 52 ¶ | skipping to change at page 13, line 29 ¶ | |||
link. | link. | |||
5.7. Performance with Misbehaving Nodes and Outside Attackers | 5.7. Performance with Misbehaving Nodes and Outside Attackers | |||
This is not considered in the current CUBIC. | This is not considered in the current CUBIC. | |||
5.8. Behavior for Application-Limited Flows | 5.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 MUST NOT include the | window. In case of long periods when cwnd is not updated due to the | |||
idle time; otherwise, W_cubic(t) might be very high after restarting | application rate limit, such as idle periods, t in Eq. 1 MUST NOT | |||
from a long idle time. | include these periods; otherwise, W_cubic(t) might be very high after | |||
restarting from these periods. | ||||
5.9. Responses to Sudden or Transient Events | 5.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. | |||
5.10. Incremental Deployment | 5.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. | |||
skipping to change at page 13, line 38 ¶ | skipping to change at page 14, line 18 ¶ | |||
European Union's Horizon 2020 research and innovation program | European Union's Horizon 2020 research and innovation program | |||
2014-2018 under grant agreement No. 644866 (SSICLOPS). This document | 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document | |||
reflects only the authors' views and the European Commission is not | reflects only the authors' views and the European Commission is not | |||
responsible for any use that may be made of the information it | responsible for any use that may be made of the information it | |||
contains. | contains. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP | ||||
Selective Acknowledgment Options", RFC 2018, | ||||
DOI 10.17487/RFC2018, October 1996, | ||||
<http://www.rfc-editor.org/info/rfc2018>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", | [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", | |||
RFC 3649, DOI 10.17487/RFC3649, December 2003, | RFC 3649, DOI 10.17487/RFC3649, December 2003, | |||
<http://www.rfc-editor.org/info/rfc3649>. | <http://www.rfc-editor.org/info/rfc3649>. | |||
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large | ||||
Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March | ||||
2004, <http://www.rfc-editor.org/info/rfc3742>. | ||||
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", | |||
RFC 4960, DOI 10.17487/RFC4960, September 2007, | RFC 4960, DOI 10.17487/RFC4960, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4960>. | <http://www.rfc-editor.org/info/rfc4960>. | |||
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion | [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion | |||
Control Algorithms", BCP 133, RFC 5033, | Control Algorithms", BCP 133, RFC 5033, | |||
DOI 10.17487/RFC5033, August 2007, | DOI 10.17487/RFC5033, August 2007, | |||
<http://www.rfc-editor.org/info/rfc5033>. | <http://www.rfc-editor.org/info/rfc5033>. | |||
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP | [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP | |||
skipping to change at page 14, line 28 ¶ | skipping to change at page 15, line 5 ¶ | |||
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion | [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion | |||
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, | Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, | |||
<http://www.rfc-editor.org/info/rfc5681>. | <http://www.rfc-editor.org/info/rfc5681>. | |||
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The | [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The | |||
NewReno Modification to TCP's Fast Recovery Algorithm", | NewReno Modification to TCP's Fast Recovery Algorithm", | |||
RFC 6582, DOI 10.17487/RFC6582, April 2012, | RFC 6582, DOI 10.17487/RFC6582, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6582>. | <http://www.rfc-editor.org/info/rfc6582>. | |||
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., | ||||
and Y. Nishida, "A Conservative Loss Recovery Algorithm | ||||
Based on Selective Acknowledgment (SACK) for TCP", | ||||
RFC 6675, DOI 10.17487/RFC6675, August 2012, | ||||
<http://www.rfc-editor.org/info/rfc6675>. | ||||
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF | |||
Recommendations Regarding Active Queue Management", | Recommendations Regarding Active Queue Management", | |||
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, | |||
<http://www.rfc-editor.org/info/rfc7567>. | <http://www.rfc-editor.org/info/rfc7567>. | |||
9.2. Informative References | 9.2. Informative References | |||
[CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic | [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic | |||
Ordering for Internet Congestion Control and its | Ordering for Internet Congestion Control and its | |||
Applications", In Proceedings of IEEE INFOCOM , May 2007. | Applications", In Proceedings of IEEE INFOCOM , May 2007. | |||
skipping to change at page 15, line 5 ¶ | skipping to change at page 15, line 35 ¶ | |||
[GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary | [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary | |||
Adjustment Algorithms", Technical Report TR2002-29, | Adjustment Algorithms", Technical Report TR2002-29, | |||
Department of Computer Sciences , The University of Texas | Department of Computer Sciences , The University of Texas | |||
at Austin , August 2002. | at Austin , August 2002. | |||
[HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step | [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step | |||
toward Realistic Performance Evaluation of High-Speed TCP | toward Realistic Performance Evaluation of High-Speed TCP | |||
Variants", International Workshop on Protocols for Fast | Variants", International Workshop on Protocols for Fast | |||
Long-Distance Networks , February 2006. | Long-Distance Networks , February 2006. | |||
[HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth | ||||
and Long-Distance Networks", International Workshop on | ||||
Protocols for Fast Long-Distance Networks , 2008. | ||||
[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly | [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly | |||
High-Speed TCP Variant", ACM SIGOPS Operating System | High-Speed TCP Variant", ACM SIGOPS Operating System | |||
Review , 2008. | Review , 2008. | |||
[K03] Kelly, T., "Scalable TCP: Improving Performance in | [K03] Kelly, T., "Scalable TCP: Improving Performance in | |||
HighSpeed Wide Area Networks", ACM SIGCOMM Computer | HighSpeed Wide Area Networks", ACM SIGCOMM Computer | |||
Communication Review , April 2003. | Communication Review , April 2003. | |||
[KWAF16] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, | ||||
"TCP Alternative Backoff with ECN (ABE)", Internet-draft, | ||||
IETF work-in-progress draft-khademi-tcpm- | ||||
alternativebackoff-ecn-01 , October 2016. | ||||
[LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control | [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control | |||
for High Bandwidth-Delay Product Paths", Internet-draft | for High Bandwidth-Delay Product Paths", Internet-draft | |||
draft-leith-tcp-htcp-06 , April 2008. | draft-leith-tcp-htcp-06 , April 2008. | |||
[XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase | [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase | |||
Congestion Control for Fast, Long Distance Networks", In | Congestion Control for Fast, Long Distance Networks", In | |||
Proceedings of IEEE INFOCOM , March 2004. | Proceedings of IEEE INFOCOM , March 2004. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 25 change blocks. | ||||
46 lines changed or deleted | 82 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/ |