idnits 2.17.1 draft-ietf-tcpm-cubic-05.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 (July 17, 2017) is 2476 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: January 18, 2018 UNL 6 S. Ha 7 Colorado 8 A. Zimmermann 10 L. Eggert 11 NetApp 12 R. Scheffenegger 13 July 17, 2017 15 CUBIC for Fast Long-Distance Networks 16 draft-ietf-tcpm-cubic-05 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 January 18, 2018. 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 4.8. Slowstart . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 10 79 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11 80 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 81 5.4. Investigating a Range of Environments . . . . . . . . . . 12 82 5.5. Protection against Congestion Collapse . . . . . . . . . 13 83 5.6. Fairness within the Alternative Congestion Control 84 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.7. Performance with Misbehaving Nodes and Outside Attackers 13 86 5.8. Behavior for Application-Limited Flows . . . . . . . . . 13 87 5.9. Responses to Sudden or Transient Events . . . . . . . . . 13 88 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 The low utilization problem of TCP in fast long-distance networks is 100 well documented in [K03][RFC3649]. This problem arises from a slow 101 increase of congestion window following a congestion event in a 102 network with a large bandwidth delay product (BDP). Our experience 103 [HKLRX06] indicates that this problem is frequently observed even in 104 the range of congestion window sizes over several hundreds of packets 105 (each packet is sized around 1000 bytes) especially under a network 106 path with over 100ms round-trip times (RTTs). This problem is 107 equally applicable to all Reno style TCP standards and their 108 variants, including TCP-RENO [RFC5681], TCP-NewReno 109 [RFC6582][RFC6675], SCTP [RFC4960], TFRC [RFC5348] that use the same 110 linear increase function for window growth, which we refer to 111 collectively as Standard TCP below. 113 CUBIC [HRX08] is a modification to the congestion control mechanism 114 of Standard TCP, in particular, to the window increase function of 115 Standard TCP senders, to remedy this problem. Specifically, it uses 116 a cubic function instead of a linear window increase function of the 117 Standrad TCP to improve scalability and stability under fast and long 118 distance networks. 120 BIC-TCP, a predecessor of CUBIC, has been selected as default TCP 121 congestion control algorithm by Linux in the year 2005 and been used 122 for several years by the Internet community at large. CUBIC uses a 123 similar window growth function as BIC-TCP and is designed to be less 124 aggressive and fairer to TCP in bandwidth usage than BIC-TCP while 125 maintaining the strengths of BIC-TCP such as stability, window 126 scalability and RTT fairness. CUBIC has already been deployed 127 globally by Linux. Through extensive testing in various Internet 128 scenarios, we believe that CUBIC is safe for testing and deployment 129 in the global Internet. 131 In the ensuing sections, we first brefly explain the design principle 132 of CUBIC, then provide the exact specification of CUBIC, and finally 133 discuss the safety features of CUBIC following the guidelines 134 specified in [RFC5033]. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Design principle of CUBIC 144 CUBIC [HRX08] uses a cubic window increase function in terms of the 145 elapsed time from the last congestion event. While most alternative 146 algorithms to Standard TCP uses a convex increase function where 147 during congestion avoidance the window increment is always 148 increasing, CUBIC uses both the concave and convex profiles of a 149 cubic function for window increase. After a window reduction 150 following a loss event detected by duplicate ACKs, it registers the 151 window size where it got the loss event as W_max and performs a 152 multiplicative decrease of congestion window and the regular fast 153 recovery and retransmit of Standard TCP. After it enters into 154 congestion avoidance from fast recovery, it starts to increase the 155 window using the concave profile of the cubic function. The cubic 156 function is set to have its plateau at W_max so the concave growth 157 continues until the window size becomes W_max. After that, the cubic 158 function turns into a convex profile and the convex window growth 159 begins. This style of window adjustment (concave and then convex) 160 improves protocol and network stability while maintaining high 161 network utilization [CEHRX07]. This is because the window size 162 remains almost constant, forming a plateau around W_max where network 163 utilization is deemed highest and under steady state, most window 164 size samples of CUBIC are close to W_max, thus promoting high network 165 utilization and protocol stability. Note that protocols with convex 166 increase functions have the maximum increments around W_max and 167 introduces a large number of packet bursts around the saturation 168 point of the network, likely causing frequent global loss 169 synchronizations. 171 Another notable feature of CUBIC is that its window increase rate is 172 mostly independent of RTT, and follows a (cubic) function of the 173 elapsed time from the beginning of congestion avoidance. This 174 feature promotes per-flow fairness to Standard TCP as well as RTT- 175 fairness. Note that Standard TCP performs well under short RTT and 176 small bandwidth (or small BDP) networks. Only in a large long RTT 177 and large bandwidth (or large BDP) networks, it has the scalability 178 problem. An alternative protocol to Standard TCP designed to be 179 friendly to Standard TCP at a per-flow basis must operate to increase 180 its window much less aggressively in small BDP networks than in large 181 BDP networks. In CUBIC, its window growth rate is slowest around the 182 inflection point of the cubic function and this function does not 183 depend on RTT. In a smaller BDP network where Standard TCP flows are 184 working well, the absolute amount of the window decrease at a loss 185 event is always smaller because of the multiplicative decrease. 186 Therefore, in CUBIC, the starting window size after a loss event from 187 which the window starts to increase, is smaller in a smaller BDP 188 network, thus falling nearer to the plateau of the cubic function 189 where the growth rate is slowest. By setting appropriate values of 190 the cubic function parameters, CUBIC sets its growth rate always no 191 faster than Standard TCP around its inflection point. When the cubic 192 function grows slower than the window of Standard TCP, CUBIC simply 193 follows the window size of Standard TCP to ensure fairness to 194 Standard TCP in a small BDP network. We call this region where CUBIC 195 behaves like Standard TCP, the TCP-friendly region. 197 CUBIC maintains the same window growth rate independent of RTTs 198 outside of the TCP-friendly region, and flows with different RTTs 199 have the similar window sizes under steady state when they operate 200 outside the TCP-friendly region. This ensures CUBIC flows with 201 different RTTs to have their bandwidth shares (approximately, window/ 202 RTT) linearly proportional to the inverse of their RTT ratio (the 203 longer RTT, the smaller the share). This behavior is the same as 204 that of Standard TCP under high statistical multiplexing environments 205 where packet losses are independent of individual flow rates. 206 However, under low statistical multiplexing environments, the 207 bandwidth share ratio of Standard TCP flows with different RTTs is 208 squarely proportional to the inverse of their RTT ratio [XHR04]. 209 CUBIC always ensures the linear ratio independent of the levels of 210 statistical multiplexing. This is an improvement over Standard TCP. 211 While there is no consensus on a particular bandwidth share ratios of 212 different RTT flows, we believe that under wired Internet, use of the 213 linear share notion seems more reasonable than equal share or a 214 higher order shares. HTCP [LS08] currently uses the equal share. 216 CUBIC sets the multiplicative window decrease factor to 0.7 while 217 Standard TCP uses 0.5. While this improves the scalability of the 218 protocol, a side effect of this decision is slower convergence 219 especially under low statistical multiplexing environments. This 220 design choice is following the observation that the author of HSTCP 221 [RFC3649] has made along with other researchers (e.g., [GV02]): the 222 current Internet becomes more asynchronous with less frequent loss 223 synchronizations with high statistical multiplexing. Under this 224 environment, even strict Multiplicative-Increase Multiplicative- 225 Decrease (MIMD) can converge. CUBIC flows with the same RTT always 226 converge to the same share of bandwidth independent of statistical 227 multiplexing, thus achieving intra-protocol fairness. We also find 228 that under the environments with sufficient statistical multiplexing, 229 the convergence speed of CUBIC flows is reasonable. 231 4. CUBIC Congestion Control 233 The unit of all window sizes in this document is segments of the 234 maximum segment size (MSS), and the unit of all times is seconds. 236 4.1. Window growth function 238 CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by 239 increasing congestion window only at the reception of ACK. The 240 protocol does not make any change to the fast recovery and retransmit 241 of TCP, such as TCP-NewReno [RFC6582] [RFC6675]. During congestion 242 avoidance after fast recovery, CUBIC changes the window update 243 algorithm of Standard TCP. Suppose that W_max is the window size 244 before the window is reduced in the last fast retransmit and 245 recovery. 247 The window growth function of CUBIC uses the following function: 249 W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) 251 where C is a constant fixed to determine the aggressiveness of window 252 growth in high BDP networks, t is the elapsed time from the last 253 window reduction that is measured right after the fast recovery in 254 response to duplicate ACKs or after the congestion window reduction 255 in response to ECN-Echo ACKs, and K is the time period that the above 256 function takes to increase the current window size to W_max if there 257 is no further loss event and is calculated by using the following 258 equation: 260 K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) 262 where beta_cubic is the CUBIC multiplication decrease factor, that 263 is, when a packet loss detected by duplicate ACKs or a network 264 congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its 265 current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how 266 we set beta_cubic in Section 4.5 and how we set C in Section 5. 268 Upon receiving an ACK during congestion avoidance, CUBIC computes the 269 window growth rate during the next RTT period using Eq. 1. It sets 270 W_cubic(t+RTT) as the candidate target value of congestion window, 271 where RTT is the weithed average RTT calculated by the standard TCP. 273 Depending on the value of the current window size cwnd, CUBIC runs in 274 three different modes. First, if cwnd is less than the window size 275 that Standard TCP would reach at time t after the last loss event, 276 then CUBIC is in the TCP friendly region (we describe below how to 277 determine this window size of Standard TCP in term of time t). 278 Otherwise, if cwnd is less than W_max, then CUBIC is the concave 279 region, and if cwnd is larger than W_max, CUBIC is in the convex 280 region. Below, we describe the exact actions taken by CUBIC in each 281 region. 283 4.2. TCP-friendly region 285 Standard TCP performs well in certain types of networks, for example, 286 under short RTT and small bandwidth (or small BDP) networks. In 287 these networks, we use the TCP-friendly region to ensure that CUBIC 288 achieves at least the same throughput as the standard TCP. 290 When receiving an ACK in congestion avoidance, we first check whether 291 the protocol is in the TCP region or not. This is done by estimating 292 the average rate of the Standard TCP using a simple analysis 293 described in [FHP00]. It considers the Standard TCP as a special 294 case of an Additive Increase and Multiplicative Decrease algorithm 295 (AIMD), which has an additive factor alpha_aimd and a multiplicative 296 factor beta_aimd with the following function: 298 AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / 299 (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) 301 By the same analysis, the average window size of Standard TCP is 302 (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with 303 alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as 304 that of Standard TCP, alpha_aimd must be equal to 305 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by 306 alpha_aimd per RTT, we can get the window size of AIMD in terms of 307 the elapsed time t as follows: 309 W_aimd(t) = W_max*beta_aimd + 310 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) 312 If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd 313 is greater than or less than W_max), then the protocol is in the TCP 314 friendly region and cwnd SHOULD be set to W_aimd(t) at each reception 315 of ACK. 317 4.3. Concave region 319 When receiving an ACK in congestion avoidance, if the protocol is not 320 in the TCP-friendly region and cwnd is less than W_max, then the 321 protocol is in the concave region. In this region, cwnd MUST be 322 incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, 323 where W_cubic(t+RTT) is calculated using Eq. 1. 325 4.4. Convex region 327 When the current window size of CUBIC is larger than W_max, it passes 328 the plateau of the cubic function after which CUBIC follows the 329 convex profile of the cubic function. Since cwnd is larger than the 330 previous saturation point W_max, this indicates that the network 331 conditions might have been perturbed since the last loss event, 332 possibly implying more available bandwidth after some flow 333 departures. Since the Internet is highly asynchronous, some amount 334 of perturbation is always possible without causing a major change in 335 available bandwidth. In this phase, CUBIC is being very careful by 336 very slowly increasing its window size. The convex profile ensures 337 that the window increases very slowly at the beginning and gradually 338 increases its growth rate. We also call this phase as the maximum 339 probing phase since CUBIC is searching for a new W_max. In this 340 region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for 341 each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1. 343 4.5. Multiplicative decrease 345 When a packet loss detected by duplicate ACKs or a network congestion 346 detected by ECN-Echo ACKs occurs, CUBIC updates its W_max, cwnd, and 347 ssthresh (slow start threshold) as follows. Parameter beta_cubic 348 SHOULD be set to 0.7. 350 W_max = cwnd; // save window size before reduction 351 ssthresh = cwnd * beta_cubic; // new slow start threshold 352 cwnd = cwnd * beta_cubic; // window reduction 354 A side effect of setting beta_cubic to a bigger value than 0.5 is 355 slower convergence. We believe that while a more adaptive setting of 356 beta_cubic could result in faster convergence, it will make the 357 analysis of the protocol much harder. This adaptive adjustment of 358 beta_cubic is an item for the next version of CUBIC. 360 4.6. Fast convergence 362 To improve the convergence speed of CUBIC, we add a heuristic in the 363 protocol. When a new flow joins the network, existing flows in the 364 network need to give up their bandwidth shares to allow the flow some 365 room for growth if the existing flows have been using all the 366 bandwidth of the network. To increase this release of bandwidth by 367 existing flows, the following mechanism called fast convergence 368 SHOULD be implemented. 370 With fast convergence, when a loss event occurs, before a window 371 reduction of congestion window, a flow remembers the last value of 372 W_max before it updates W_max for the current loss event. Let us 373 call the last value of W_max to be W_last_max. 375 if (W_max < W_last_max){ // should we make room for others 376 W_last_max = W_max; // remember the last W_max 377 W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max 378 } else { 379 W_last_max = W_max // remember the last W_max 380 } 382 At a loss event, if the current value of W_max is less than 383 W_last_max, this indicates that the saturation point experienced by 384 this flow is getting reduced because of the change in available 385 bandwidth. Then we allow this flow to release more bandwidth by 386 reducing W_max further. This action effectively lengthens the time 387 for this flow to increase its window because the reduced W_max forces 388 the flow to have the plateau earlier. This allows more time for the 389 new flow to catch up its window size 391 The fast convergence is designed for network environments with 392 multiple CUBIC flows. In network environments with only a single 393 CUBIC flow and without any other traffic, the fast convergence SHOULD 394 be disabled. 396 4.7. Timeout 398 In case of timeout, CUBIC follows the standard TCP to reduce cwnd, 399 but sets ssthresh using beta_cubic (same as in Section 4.5). 401 4.8. Slowstart 403 CUBIC MUST employ a slow start algorithm, when the cwnd is no more 404 than ssthresh. Among the slow start algorithms, CUBIC MAY choose the 405 standard TCP slow start[RFC5681] in general networks, or the limited 406 slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth 407 and long-distance networks. 409 5. Discussion 411 In this section, we further discuss the safety features of CUBIC 412 following the guidelines specified in [RFC5033]. 414 With a deterministic loss model where the number of packets between 415 two successive lost events is always 1/p, CUBIC always operates with 416 the concave window profile which greatly simplifies the performance 417 analysis of CUBIC. The average window size of CUBIC can be obtained 418 by the following function: 420 AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * 421 (RTT^0.75) / (p^0.75) (Eq. 5) 423 With beta_cubic set to 0.7, the above formula is reduced to: 425 AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6) 427 We will determine the value of C in the following subsection using 428 Eq. 6. 430 5.1. Fairness to standard TCP 432 In environments where standard TCP is able to make reasonable use of 433 the available bandwidth, CUBIC does not significantly change this 434 state. 436 Standard TCP performs well in the following two types of networks: 438 1. networks with a small bandwidth-delay product (BDP) 440 2. networks with a short RTT, but not necessarily a small BDP 442 CUBIC is designed to behave very similarly to standard TCP in the 443 above two types of networks. The following two tables show the 444 average window size of standard TCP, HSTCP, and CUBIC. The average 445 window size of standard TCP and HSTCP is from [RFC3649]. The average 446 window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP 447 friendly mode for three different values of C. 449 +----------+-------+--------+-------------+-------------+-----------+ 450 | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | 451 | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | 452 +----------+-------+--------+-------------+-------------+-----------+ 453 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 454 | 10^-3 | 38 | 38 | 38 | 38 | 59 | 455 | 10^-4 | 120 | 263 | 120 | 187 | 333 | 456 | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | 457 | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | 458 | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | 459 | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | 460 +----------+-------+--------+-------------+-------------+-----------+ 462 Response function of standard TCP, HSTCP, and CUBIC in networks with 463 RTT = 0.1 seconds. The average window size is in MSS-sized segments. 465 Table 1 467 +--------+-----------+-----------+------------+-----------+---------+ 468 | Loss | Average | Average | CUBIC | CUBIC | CUBIC | 469 | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | 470 +--------+-----------+-----------+------------+-----------+---------+ 471 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 472 | 10^-3 | 38 | 38 | 38 | 38 | 38 | 473 | 10^-4 | 120 | 263 | 120 | 120 | 120 | 474 | 10^-5 | 379 | 1795 | 379 | 379 | 379 | 475 | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | 476 | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | 477 | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | 478 +--------+-----------+-----------+------------+-----------+---------+ 480 Response function of standard TCP, HSTCP, and CUBIC in networks with 481 RTT = 0.01 seconds. The average window size is in MSS-sized 482 segments. 484 Table 2 486 Both tables show that CUBIC with any of these three C values is more 487 friendly to TCP than HSTCP, especially in networks with a short RTT 488 where TCP performs reasonably well. For example, in a network with 489 RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 490 packets. If the packet size is 1500 bytes, then TCP can achieve an 491 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 492 achieves exactly the same rate as Standard TCP, whereas HSTCP is 493 about ten times more aggressive than Standard TCP. 495 We can see that C determines the aggressiveness of CUBIC in competing 496 with other protocols for the bandwidth. CUBIC is more friendly to 497 the Standard TCP, if the value of C is lower. However, we do not 498 recommend to set C to a very low value like 0.04, since CUBIC with a 499 low C cannot efficiently use the bandwidth in long RTT and high 500 bandwidth networks. Based on these observations and our experiments, 501 we find C=0.4 gives a good balance between TCP-friendliness and 502 aggressiveness of window growth. Therefore, C SHOULD be set to 0.4. 503 With C set to 0.4, Eq. 6 is reduced to: 505 AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) 507 Eq. 7 is then used in the next subsection to show the scalability of 508 CUBIC. 510 5.2. Using Spare Capacity 512 CUBIC uses a more aggressive window growth function than Standard TCP 513 under long RTT and high bandwidth networks. 515 The following table shows that to achieve 10Gbps rate, standard TCP 516 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 517 loss rate of 2.9e-8. 519 +------------------+-----------+---------+---------+---------+ 520 | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 521 +------------------+-----------+---------+---------+---------+ 522 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 523 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 524 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 525 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 526 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 527 +------------------+-----------+---------+---------+---------+ 529 Required packet loss rate for Standard TCP, HSTCP, and CUBIC to 530 achieve a certain throughput. We use 1500-byte packets and an RTT of 531 0.1 seconds. 533 Table 3 535 Our test results in [HKLRX06] indicate that CUBIC uses the spare 536 bandwidth left unused by existing Standard TCP flows in the same 537 bottleneck link without taking away much bandwidth from the existing 538 flows. 540 5.3. Difficult Environments 542 CUBIC is designed to remedy the poor performance of TCP in fast long- 543 distance networks. 545 5.4. Investigating a Range of Environments 547 CUBIC has been extensively studied by using both NS-2 simulation and 548 test-bed experiments covering a wide range of network environments. 549 More information can be found in [HKLRX06]. 551 Same as Standard TCP, CUBIC is a loss-based congestion control 552 algorithm. Because CUBIC is designed to be more aggressive (due to 553 faster window growth function and bigger multiplicative decrease 554 factor) than Standard TCP in fast and long distance networks, it can 555 fill large drop-tail buffers more quickly than Standard TCP and 556 increase the risk of a standing queue[KWAF16]. In this case, proper 557 queue sizing and management [RFC7567] could be used to reduce the 558 packet queueing delay. 560 5.5. Protection against Congestion Collapse 562 With regard to the potential of causing congestion collapse, CUBIC 563 behaves like standard TCP since CUBIC modifies only the window 564 adjustment algorithm of TCP. Thus, it does not modify the ACK 565 clocking and Timeout behaviors of Standard TCP. 567 5.6. Fairness within the Alternative Congestion Control Algorithm. 569 CUBIC ensures convergence of competing CUBIC flows with the same RTT 570 in the same bottleneck links to an equal bandwidth share. When 571 competing flows have different RTTs, their bandwidth shares are 572 linearly proportional to the inverse of their RTT ratios. This is 573 true independent of the level of statistical multiplexing in the 574 link. 576 5.7. Performance with Misbehaving Nodes and Outside Attackers 578 This is not considered in the current CUBIC. 580 5.8. Behavior for Application-Limited Flows 582 CUBIC does not raise its congestion window size if the flow is 583 currently limited by the application instead of the congestion 584 window. In case of long periods when cwnd is not updated due to the 585 application rate limit, such as idle periods, t in Eq. 1 MUST NOT 586 include these periods; otherwise, W_cubic(t) might be very high after 587 restarting from these periods. 589 5.9. Responses to Sudden or Transient Events 591 In case that there is a sudden congestion, a routing change, or a 592 mobility event, CUBIC behaves the same as Standard TCP. 594 5.10. Incremental Deployment 596 CUBIC requires only the change of TCP senders, and does not require 597 any assistant of routers. 599 6. Security Considerations 601 This proposal makes no changes to the underlying security of TCP. 603 7. IANA Considerations 605 There are no IANA considerations regarding this document. 607 8. Acknowledgements 609 Alexander Zimmermann and Lars Eggert have received funding from the 610 European Union's Horizon 2020 research and innovation program 611 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 612 reflects only the authors' views and the European Commission is not 613 responsible for any use that may be made of the information it 614 contains. 616 9. References 618 9.1. Normative References 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 626 RFC 3649, DOI 10.17487/RFC3649, December 2003, 627 . 629 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 630 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 631 2004, . 633 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 634 RFC 4960, DOI 10.17487/RFC4960, September 2007, 635 . 637 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 638 Control Algorithms", BCP 133, RFC 5033, 639 DOI 10.17487/RFC5033, August 2007, 640 . 642 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 643 Friendly Rate Control (TFRC): Protocol Specification", 644 RFC 5348, DOI 10.17487/RFC5348, September 2008, 645 . 647 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 648 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 649 . 651 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 652 NewReno Modification to TCP's Fast Recovery Algorithm", 653 RFC 6582, DOI 10.17487/RFC6582, April 2012, 654 . 656 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 657 and Y. Nishida, "A Conservative Loss Recovery Algorithm 658 Based on Selective Acknowledgment (SACK) for TCP", 659 RFC 6675, DOI 10.17487/RFC6675, August 2012, 660 . 662 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 663 Recommendations Regarding Active Queue Management", 664 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 665 . 667 9.2. Informative References 669 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 670 Ordering for Internet Congestion Control and its 671 Applications", In Proceedings of IEEE INFOCOM , May 2007. 673 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 674 Equation-Based and AIMD Congestion Control", May 2000. 676 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 677 Adjustment Algorithms", Technical Report TR2002-29, 678 Department of Computer Sciences , The University of Texas 679 at Austin , August 2002. 681 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 682 toward Realistic Performance Evaluation of High-Speed TCP 683 Variants", International Workshop on Protocols for Fast 684 Long-Distance Networks , February 2006. 686 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth 687 and Long-Distance Networks", International Workshop on 688 Protocols for Fast Long-Distance Networks , 2008. 690 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly 691 High-Speed TCP Variant", ACM SIGOPS Operating System 692 Review , 2008. 694 [K03] Kelly, T., "Scalable TCP: Improving Performance in 695 HighSpeed Wide Area Networks", ACM SIGCOMM Computer 696 Communication Review , April 2003. 698 [KWAF16] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 699 "TCP Alternative Backoff with ECN (ABE)", Internet-draft, 700 IETF work-in-progress draft-khademi-tcpm- 701 alternativebackoff-ecn-01 , October 2016. 703 [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control 704 for High Bandwidth-Delay Product Paths", Internet-draft 705 draft-leith-tcp-htcp-06 , April 2008. 707 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 708 Congestion Control for Fast, Long Distance Networks", In 709 Proceedings of IEEE INFOCOM , March 2004. 711 Authors' Addresses 713 Injong Rhee 714 North Carolina State University 715 Department of Computer Science 716 Raleigh, NC 27695-7534 717 US 719 Email: rhee@ncsu.edu 721 Lisong Xu 722 University of Nebraska-Lincoln 723 Department of Computer Science and Engineering 724 Lincoln, NE 68588-0115 725 US 727 Email: xu@unl.edu 729 Sangtae Ha 730 University of Colorado at Boulder 731 Department of Computer Science 732 Boulder, CO 80309-0430 733 US 735 Email: sangtae.ha@colorado.edu 737 Alexander Zimmermann 739 Phone: +49 175 5766838 740 Email: alexander.zimmermann@rwth-aachen.de 741 Lars Eggert 742 NetApp 743 Sonnenallee 1 744 Kirchheim 85551 745 Germany 747 Phone: +49 151 12055791 748 Email: lars@netapp.com 750 Richard Scheffenegger 752 Email: rscheff@gmx.at