idnits 2.17.1 draft-ietf-tcpm-cubic-02.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 (August 5, 2016) is 2821 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: February 6, 2017 UNL 6 S. Ha 7 Colorado 8 A. Zimmermann 9 L. Eggert 10 R. Scheffenegger 11 NetApp 12 August 5, 2016 14 CUBIC for Fast Long-Distance Networks 15 draft-ietf-tcpm-cubic-02 17 Abstract 19 CUBIC is an extension to the current TCP standards. The protocol 20 differs from the current TCP standards only in the congestion window 21 adjustment function in the sender side. In particular, it uses a 22 cubic function instead of a linear window increase of the current TCP 23 standards to improve scalability and stability under fast and long 24 distance networks. BIC-TCP, a predecessor of CUBIC, has been a 25 default TCP adopted by Linux since year 2005 and has already been 26 deployed globally and in use for several years by the Internet 27 community at large. CUBIC is using a similar window growth function 28 as BIC-TCP and is designed to be less aggressive and fairer to TCP in 29 bandwidth usage than BIC-TCP while maintaining the strengths of BIC- 30 TCP such as stability, window scalability and RTT fairness. Through 31 extensive testing in various Internet scenarios, we believe that 32 CUBIC is safe for deployment and testing in the global Internet. The 33 intent of this document is to provide the protocol specification of 34 CUBIC for a third party implementation and solicit the community 35 feedback through experimentation on the performance of CUBIC. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 6, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 74 3.1. Window growth function . . . . . . . . . . . . . . . . . 5 75 3.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 6 76 3.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 78 3.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 7 79 3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7 80 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8 82 4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10 83 4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11 84 4.4. Investigating a Range of Environments . . . . . . . . . . 11 85 4.5. Protection against Congestion Collapse . . . . . . . . . 11 86 4.6. Fairness within the Alternative Congestion Control 87 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.7. Performance with Misbehaving Nodes and Outside Attackers 11 89 4.8. Behavior for Application-Limited Flows . . . . . . . . . 11 90 4.9. Responses to Sudden or Transient Events . . . . . . . . . 11 91 4.10. Incremental Deployment . . . . . . . . . . . . . . . . . 12 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 8.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 The low utilization problem of TCP in fast long-distance networks is 103 well documented in [K03][RFC3649]. This problem arises from a slow 104 increase of congestion window following a congestion event in a 105 network with a large bandwidth delay product (BDP). Our experience 106 [HKLRX06] indicates that this problem is frequently observed even in 107 the range of congestion window sizes over several hundreds of packets 108 (each packet is sized around 1000 bytes) especially under a network 109 path with over 100ms round-trip times (RTTs). This problem is 110 equally applicable to all Reno style TCP standards and their 111 variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- 112 SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same 113 linear increase function for window growth, which we refer to 114 collectively as Standard TCP below. 116 CUBIC [HRX08] is a modification to the congestion control mechanism 117 of Standard TCP, in particular, to the window increase function of 118 Standard TCP senders, to remedy this problem. It uses a cubic 119 increase function in terms of the elapsed time from the last 120 congestion event. While most alternative algorithms to Standard TCP 121 uses a convex increase function where after a loss event, the window 122 increment is always increasing, CUBIC uses both the concave and 123 convex profiles of a cubic function for window increase. After a 124 window reduction following a loss event, it registers the window size 125 where it got the loss event as W_max and performs a multiplicative 126 decrease of congestion window and the regular fast recovery and 127 retransmit of Standard TCP. After it enters into congestion 128 avoidance from fast recovery, it starts to increase the window using 129 the concave profile of the cubic function. The cubic function is set 130 to have its plateau at W_max so the concave growth continues until 131 the window size becomes W_max. After that, the cubic function turns 132 into a convex profile and the convex window growth begins. This 133 style of window adjustment (concave and then convex) improves 134 protocol and network stability while maintaining high network 135 utilization [CEHRX07]. This is because the window size remains 136 almost constant, forming a plateau around W_max where network 137 utilization is deemed highest and under steady state, most window 138 size samples of CUBIC are close to W_max, thus promoting high network 139 utilization and protocol stability. Note that protocols with convex 140 increase functions have the maximum increments around W_max and 141 introduces a large number of packet bursts around the saturation 142 point of the network, likely causing frequent global loss 143 synchronizations. 145 Another notable feature of CUBIC is that its window increase rate is 146 mostly independent of RTT, and follows a (cubic) function of the 147 elapsed time since the last loss event. This feature promotes per- 148 flow fairness to Standard TCP as well as RTT-fairness. Note that 149 Standard TCP performs well under short RTT and small bandwidth (or 150 small BDP) networks. Only in a large long RTT and large bandwidth 151 (or large BDP) networks, it has the scalability problem. An 152 alternative protocol to Standard TCP designed to be friendly to 153 Standard TCP at a per-flow basis must operate to increase its window 154 much less aggressively in small BDP networks than in large BDP 155 networks. In CUBIC, its window growth rate is slowest around the 156 inflection point of the cubic function and this function does not 157 depend on RTT. In a smaller BDP network where Standard TCP flows are 158 working well, the absolute amount of the window decrease at a loss 159 event is always smaller because of the multiplicative decrease. 160 Therefore, in CUBIC, the starting window size after a loss event from 161 which the window starts to increase, is smaller in a smaller BDP 162 network, thus falling nearer to the plateau of the cubic function 163 where the growth rate is slowest. By setting appropriate values of 164 the cubic function parameters, CUBIC sets its growth rate always no 165 faster than Standard TCP around its inflection point. When the cubic 166 function grows slower than the window of Standard TCP, CUBIC simply 167 follows the window size of Standard TCP to ensure fairness to 168 Standard TCP in a small BDP network. We call this region where CUBIC 169 behaves like Standard TCP, the TCP-friendly region. 171 CUBIC maintains the same window growth rate independent of RTTs 172 outside of the TCP-friendly region, and flows with different RTTs 173 have the similar window sizes under steady state when they operate 174 outside the TCP-friendly region. This ensures CUBIC flows with 175 different RTTs to have their bandwidth shares linearly proportional 176 to the inverse of their RTT ratio (the longer RTT, the smaller the 177 share). This behavior is the same as that of Standard TCP under high 178 statistical multiplexing environments where packet losses are 179 independent of individual flow rates. However, under low statistical 180 multiplexing environments, the bandwidth share ratio of Standard TCP 181 flows with different RTTs is squarely proportional to the inverse of 182 their RTT ratio [XHR04]. CUBIC always ensures the linear ratio 183 independent of the levels of statistical multiplexing. This is an 184 improvement over Standard TCP. While there is no consensus on a 185 particular bandwidth share ratios of different RTT flows, we believe 186 that under wired Internet, use of the linear share notion seems more 187 reasonable than equal share or a higher order shares. HTCP [LS08] 188 currently uses the equal share. 190 CUBIC sets the multiplicative window decrease factor to 0.7 while 191 Standard TCP uses 0.5. While this improves the scalability of the 192 protocol, a side effect of this decision is slower convergence 193 especially under low statistical multiplexing environments. This 194 design choice is following the observation that the author of HSTCP 195 [RFC3649] has made along with other researchers (e.g., [GV02]): the 196 current Internet becomes more asynchronous with less frequent loss 197 synchronizations with high statistical multiplexing. Under this 198 environment, even strict MIMD can converge. CUBIC flows with the 199 same RTT always converge to the same share of bandwidth independent 200 of statistical multiplexing, thus achieving intra-protocol fairness. 201 We also find that under the environments with sufficient statistical 202 multiplexing, the convergence speed of CUBIC flows is reasonable. 204 In the ensuing sections, we provide the exact specification of CUBIC 205 and discuss the safety features of CUBIC following the guidelines 206 specified in [RFC5033]. 208 2. Conventions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 3. CUBIC Congestion Control 216 The unit of all window sizes in this document is segments of the 217 maximum segment size (MSS), and the unit of all times is seconds. 219 3.1. Window growth function 221 CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by 222 increasing congestion window only at the reception of ACK. The 223 protocol does not make any change to the fast recovery and retransmit 224 of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During 225 congestion avoidance after fast recovery, CUBIC changes the window 226 update algorithm of Standard TCP. Suppose that W_max is the window 227 size before the window is reduced in the last fast retransmit and 228 recovery. 230 The window growth function of CUBIC uses the following function: 232 W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) 234 where C is a constant fixed to determine the aggressiveness of window 235 growth in high BDP networks, t is the elapsed time from the last 236 window reduction (measured right after the fast recovery), and K is 237 the time period that the above function takes to increase the current 238 window size to W_max if there is no further loss event and is 239 calculated by using the following equation: 241 K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) 243 where beta_cubic is the CUBIC multiplication decrease factor, that 244 is, when a packet loss occurs, CUBIC reduces its current window cwnd 245 to cwnd*beta_cubic. We discuss how we set C in the next Section in 246 more details. 248 Upon receiving an ACK during congestion avoidance, CUBIC computes the 249 window growth rate during the next RTT period using Eq. 1. It sets 250 W_cubic(t+RTT) as the candidate target value of congestion window. 252 Depending on the value of the current window size cwnd, CUBIC runs in 253 three different modes. First, if cwnd is less than the window size 254 that Standard TCP would reach at time t after the last loss event, 255 then CUBIC is in the TCP friendly region (we describe below how to 256 determine this window size of Standard TCP in term of time t). 257 Otherwise, if cwnd is less than W_max, then CUBIC is the concave 258 region, and if cwnd is larger than W_max, CUBIC is in the convex 259 region. Below, we describe the exact actions taken by CUBIC in each 260 region. 262 3.2. TCP-friendly region 264 When receiving an ACK in congestion avoidance, we first check whether 265 the protocol is in the TCP region or not. This is done by estimating 266 the average rate of the Standard TCP using a simple analysis 267 described in [FHP00]. It considers the Standard TCP as a special 268 case of an Additive Increase and Multiplicative Decrease algorithm 269 (AIMD), which has an additive factor alpha_aimd and a multiplicative 270 factor beta_aimd with the following function: 272 AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / 273 (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) 275 By the same analysis, the average window size of Standard TCP is 276 (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with 277 alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as 278 that of Standard TCP, alpha_aimd must be equal to 279 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by 280 alpha_aimd per RTT, we can get the window size of AIMD in terms of 281 the elapsed time t as follows: 283 W_aimd(t) = W_max*beta_aimd + 284 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) 286 If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP 287 friendly region and cwnd SHOULD be set to W_aimd(t) at each reception 288 of ACK. 290 3.3. Concave region 292 When receiving an ACK in congestion avoidance, if the protocol is not 293 in the TCP-friendly region and cwnd is less than W_max, then the 294 protocol is in the concave region. In this region, cwnd MUST be 295 incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK. 297 3.4. Convex region 299 When the current window size of CUBIC is larger than W_max, it passes 300 the plateau of the cubic function after which CUBIC follows the 301 convex profile of the cubic function. Since cwnd is larger than the 302 previous saturation point W_max, this indicates that the network 303 conditions might have been perturbed since the last loss event, 304 possibly implying more available bandwidth after some flow 305 departures. Since the Internet is highly asynchronous, some amount 306 of perturbation is always possible without causing a major change in 307 available bandwidth. In this phase, CUBIC is being very careful by 308 very slowly increasing its window size. The convex profile ensures 309 that the window increases very slowly at the beginning and gradually 310 increases its growth rate. We also call this phase as the maximum 311 probing phase since CUBIC is searching for a new W_max. In this 312 region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for 313 each received ACK. 315 3.5. Multiplicative decrease 317 When a packet loss occurs, CUBIC reduces its window size by a factor 318 of beta. Parameter beta_cubic SHOULD be set to 0.7. 320 W_max = cwnd; // save window size before reduction 321 cwnd = cwnd * beta_cubic; // window reduction 323 A side effect of setting beta_cubic to a bigger value than 0.5 is 324 slower convergence. We believe that while a more adaptive setting of 325 beta_cubic could result in faster convergence, it will make the 326 analysis of the protocol much harder. This adaptive adjustment of 327 beta_cubic is an item for the next version of CUBIC. 329 3.6. Fast convergence 331 To improve the convergence speed of CUBIC, we add a heuristic in the 332 protocol. When a new flow joins the network, existing flows in the 333 network need to give up their bandwidth shares to allow the flow some 334 room for growth if the existing flows have been using all the 335 bandwidth of the network. To increase this release of bandwidth by 336 existing flows, the following mechanism called fast convergence 337 SHOULD be implemented. 339 With fast convergence, when a loss event occurs, before a window 340 reduction of congestion window, a flow remembers the last value of 341 W_max before it updates W_max for the current loss event. Let us 342 call the last value of W_max to be W_last_max. 344 if (W_max < W_last_max){ // check downward trend 345 W_last_max = W_max; // remember the last W_max 346 W_max = W_max*(1+beta_cubic)/2; // further reduce W_max 347 } else { // check upward trend 348 W_last_max = W_max // remember the last W_max 349 } 351 This allows W_max to be slightly less than the original W_max. Since 352 flows spend most of time around their W_max, flows with larger 353 bandwidth shares tend to spend more time around the plateau allowing 354 more time for flows with smaller shares to increase their windows. 356 4. Discussion 358 With a deterministic loss model where the number of packets between 359 two successive lost events is always 1/p, CUBIC always operates with 360 the concave window profile which greatly simplifies the performance 361 analysis of CUBIC. The average window size of CUBIC can be obtained 362 by the following function: 364 AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * 365 (RTT^0.75) / (p^0.75) (Eq. 5) 367 With beta_cubic set to 0.7, the above formula is reduced to: 369 AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6) 371 We will determine the value of C in the following subsection using 372 Eq. 6. 374 4.1. Fairness to standard TCP 376 In environments where standard TCP is able to make reasonable use of 377 the available bandwidth, CUBIC does not significantly change this 378 state. 380 Standard TCP performs well in the following two types of networks: 382 1. networks with a small bandwidth-delay product (BDP) 384 2. networks with a short RTT, but not necessarily a small BDP 386 CUBIC is designed to behave very similarly to standard TCP in the 387 above two types of networks. The following two tables show the 388 average window size of standard TCP, HSTCP, and CUBIC. The average 389 window size of standard TCP and HSTCP is from [RFC3649]. The average 390 window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP 391 friendly mode for three different values of C. 393 +----------+-------+--------+-------------+-------------+-----------+ 394 | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | 395 | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | 396 +----------+-------+--------+-------------+-------------+-----------+ 397 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 398 | 10^-3 | 38 | 38 | 38 | 38 | 59 | 399 | 10^-4 | 120 | 263 | 120 | 187 | 333 | 400 | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | 401 | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | 402 | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | 403 | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | 404 +----------+-------+--------+-------------+-------------+-----------+ 406 Response function of standard TCP, HSTCP, and CUBIC in networks with 407 RTT = 0.1 seconds. The average window size is in MSS-sized segments. 409 Table 1 411 +--------+-----------+-----------+------------+-----------+---------+ 412 | Loss | Average | Average | CUBIC | CUBIC | CUBIC | 413 | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | 414 +--------+-----------+-----------+------------+-----------+---------+ 415 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 416 | 10^-3 | 38 | 38 | 38 | 38 | 38 | 417 | 10^-4 | 120 | 263 | 120 | 120 | 120 | 418 | 10^-5 | 379 | 1795 | 379 | 379 | 379 | 419 | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | 420 | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | 421 | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | 422 +--------+-----------+-----------+------------+-----------+---------+ 424 Response function of standard TCP, HSTCP, and CUBIC in networks with 425 RTT = 0.01 seconds. The average window size is in MSS-sized 426 segments. 428 Table 2 430 Both tables show that CUBIC with any of these three C values is more 431 friendly to TCP than HSTCP, especially in networks with a short RTT 432 where TCP performs reasonably well. For example, in a network with 433 RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 434 packets. If the packet size is 1500 bytes, then TCP can achieve an 435 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 436 achieves exactly the same rate as Standard TCP, whereas HSTCP is 437 about ten times more aggressive than Standard TCP. 439 We can see that C determines the aggressiveness of CUBIC in competing 440 with other protocols for the bandwidth. CUBIC is more friendly to 441 the Standard TCP, if the value of C is lower. However, we do not 442 recommend to set C to a very low value like 0.04, since CUBIC with a 443 low C cannot efficiently use the bandwidth in long RTT and high 444 bandwidth networks. Based on these observations, we find C=0.4 gives 445 a good balance between TCP-friendliness and aggressiveness of window 446 growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 447 is reduced to: 449 AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) 451 Eq. 7 is then used in the next subsection to show the scalability of 452 CUBIC. 454 4.2. Using Spare Capacity 456 CUBIC uses a more aggressive window growth function than Standard TCP 457 under long RTT and high bandwidth networks. 459 The following table shows that to achieve 10Gbps rate, standard TCP 460 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 461 loss rate of 2.9e-8. 463 +------------------+-----------+---------+---------+---------+ 464 | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 465 +------------------+-----------+---------+---------+---------+ 466 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 467 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 468 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 469 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 470 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 471 +------------------+-----------+---------+---------+---------+ 473 Required packet loss rate for Standard TCP, HSTCP, and CUBIC to 474 achieve a certain throughput. We use 1500-byte packets and an RTT of 475 0.1 seconds. 477 Table 3 479 Our test results in [HKLRX06] indicate that CUBIC uses the spare 480 bandwidth left unused by existing Standard TCP flows in the same 481 bottleneck link without taking away much bandwidth from the existing 482 flows. 484 4.3. Difficult Environments 486 CUBIC is designed to remedy the poor performance of TCP in fast long- 487 distance networks. It is not designed for wireless networks. 489 4.4. Investigating a Range of Environments 491 CUBIC has been extensively studied by using both NS-2 simulation and 492 test-bed experiments covering a wide range of network environments. 493 More information can be found in [HKLRX06]. 495 4.5. Protection against Congestion Collapse 497 In case that there is congestion collapse, CUBIC behaves likely 498 standard TCP since CUBIC modifies only the window adjustment 499 algorithm of TCP. Thus, it does not modify the ACK clocking and 500 Timeout behaviors of Standard TCP. 502 4.6. Fairness within the Alternative Congestion Control Algorithm. 504 CUBIC ensures convergence of competing CUBIC flows with the same RTT 505 in the same bottleneck links to an equal bandwidth share. When 506 competing flows have different RTTs, their bandwidth shares are 507 linearly proportional to the inverse of their RTT ratios. This is 508 true independent of the level of statistical multiplexing in the 509 link. 511 4.7. Performance with Misbehaving Nodes and Outside Attackers 513 This is not considered in the current CUBIC. 515 4.8. Behavior for Application-Limited Flows 517 CUBIC does not raise its congestion window size if the flow is 518 currently limited by the application instead of the congestion 519 window. In cases of idle periods, t in Eq. 1 should not include the 520 idle time; otherwise, W_cubic(t) might be very high after restarting 521 from a long idle time. 523 4.9. Responses to Sudden or Transient Events 525 In case that there is a sudden congestion, a routing change, or a 526 mobility event, CUBIC behaves the same as Standard TCP. 528 4.10. Incremental Deployment 530 CUBIC requires only the change of TCP senders, and does not require 531 any assistant of routers. 533 5. Security Considerations 535 This proposal makes no changes to the underlying security of TCP. 537 6. IANA Considerations 539 There are no IANA considerations regarding this document. 541 7. Acknowledgements 543 Alexander Zimmermann and Lars Eggert have received funding from the 544 European Union's Horizon 2020 research and innovation program 545 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 546 reflects only the authors' views and the European Commission is not 547 responsible for any use that may be made of the information it 548 contains. 550 8. References 552 8.1. Normative References 554 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 555 Selective Acknowledgment Options", RFC 2018, 556 DOI 10.17487/RFC2018, October 1996, 557 . 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 565 RFC 3649, DOI 10.17487/RFC3649, December 2003, 566 . 568 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 569 RFC 4960, DOI 10.17487/RFC4960, September 2007, 570 . 572 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 573 Control Algorithms", BCP 133, RFC 5033, 574 DOI 10.17487/RFC5033, August 2007, 575 . 577 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 578 Friendly Rate Control (TFRC): Protocol Specification", 579 RFC 5348, DOI 10.17487/RFC5348, September 2008, 580 . 582 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 583 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 584 . 586 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 587 NewReno Modification to TCP's Fast Recovery Algorithm", 588 RFC 6582, DOI 10.17487/RFC6582, April 2012, 589 . 591 8.2. Informative References 593 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 594 Ordering for Internet Congestion Control and its 595 Applications", In Proceedings of IEEE INFOCOM , May 2007. 597 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 598 Equation-Based and AIMD Congestion Control", May 2000. 600 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 601 Adjustment Algorithms", Technical Report TR2002-29, 602 Department of Computer Sciences , The University of Texas 603 at Austin , August 2002. 605 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 606 toward Realistic Performance Evaluation of High-Speed TCP 607 Variants", International Workshop on Protocols for Fast 608 Long-Distance Networks , February 2006. 610 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly 611 High-Speed TCP Variant", ACM SIGOPS Operating System 612 Review , 2008. 614 [K03] Kelly, T., "Scalable TCP: Improving Performance in 615 HighSpeed Wide Area Networks", ACM SIGCOMM Computer 616 Communication Review , April 2003. 618 [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control 619 for High Bandwidth-Delay Product Paths", Internet-draft 620 draft-leith-tcp-htcp-06 , April 2008. 622 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 623 Congestion Control for Fast, Long Distance Networks", In 624 Proceedings of IEEE INFOCOM , March 2004. 626 Authors' Addresses 628 Injong Rhee 629 North Carolina State University 630 Department of Computer Science 631 Raleigh, NC 27695-7534 632 US 634 Email: rhee@ncsu.edu 636 Lisong Xu 637 University of Nebraska-Lincoln 638 Department of Computer Science and Engineering 639 Lincoln, NE 68588-01150 640 US 642 Email: xu@unl.edu 644 Sangtae Ha 645 University of Colorado at Boulder 646 Department of Computer Science 647 Boulder, CO 80309-0430 648 US 650 Email: sangtae.ha@colorado.edu 652 Alexander Zimmermann 653 NetApp 654 Sonnenallee 1 655 Kirchheim 85551 656 Germany 658 Phone: +49 89 900594712 659 Email: alexander.zimmermann@netapp.com 661 Lars Eggert 662 NetApp 663 Sonnenallee 1 664 Kirchheim 85551 665 Germany 667 Phone: +49 151 12055791 668 Email: lars@netapp.com 669 Richard Scheffenegger 670 NetApp 671 Am Euro Platz 2 672 Vienna 1120 673 Austria 675 Phone: +43 1 3676811 3146 676 Email: rs@netapp.com