idnits 2.17.1 draft-ietf-tcpm-cubic-06.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 (September 17, 2017) is 2405 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: March 21, 2018 UNL 6 S. Ha 7 Colorado 8 A. Zimmermann 10 L. Eggert 11 NetApp 12 R. Scheffenegger 13 September 17, 2017 15 CUBIC for Fast Long-Distance Networks 16 draft-ietf-tcpm-cubic-06 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 https://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 March 21, 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 (https://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 . . . . . . . . . . . . . . . . . . 12 80 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 81 5.4. Investigating a Range of Environments . . . . . . . . . . 13 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 . . . . . . . . . 14 88 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 14 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 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. 276 1) The TCP-friendly region, which ensures that CUBIC achieves at 277 least the same throughput as the standard TCP. 279 2) The concave region, if CUBIC is not in the TCP-friendly region 280 and cwnd is less than W_max. 282 3) The convex region, if CUBIC is not in the TCP-friendly region 283 and cwnd is greater than W_max. 285 Below, we describe the exact actions taken by CUBIC in each region. 287 4.2. TCP-friendly region 289 Standard TCP performs well in certain types of networks, for example, 290 under short RTT and small bandwidth (or small BDP) networks. In 291 these networks, we use the TCP-friendly region to ensure that CUBIC 292 achieves at least the same throughput as the standard TCP. 294 The TCP-friendly region is designed according to the analysis 295 described in [FHP00]. The analysis studies the performance of an 296 Additive Increase and Multiplicative Decrease (AIMD) algorithm with 297 an additive factor of alpha_aimd (segment per RTT) and a 298 multiplicative factor of beta_aimd, denoted by AIMD(alpha_aimd, 299 beta_aimd). Specifically, the average window size of 300 AIMD(alpha_aimd, beta_aimd) can be calculated using Eq. 3. The 301 analysis shows that AIMD(alpha_aimd, beta_aimd) with 302 alpha_aimd=3*(1-beta_aimd)/(1+beta_aimd) achieves the same average 303 window size as the standard TCP that uses AIMD(1, 0.5). 305 AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / 306 (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) 308 Based on the above analysis, CUBIC uses Eq. 4 to estimate the window 309 size W_est of AIMD(alpha_aimd, beta_aimd) with 310 alpha_aimd=3*(1-beta_cubic)/(1+beta_cubic) and beta_aimd=beta_cubic, 311 which achieves the same average window size as the standard TCP. 312 When receiving an ACK in congestion avoidance (cwnd could be greater 313 than or less than W_max), CUBIC checks whether W_cubic(t) is less 314 than W_est(t). If so, CUBIC is in the TCP-friendly region and cwnd 315 SHOULD be set to W_est(t) at each reception of ACK. 317 W_est(t) = W_max*beta_cubic + 318 [3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4) 320 4.3. Concave region 322 When receiving an ACK in congestion avoidance, if the protocol is not 323 in the TCP-friendly region and cwnd is less than W_max, then the 324 protocol is in the concave region. In this region, cwnd MUST be 325 incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, 326 where W_cubic(t+RTT) is calculated using Eq. 1. 328 4.4. Convex region 330 When the current window size of CUBIC is larger than W_max, it passes 331 the plateau of the cubic function after which CUBIC follows the 332 convex profile of the cubic function. Since cwnd is larger than the 333 previous saturation point W_max, this indicates that the network 334 conditions might have been perturbed since the last loss event, 335 possibly implying more available bandwidth after some flow 336 departures. Since the Internet is highly asynchronous, some amount 337 of perturbation is always possible without causing a major change in 338 available bandwidth. In this phase, CUBIC is being very careful by 339 very slowly increasing its window size. The convex profile ensures 340 that the window increases very slowly at the beginning and gradually 341 increases its growth rate. We also call this phase as the maximum 342 probing phase since CUBIC is searching for a new W_max. In this 343 region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for 344 each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1. 346 4.5. Multiplicative decrease 348 When a packet loss detected by duplicate ACKs or a network congestion 349 detected by ECN-Echo ACKs occurs, CUBIC updates its W_max, cwnd, and 350 ssthresh (slow start threshold) as follows. Parameter beta_cubic 351 SHOULD be set to 0.7. 353 W_max = cwnd; // save window size before reduction 354 ssthresh = cwnd * beta_cubic; // new slow start threshold 355 cwnd = cwnd * beta_cubic; // window reduction 357 A side effect of setting beta_cubic to a bigger value than 0.5 is 358 slower convergence. We believe that while a more adaptive setting of 359 beta_cubic could result in faster convergence, it will make the 360 analysis of the protocol much harder. This adaptive adjustment of 361 beta_cubic is an item for the next version of CUBIC. 363 4.6. Fast convergence 365 To improve the convergence speed of CUBIC, we add a heuristic in the 366 protocol. When a new flow joins the network, existing flows in the 367 network need to give up their bandwidth shares to allow the flow some 368 room for growth if the existing flows have been using all the 369 bandwidth of the network. To increase this release of bandwidth by 370 existing flows, the following mechanism called fast convergence 371 SHOULD be implemented. 373 With fast convergence, when a loss event occurs, before a window 374 reduction of congestion window, a flow remembers the last value of 375 W_max before it updates W_max for the current loss event. Let us 376 call the last value of W_max to be W_last_max. 378 if (W_max < W_last_max){ // should we make room for others 379 W_last_max = W_max; // remember the last W_max 380 W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max 381 } else { 382 W_last_max = W_max // remember the last W_max 383 } 385 At a loss event, if the current value of W_max is less than 386 W_last_max, this indicates that the saturation point experienced by 387 this flow is getting reduced because of the change in available 388 bandwidth. Then we allow this flow to release more bandwidth by 389 reducing W_max further. This action effectively lengthens the time 390 for this flow to increase its window because the reduced W_max forces 391 the flow to have the plateau earlier. This allows more time for the 392 new flow to catch up its window size 394 The fast convergence is designed for network environments with 395 multiple CUBIC flows. In network environments with only a single 396 CUBIC flow and without any other traffic, the fast convergence SHOULD 397 be disabled. 399 4.7. Timeout 401 In case of timeout, CUBIC follows the standard TCP to reduce cwnd, 402 but sets ssthresh using beta_cubic (same as in Section 4.5). 404 4.8. Slowstart 406 CUBIC MUST employ a slow start algorithm, when the cwnd is no more 407 than ssthresh. Among the slow start algorithms, CUBIC MAY choose the 408 standard TCP slow start [RFC5681] in general networks, or the limited 409 slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth 410 and long-distance networks. 412 In the case when CUBIC runs the hybrid slow start [HR08], it may exit 413 the first slow start without incurring any packet loss and thus W_max 414 is undefined. In this special case, CUBIC switches to congestion 415 avoidance and increases its congestion window size using Eq. 1 where 416 K is set to 0 and W_max is set to the window size when CUBIC just 417 exits the slow start. 419 5. Discussion 421 In this section, we further discuss the safety features of CUBIC 422 following the guidelines specified in [RFC5033]. 424 With a deterministic loss model where the number of packets between 425 two successive lost events is always 1/p, CUBIC always operates with 426 the concave window profile which greatly simplifies the performance 427 analysis of CUBIC. The average window size of CUBIC can be obtained 428 by the following function: 430 AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * 431 (RTT^0.75) / (p^0.75) (Eq. 5) 433 With beta_cubic set to 0.7, the above formula is reduced to: 435 AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6) 437 We will determine the value of C in the following subsection using 438 Eq. 6. 440 5.1. Fairness to standard TCP 442 In environments where standard TCP is able to make reasonable use of 443 the available bandwidth, CUBIC does not significantly change this 444 state. 446 Standard TCP performs well in the following two types of networks: 448 1. networks with a small bandwidth-delay product (BDP) 450 2. networks with a short RTT, but not necessarily a small BDP 452 CUBIC is designed to behave very similarly to standard TCP in the 453 above two types of networks. The following two tables show the 454 average window size of standard TCP, HSTCP, and CUBIC. The average 455 window size of standard TCP and HSTCP is from [RFC3649]. The average 456 window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP 457 friendly mode for three different values of C. 459 +----------+-------+--------+-------------+-------------+-----------+ 460 | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | 461 | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | 462 +----------+-------+--------+-------------+-------------+-----------+ 463 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 464 | 10^-3 | 38 | 38 | 38 | 38 | 59 | 465 | 10^-4 | 120 | 263 | 120 | 187 | 333 | 466 | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | 467 | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | 468 | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | 469 | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | 470 +----------+-------+--------+-------------+-------------+-----------+ 472 Response function of standard TCP, HSTCP, and CUBIC in networks with 473 RTT = 0.1 seconds. The average window size is in MSS-sized segments. 475 Table 1 477 +--------+-----------+-----------+------------+-----------+---------+ 478 | Loss | Average | Average | CUBIC | CUBIC | CUBIC | 479 | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | 480 +--------+-----------+-----------+------------+-----------+---------+ 481 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 482 | 10^-3 | 38 | 38 | 38 | 38 | 38 | 483 | 10^-4 | 120 | 263 | 120 | 120 | 120 | 484 | 10^-5 | 379 | 1795 | 379 | 379 | 379 | 485 | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | 486 | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | 487 | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | 488 +--------+-----------+-----------+------------+-----------+---------+ 490 Response function of standard TCP, HSTCP, and CUBIC in networks with 491 RTT = 0.01 seconds. The average window size is in MSS-sized 492 segments. 494 Table 2 496 Both tables show that CUBIC with any of these three C values is more 497 friendly to TCP than HSTCP, especially in networks with a short RTT 498 where TCP performs reasonably well. For example, in a network with 499 RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 500 packets. If the packet size is 1500 bytes, then TCP can achieve an 501 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 502 achieves exactly the same rate as Standard TCP, whereas HSTCP is 503 about ten times more aggressive than Standard TCP. 505 We can see that C determines the aggressiveness of CUBIC in competing 506 with other protocols for the bandwidth. CUBIC is more friendly to 507 the Standard TCP, if the value of C is lower. However, we do not 508 recommend to set C to a very low value like 0.04, since CUBIC with a 509 low C cannot efficiently use the bandwidth in long RTT and high 510 bandwidth networks. Based on these observations and our experiments, 511 we find C=0.4 gives a good balance between TCP-friendliness and 512 aggressiveness of window growth. Therefore, C SHOULD be set to 0.4. 513 With C set to 0.4, Eq. 6 is reduced to: 515 AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) 517 Eq. 7 is then used in the next subsection to show the scalability of 518 CUBIC. 520 5.2. Using Spare Capacity 522 CUBIC uses a more aggressive window growth function than Standard TCP 523 under long RTT and high bandwidth networks. 525 The following table shows that to achieve 10Gbps rate, standard TCP 526 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 527 loss rate of 2.9e-8. 529 +------------------+-----------+---------+---------+---------+ 530 | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 531 +------------------+-----------+---------+---------+---------+ 532 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 533 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 534 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 535 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 536 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 537 +------------------+-----------+---------+---------+---------+ 539 Required packet loss rate for Standard TCP, HSTCP, and CUBIC to 540 achieve a certain throughput. We use 1500-byte packets and an RTT of 541 0.1 seconds. 543 Table 3 545 Our test results in [HKLRX06] indicate that CUBIC uses the spare 546 bandwidth left unused by existing Standard TCP flows in the same 547 bottleneck link without taking away much bandwidth from the existing 548 flows. 550 5.3. Difficult Environments 552 CUBIC is designed to remedy the poor performance of TCP in fast long- 553 distance networks. 555 5.4. Investigating a Range of Environments 557 CUBIC has been extensively studied by using both NS-2 simulation and 558 test-bed experiments covering a wide range of network environments. 559 More information can be found in [HKLRX06]. 561 Same as Standard TCP, CUBIC is a loss-based congestion control 562 algorithm. Because CUBIC is designed to be more aggressive (due to 563 faster window growth function and bigger multiplicative decrease 564 factor) than Standard TCP in fast and long distance networks, it can 565 fill large drop-tail buffers more quickly than Standard TCP and 566 increase the risk of a standing queue[KWAF16]. In this case, proper 567 queue sizing and management [RFC7567] could be used to reduce the 568 packet queueing delay. 570 5.5. Protection against Congestion Collapse 572 With regard to the potential of causing congestion collapse, CUBIC 573 behaves like standard TCP since CUBIC modifies only the window 574 adjustment algorithm of TCP. Thus, it does not modify the ACK 575 clocking and Timeout behaviors of Standard TCP. 577 5.6. Fairness within the Alternative Congestion Control Algorithm. 579 CUBIC ensures convergence of competing CUBIC flows with the same RTT 580 in the same bottleneck links to an equal bandwidth share. When 581 competing flows have different RTTs, their bandwidth shares are 582 linearly proportional to the inverse of their RTT ratios. This is 583 true independent of the level of statistical multiplexing in the 584 link. 586 5.7. Performance with Misbehaving Nodes and Outside Attackers 588 This is not considered in the current CUBIC. 590 5.8. Behavior for Application-Limited Flows 592 CUBIC does not raise its congestion window size if the flow is 593 currently limited by the application instead of the congestion 594 window. In case of long periods when cwnd has not been updated due 595 to the application rate limit, such as idle periods, t in Eq. 1 MUST 596 NOT include these periods; otherwise, W_cubic(t) might be very high 597 after restarting from these periods. 599 5.9. Responses to Sudden or Transient Events 601 In case that there is a sudden congestion, a routing change, or a 602 mobility event, CUBIC behaves the same as Standard TCP. 604 5.10. Incremental Deployment 606 CUBIC requires only the change of TCP senders, and does not require 607 any assistant of routers. 609 6. Security Considerations 611 This proposal makes no changes to the underlying security of TCP. 613 7. IANA Considerations 615 There are no IANA considerations regarding this document. 617 8. Acknowledgements 619 Alexander Zimmermann and Lars Eggert have received funding from the 620 European Union's Horizon 2020 research and innovation program 621 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 622 reflects only the authors' views and the European Commission is not 623 responsible for any use that may be made of the information it 624 contains. 626 9. References 628 9.1. Normative References 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 636 RFC 3649, DOI 10.17487/RFC3649, December 2003, 637 . 639 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 640 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 641 2004, . 643 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 644 RFC 4960, DOI 10.17487/RFC4960, September 2007, 645 . 647 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 648 Control Algorithms", BCP 133, RFC 5033, 649 DOI 10.17487/RFC5033, August 2007, 650 . 652 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 653 Friendly Rate Control (TFRC): Protocol Specification", 654 RFC 5348, DOI 10.17487/RFC5348, September 2008, 655 . 657 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 658 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 659 . 661 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 662 NewReno Modification to TCP's Fast Recovery Algorithm", 663 RFC 6582, DOI 10.17487/RFC6582, April 2012, 664 . 666 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 667 and Y. Nishida, "A Conservative Loss Recovery Algorithm 668 Based on Selective Acknowledgment (SACK) for TCP", 669 RFC 6675, DOI 10.17487/RFC6675, August 2012, 670 . 672 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 673 Recommendations Regarding Active Queue Management", 674 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 675 . 677 9.2. Informative References 679 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 680 Ordering for Internet Congestion Control and its 681 Applications", In Proceedings of IEEE INFOCOM , May 2007. 683 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 684 Equation-Based and AIMD Congestion Control", May 2000. 686 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 687 Adjustment Algorithms", Technical Report TR2002-29, 688 Department of Computer Sciences , The University of Texas 689 at Austin , August 2002. 691 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 692 toward Realistic Performance Evaluation of High-Speed TCP 693 Variants", International Workshop on Protocols for Fast 694 Long-Distance Networks , February 2006. 696 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth 697 and Long-Distance Networks", International Workshop on 698 Protocols for Fast Long-Distance Networks , 2008. 700 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly 701 High-Speed TCP Variant", ACM SIGOPS Operating System 702 Review , 2008. 704 [K03] Kelly, T., "Scalable TCP: Improving Performance in 705 HighSpeed Wide Area Networks", ACM SIGCOMM Computer 706 Communication Review , April 2003. 708 [KWAF16] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 709 "TCP Alternative Backoff with ECN (ABE)", Internet-draft, 710 IETF work-in-progress draft-khademi-tcpm- 711 alternativebackoff-ecn-01 , October 2016. 713 [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control 714 for High Bandwidth-Delay Product Paths", Internet-draft 715 draft-leith-tcp-htcp-06 , April 2008. 717 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 718 Congestion Control for Fast, Long Distance Networks", In 719 Proceedings of IEEE INFOCOM , March 2004. 721 Authors' Addresses 723 Injong Rhee 724 North Carolina State University 725 Department of Computer Science 726 Raleigh, NC 27695-7534 727 US 729 Email: rhee@ncsu.edu 731 Lisong Xu 732 University of Nebraska-Lincoln 733 Department of Computer Science and Engineering 734 Lincoln, NE 68588-0115 735 US 737 Email: xu@unl.edu 738 Sangtae Ha 739 University of Colorado at Boulder 740 Department of Computer Science 741 Boulder, CO 80309-0430 742 US 744 Email: sangtae.ha@colorado.edu 746 Alexander Zimmermann 748 Phone: +49 175 5766838 749 Email: alexander.zimmermann@rwth-aachen.de 751 Lars Eggert 752 NetApp 753 Sonnenallee 1 754 Kirchheim 85551 755 Germany 757 Phone: +49 151 12055791 758 Email: lars@netapp.com 760 Richard Scheffenegger 762 Email: rscheff@gmx.at