idnits 2.17.1 draft-ietf-tcpm-cubic-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 4, 2017) is 2638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee 3 Internet-Draft NCSU 4 Intended status: Informational L. Xu 5 Expires: August 8, 2017 UNL 6 S. Ha 7 Colorado 8 A. Zimmermann 10 L. Eggert 11 NetApp 12 R. Scheffenegger 13 February 4, 2017 15 CUBIC for Fast Long-Distance Networks 16 draft-ietf-tcpm-cubic-04 18 Abstract 20 CUBIC is an extension to the current TCP standards. The protocol 21 differs from the current TCP standards only in the congestion window 22 adjustment function in the sender side. In particular, it uses a 23 cubic function instead of a linear window increase function of the 24 current TCP standards to improve scalability and stability under fast 25 and long distance networks. CUBIC and its predecessor algorithm have 26 been adopted as default by Linux and have been used for many years. 27 This document provides a specification of CUBIC to enable third party 28 implementation and to solicit the community feedback through 29 experimentation on the performance of CUBIC. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 8, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4 68 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 69 4.1. Window growth function . . . . . . . . . . . . . . . . . 6 70 4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7 71 4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 72 4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 73 4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8 74 4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8 75 4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 9 78 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11 79 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 80 5.4. Investigating a Range of Environments . . . . . . . . . . 12 81 5.5. Protection against Congestion Collapse . . . . . . . . . 12 82 5.6. Fairness within the Alternative Congestion Control 83 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.7. Performance with Misbehaving Nodes and Outside Attackers 12 85 5.8. Behavior for Application-Limited Flows . . . . . . . . . 12 86 5.9. Responses to Sudden or Transient Events . . . . . . . . . 13 87 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 93 9.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 The low utilization problem of TCP in fast long-distance networks is 99 well documented in [K03][RFC3649]. This problem arises from a slow 100 increase of congestion window following a congestion event in a 101 network with a large bandwidth delay product (BDP). Our experience 102 [HKLRX06] indicates that this problem is frequently observed even in 103 the range of congestion window sizes over several hundreds of packets 104 (each packet is sized around 1000 bytes) especially under a network 105 path with over 100ms round-trip times (RTTs). This problem is 106 equally applicable to all Reno style TCP standards and their 107 variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- 108 SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same 109 linear increase function for window growth, which we refer to 110 collectively as Standard TCP below. 112 CUBIC [HRX08] is a modification to the congestion control mechanism 113 of Standard TCP, in particular, to the window increase function of 114 Standard TCP senders, to remedy this problem. Specifically, it uses 115 a cubic function instead of a linear window increase function of the 116 Standrad TCP to improve scalability and stability under fast and long 117 distance networks. 119 BIC-TCP, a predecessor of CUBIC, has been selected as default TCP 120 congestion control algorithm by Linux in the year 2005 and been used 121 for several years by the Internet community at large. CUBIC uses a 122 similar window growth function as BIC-TCP and is designed to be less 123 aggressive and fairer to TCP in bandwidth usage than BIC-TCP while 124 maintaining the strengths of BIC-TCP such as stability, window 125 scalability and RTT fairness. CUBIC has already been deployed 126 globally by Linux. Through extensive testing in various Internet 127 scenarios, we believe that CUBIC is safe for testing and deployment 128 in the global Internet. 130 In the ensuing sections, we first brefly explain the design principle 131 of CUBIC, then provide the exact specification of CUBIC, and finally 132 discuss the safety features of CUBIC following the guidelines 133 specified in [RFC5033]. 135 2. Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Design principle of CUBIC 143 CUBIC [HRX08] uses a cubic window increase function in terms of the 144 elapsed time from the last congestion event. While most alternative 145 algorithms to Standard TCP uses a convex increase function where 146 during congestion avoidance the window increment is always 147 increasing, CUBIC uses both the concave and convex profiles of a 148 cubic function for window increase. After a window reduction 149 following a loss event detected by duplicate ACKs, it registers the 150 window size where it got the loss event as W_max and performs a 151 multiplicative decrease of congestion window and the regular fast 152 recovery and retransmit of Standard TCP. After it enters into 153 congestion avoidance from fast recovery, it starts to increase the 154 window using the concave profile of the cubic function. The cubic 155 function is set to have its plateau at W_max so the concave growth 156 continues until the window size becomes W_max. After that, the cubic 157 function turns into a convex profile and the convex window growth 158 begins. This style of window adjustment (concave and then convex) 159 improves protocol and network stability while maintaining high 160 network utilization [CEHRX07]. This is because the window size 161 remains almost constant, forming a plateau around W_max where network 162 utilization is deemed highest and under steady state, most window 163 size samples of CUBIC are close to W_max, thus promoting high network 164 utilization and protocol stability. Note that protocols with convex 165 increase functions have the maximum increments around W_max and 166 introduces a large number of packet bursts around the saturation 167 point of the network, likely causing frequent global loss 168 synchronizations. 170 Another notable feature of CUBIC is that its window increase rate is 171 mostly independent of RTT, and follows a (cubic) function of the 172 elapsed time from the beginning of congestion avoidance. This 173 feature promotes per-flow fairness to Standard TCP as well as RTT- 174 fairness. Note that Standard TCP performs well under short RTT and 175 small bandwidth (or small BDP) networks. Only in a large long RTT 176 and large bandwidth (or large BDP) networks, it has the scalability 177 problem. An alternative protocol to Standard TCP designed to be 178 friendly to Standard TCP at a per-flow basis must operate to increase 179 its window much less aggressively in small BDP networks than in large 180 BDP networks. In CUBIC, its window growth rate is slowest around the 181 inflection point of the cubic function and this function does not 182 depend on RTT. In a smaller BDP network where Standard TCP flows are 183 working well, the absolute amount of the window decrease at a loss 184 event is always smaller because of the multiplicative decrease. 185 Therefore, in CUBIC, the starting window size after a loss event from 186 which the window starts to increase, is smaller in a smaller BDP 187 network, thus falling nearer to the plateau of the cubic function 188 where the growth rate is slowest. By setting appropriate values of 189 the cubic function parameters, CUBIC sets its growth rate always no 190 faster than Standard TCP around its inflection point. When the cubic 191 function grows slower than the window of Standard TCP, CUBIC simply 192 follows the window size of Standard TCP to ensure fairness to 193 Standard TCP in a small BDP network. We call this region where CUBIC 194 behaves like Standard TCP, the TCP-friendly region. 196 CUBIC maintains the same window growth rate independent of RTTs 197 outside of the TCP-friendly region, and flows with different RTTs 198 have the similar window sizes under steady state when they operate 199 outside the TCP-friendly region. This ensures CUBIC flows with 200 different RTTs to have their bandwidth shares (approximately, window/ 201 RTT) linearly proportional to the inverse of their RTT ratio (the 202 longer RTT, the smaller the share). This behavior is the same as 203 that of Standard TCP under high statistical multiplexing environments 204 where packet losses are independent of individual flow rates. 205 However, under low statistical multiplexing environments, the 206 bandwidth share ratio of Standard TCP flows with different RTTs is 207 squarely proportional to the inverse of their RTT ratio [XHR04]. 208 CUBIC always ensures the linear ratio independent of the levels of 209 statistical multiplexing. This is an improvement over Standard TCP. 210 While there is no consensus on a particular bandwidth share ratios of 211 different RTT flows, we believe that under wired Internet, use of the 212 linear share notion seems more reasonable than equal share or a 213 higher order shares. HTCP [LS08] currently uses the equal share. 215 CUBIC sets the multiplicative window decrease factor to 0.7 while 216 Standard TCP uses 0.5. While this improves the scalability of the 217 protocol, a side effect of this decision is slower convergence 218 especially under low statistical multiplexing environments. This 219 design choice is following the observation that the author of HSTCP 220 [RFC3649] has made along with other researchers (e.g., [GV02]): the 221 current Internet becomes more asynchronous with less frequent loss 222 synchronizations with high statistical multiplexing. Under this 223 environment, even strict Multiplicative-Increase Multiplicative- 224 Decrease (MIMD) can converge. CUBIC flows with the same RTT always 225 converge to the same share of bandwidth independent of statistical 226 multiplexing, thus achieving intra-protocol fairness. We also find 227 that under the environments with sufficient statistical multiplexing, 228 the convergence speed of CUBIC flows is reasonable. 230 4. CUBIC Congestion Control 232 The unit of all window sizes in this document is segments of the 233 maximum segment size (MSS), and the unit of all times is seconds. 235 4.1. Window growth function 237 CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by 238 increasing congestion window only at the reception of ACK. The 239 protocol does not make any change to the fast recovery and retransmit 240 of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During 241 congestion avoidance after fast recovery, CUBIC changes the window 242 update algorithm of Standard TCP. Suppose that W_max is the window 243 size before the window is reduced in the last fast retransmit and 244 recovery. 246 The window growth function of CUBIC uses the following function: 248 W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) 250 where C is a constant fixed to determine the aggressiveness of window 251 growth in high BDP networks, t is the elapsed time from the last 252 window reduction that is measured right after the fast recovery in 253 response to duplicate ACKs or after the congestion window reduction 254 in response to ECN-Echo ACKs, and K is the time period that the above 255 function takes to increase the current window size to W_max if there 256 is no further loss event and is calculated by using the following 257 equation: 259 K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) 261 where beta_cubic is the CUBIC multiplication decrease factor, that 262 is, when a packet loss detected by duplicate ACKs or a network 263 congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its 264 current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how 265 we set C in the next Section in more details. 267 Upon receiving an ACK during congestion avoidance, CUBIC computes the 268 window growth rate during the next RTT period using Eq. 1. It sets 269 W_cubic(t+RTT) as the candidate target value of congestion window, 270 where RTT is the weithed average RTT calculated by the standard TCP. 272 Depending on the value of the current window size cwnd, CUBIC runs in 273 three different modes. First, if cwnd is less than the window size 274 that Standard TCP would reach at time t after the last loss event, 275 then CUBIC is in the TCP friendly region (we describe below how to 276 determine this window size of Standard TCP in term of time t). 277 Otherwise, if cwnd is less than W_max, then CUBIC is the concave 278 region, and if cwnd is larger than W_max, CUBIC is in the convex 279 region. Below, we describe the exact actions taken by CUBIC in each 280 region. 282 4.2. TCP-friendly region 284 Standard TCP performs well in certain types of networks, for example, 285 under short RTT and small bandwidth (or small BDP) networks. In 286 these networks, we use the TCP-friendly region to ensure that CUBIC 287 achieves at least the same throughput as the standard TCP. 289 When receiving an ACK in congestion avoidance, we first check whether 290 the protocol is in the TCP region or not. This is done by estimating 291 the average rate of the Standard TCP using a simple analysis 292 described in [FHP00]. It considers the Standard TCP as a special 293 case of an Additive Increase and Multiplicative Decrease algorithm 294 (AIMD), which has an additive factor alpha_aimd and a multiplicative 295 factor beta_aimd with the following function: 297 AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / 298 (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) 300 By the same analysis, the average window size of Standard TCP is 301 (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with 302 alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as 303 that of Standard TCP, alpha_aimd must be equal to 304 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by 305 alpha_aimd per RTT, we can get the window size of AIMD in terms of 306 the elapsed time t as follows: 308 W_aimd(t) = W_max*beta_aimd + 309 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) 311 If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP 312 friendly region and cwnd SHOULD be set to W_aimd(t) at each reception 313 of ACK. 315 4.3. Concave region 317 When receiving an ACK in congestion avoidance, if the protocol is not 318 in the TCP-friendly region and cwnd is less than W_max, then the 319 protocol is in the concave region. In this region, cwnd MUST be 320 incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, 321 where W_cubic(t+RTT) is calculated using Eq. 1. 323 4.4. Convex region 325 When the current window size of CUBIC is larger than W_max, it passes 326 the plateau of the cubic function after which CUBIC follows the 327 convex profile of the cubic function. Since cwnd is larger than the 328 previous saturation point W_max, this indicates that the network 329 conditions might have been perturbed since the last loss event, 330 possibly implying more available bandwidth after some flow 331 departures. Since the Internet is highly asynchronous, some amount 332 of perturbation is always possible without causing a major change in 333 available bandwidth. In this phase, CUBIC is being very careful by 334 very slowly increasing its window size. The convex profile ensures 335 that the window increases very slowly at the beginning and gradually 336 increases its growth rate. We also call this phase as the maximum 337 probing phase since CUBIC is searching for a new W_max. In this 338 region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for 339 each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1. 341 4.5. Multiplicative decrease 343 When a packet loss detected by duplicate ACKs or a network congestion 344 detected by ECN-Echo ACKs occurs, CUBIC updates its W_max, cwnd, and 345 ssthresh (slow start threshold) as follows. Parameter beta_cubic 346 SHOULD be set to 0.7. 348 W_max = cwnd; // save window size before reduction 349 ssthresh = cwnd * beta_cubic; // new slow start threshold 350 cwnd = cwnd * beta_cubic; // window reduction 352 A side effect of setting beta_cubic to a bigger value than 0.5 is 353 slower convergence. We believe that while a more adaptive setting of 354 beta_cubic could result in faster convergence, it will make the 355 analysis of the protocol much harder. This adaptive adjustment of 356 beta_cubic is an item for the next version of CUBIC. 358 4.6. Fast convergence 360 To improve the convergence speed of CUBIC, we add a heuristic in the 361 protocol. When a new flow joins the network, existing flows in the 362 network need to give up their bandwidth shares to allow the flow some 363 room for growth if the existing flows have been using all the 364 bandwidth of the network. To increase this release of bandwidth by 365 existing flows, the following mechanism called fast convergence 366 SHOULD be implemented. 368 With fast convergence, when a loss event occurs, before a window 369 reduction of congestion window, a flow remembers the last value of 370 W_max before it updates W_max for the current loss event. Let us 371 call the last value of W_max to be W_last_max. 373 if (W_max < W_last_max){ // check downward trend 374 W_last_max = W_max; // remember the last W_max 375 W_max = W_max*(1+beta_cubic)/2; // further reduce W_max 376 } else { // check upward trend 377 W_last_max = W_max // remember the last W_max 378 } 380 This allows W_max to be slightly less than the original W_max. Since 381 flows spend most of time around their W_max, flows with larger 382 bandwidth shares tend to spend more time around the plateau allowing 383 more time for flows with smaller shares to increase their windows. 385 4.7. Timeout 387 In case of timeout, CUBIC follows the standard TCP to reduce cwnd, 388 but sets ssthresh using beta_cubic (same as in Section 4.5). 390 5. Discussion 392 In this section, we further discuss the safety features of CUBIC 393 following the guidelines specified in [RFC5033]. 395 With a deterministic loss model where the number of packets between 396 two successive lost events is always 1/p, CUBIC always operates with 397 the concave window profile which greatly simplifies the performance 398 analysis of CUBIC. The average window size of CUBIC can be obtained 399 by the following function: 401 AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * 402 (RTT^0.75) / (p^0.75) (Eq. 5) 404 With beta_cubic set to 0.7, the above formula is reduced to: 406 AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6) 408 We will determine the value of C in the following subsection using 409 Eq. 6. 411 5.1. Fairness to standard TCP 413 In environments where standard TCP is able to make reasonable use of 414 the available bandwidth, CUBIC does not significantly change this 415 state. 417 Standard TCP performs well in the following two types of networks: 419 1. networks with a small bandwidth-delay product (BDP) 420 2. networks with a short RTT, but not necessarily a small BDP 422 CUBIC is designed to behave very similarly to standard TCP in the 423 above two types of networks. The following two tables show the 424 average window size of standard TCP, HSTCP, and CUBIC. The average 425 window size of standard TCP and HSTCP is from [RFC3649]. The average 426 window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP 427 friendly mode for three different values of C. 429 +----------+-------+--------+-------------+-------------+-----------+ 430 | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | 431 | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | 432 +----------+-------+--------+-------------+-------------+-----------+ 433 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 434 | 10^-3 | 38 | 38 | 38 | 38 | 59 | 435 | 10^-4 | 120 | 263 | 120 | 187 | 333 | 436 | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | 437 | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | 438 | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | 439 | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | 440 +----------+-------+--------+-------------+-------------+-----------+ 442 Response function of standard TCP, HSTCP, and CUBIC in networks with 443 RTT = 0.1 seconds. The average window size is in MSS-sized segments. 445 Table 1 447 +--------+-----------+-----------+------------+-----------+---------+ 448 | Loss | Average | Average | CUBIC | CUBIC | CUBIC | 449 | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | 450 +--------+-----------+-----------+------------+-----------+---------+ 451 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 452 | 10^-3 | 38 | 38 | 38 | 38 | 38 | 453 | 10^-4 | 120 | 263 | 120 | 120 | 120 | 454 | 10^-5 | 379 | 1795 | 379 | 379 | 379 | 455 | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | 456 | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | 457 | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | 458 +--------+-----------+-----------+------------+-----------+---------+ 460 Response function of standard TCP, HSTCP, and CUBIC in networks with 461 RTT = 0.01 seconds. The average window size is in MSS-sized 462 segments. 464 Table 2 466 Both tables show that CUBIC with any of these three C values is more 467 friendly to TCP than HSTCP, especially in networks with a short RTT 468 where TCP performs reasonably well. For example, in a network with 469 RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 470 packets. If the packet size is 1500 bytes, then TCP can achieve an 471 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 472 achieves exactly the same rate as Standard TCP, whereas HSTCP is 473 about ten times more aggressive than Standard TCP. 475 We can see that C determines the aggressiveness of CUBIC in competing 476 with other protocols for the bandwidth. CUBIC is more friendly to 477 the Standard TCP, if the value of C is lower. However, we do not 478 recommend to set C to a very low value like 0.04, since CUBIC with a 479 low C cannot efficiently use the bandwidth in long RTT and high 480 bandwidth networks. Based on these observations, we find C=0.4 gives 481 a good balance between TCP-friendliness and aggressiveness of window 482 growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 483 is reduced to: 485 AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) 487 Eq. 7 is then used in the next subsection to show the scalability of 488 CUBIC. 490 5.2. Using Spare Capacity 492 CUBIC uses a more aggressive window growth function than Standard TCP 493 under long RTT and high bandwidth networks. 495 The following table shows that to achieve 10Gbps rate, standard TCP 496 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 497 loss rate of 2.9e-8. 499 +------------------+-----------+---------+---------+---------+ 500 | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 501 +------------------+-----------+---------+---------+---------+ 502 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 503 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 504 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 505 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 506 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 507 +------------------+-----------+---------+---------+---------+ 509 Required packet loss rate for Standard TCP, HSTCP, and CUBIC to 510 achieve a certain throughput. We use 1500-byte packets and an RTT of 511 0.1 seconds. 513 Table 3 515 Our test results in [HKLRX06] indicate that CUBIC uses the spare 516 bandwidth left unused by existing Standard TCP flows in the same 517 bottleneck link without taking away much bandwidth from the existing 518 flows. 520 5.3. Difficult Environments 522 CUBIC is designed to remedy the poor performance of TCP in fast long- 523 distance networks. 525 5.4. Investigating a Range of Environments 527 CUBIC has been extensively studied by using both NS-2 simulation and 528 test-bed experiments covering a wide range of network environments. 529 More information can be found in [HKLRX06]. 531 Same as Standard TCP, CUBIC is a loss-based congestion control 532 algorithm. Therefore, CUBIC, which is designed to be more aggressive 533 than Standard TCP in fast and long distance networks, can fill large 534 drop-tail buffers more quickly than Standard TCP. In this case, 535 proper queue sizing and management [RFC7567] could be used to reduce 536 the packet queueing delay. 538 5.5. Protection against Congestion Collapse 540 With regard to the potential of causing congestion collapse, CUBIC 541 behaves like standard TCP since CUBIC modifies only the window 542 adjustment algorithm of TCP. Thus, it does not modify the ACK 543 clocking and Timeout behaviors of Standard TCP. 545 5.6. Fairness within the Alternative Congestion Control Algorithm. 547 CUBIC ensures convergence of competing CUBIC flows with the same RTT 548 in the same bottleneck links to an equal bandwidth share. When 549 competing flows have different RTTs, their bandwidth shares are 550 linearly proportional to the inverse of their RTT ratios. This is 551 true independent of the level of statistical multiplexing in the 552 link. 554 5.7. Performance with Misbehaving Nodes and Outside Attackers 556 This is not considered in the current CUBIC. 558 5.8. Behavior for Application-Limited Flows 560 CUBIC does not raise its congestion window size if the flow is 561 currently limited by the application instead of the congestion 562 window. In cases of idle periods, t in Eq. 1 MUST NOT include the 563 idle time; otherwise, W_cubic(t) might be very high after restarting 564 from a long idle time. 566 5.9. Responses to Sudden or Transient Events 568 In case that there is a sudden congestion, a routing change, or a 569 mobility event, CUBIC behaves the same as Standard TCP. 571 5.10. Incremental Deployment 573 CUBIC requires only the change of TCP senders, and does not require 574 any assistant of routers. 576 6. Security Considerations 578 This proposal makes no changes to the underlying security of TCP. 580 7. IANA Considerations 582 There are no IANA considerations regarding this document. 584 8. Acknowledgements 586 Alexander Zimmermann and Lars Eggert have received funding from the 587 European Union's Horizon 2020 research and innovation program 588 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 589 reflects only the authors' views and the European Commission is not 590 responsible for any use that may be made of the information it 591 contains. 593 9. References 595 9.1. Normative References 597 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 598 Selective Acknowledgment Options", RFC 2018, 599 DOI 10.17487/RFC2018, October 1996, 600 . 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 608 RFC 3649, DOI 10.17487/RFC3649, December 2003, 609 . 611 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 612 RFC 4960, DOI 10.17487/RFC4960, September 2007, 613 . 615 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 616 Control Algorithms", BCP 133, RFC 5033, 617 DOI 10.17487/RFC5033, August 2007, 618 . 620 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 621 Friendly Rate Control (TFRC): Protocol Specification", 622 RFC 5348, DOI 10.17487/RFC5348, September 2008, 623 . 625 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 626 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 627 . 629 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 630 NewReno Modification to TCP's Fast Recovery Algorithm", 631 RFC 6582, DOI 10.17487/RFC6582, April 2012, 632 . 634 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 635 Recommendations Regarding Active Queue Management", 636 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 637 . 639 9.2. Informative References 641 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 642 Ordering for Internet Congestion Control and its 643 Applications", In Proceedings of IEEE INFOCOM , May 2007. 645 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 646 Equation-Based and AIMD Congestion Control", May 2000. 648 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 649 Adjustment Algorithms", Technical Report TR2002-29, 650 Department of Computer Sciences , The University of Texas 651 at Austin , August 2002. 653 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 654 toward Realistic Performance Evaluation of High-Speed TCP 655 Variants", International Workshop on Protocols for Fast 656 Long-Distance Networks , February 2006. 658 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly 659 High-Speed TCP Variant", ACM SIGOPS Operating System 660 Review , 2008. 662 [K03] Kelly, T., "Scalable TCP: Improving Performance in 663 HighSpeed Wide Area Networks", ACM SIGCOMM Computer 664 Communication Review , April 2003. 666 [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control 667 for High Bandwidth-Delay Product Paths", Internet-draft 668 draft-leith-tcp-htcp-06 , April 2008. 670 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 671 Congestion Control for Fast, Long Distance Networks", In 672 Proceedings of IEEE INFOCOM , March 2004. 674 Authors' Addresses 676 Injong Rhee 677 North Carolina State University 678 Department of Computer Science 679 Raleigh, NC 27695-7534 680 US 682 Email: rhee@ncsu.edu 684 Lisong Xu 685 University of Nebraska-Lincoln 686 Department of Computer Science and Engineering 687 Lincoln, NE 68588-0115 688 US 690 Email: xu@unl.edu 692 Sangtae Ha 693 University of Colorado at Boulder 694 Department of Computer Science 695 Boulder, CO 80309-0430 696 US 698 Email: sangtae.ha@colorado.edu 699 Alexander Zimmermann 701 Phone: +49 175 5766838 702 Email: alexander.zimmermann@rwth-aachen.de 704 Lars Eggert 705 NetApp 706 Sonnenallee 1 707 Kirchheim 85551 708 Germany 710 Phone: +49 151 12055791 711 Email: lars@netapp.com 713 Richard Scheffenegger 715 Email: rscheff@gmx.at