idnits 2.17.1 draft-leith-tcp-htcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 7, 2008) is 5862 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'Cot05' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'Hegde04' is defined on line 329, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-leith-tcp-htcp-06 D. Leith 3 Internet-Draft Hamilton Institute 4 Intended status: Experimental April 7, 2008 5 Expires: October 9, 2008 7 H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 9, 2008. 34 Abstract 36 This document describes a number of changes to the TCP congestion 37 control algorithm to to improve performance in high bandwidth-delay 38 product paths. We focus on changes to the congestion avoidance mode, 39 rather than slow-start. 41 Table of Contents 43 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 45 3. Additive Increase for High Bandwidth-Delay Product Paths . . . 6 46 4. Impact of Changes on Performance . . . . . . . . . . . . . . . 8 47 4.1. RTT unfairness . . . . . . . . . . . . . . . . . . . . . . 8 48 4.2. Friendliness . . . . . . . . . . . . . . . . . . . . . . . 8 49 4.3. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 8 50 4.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 8 51 5. Optional RTT Scaling . . . . . . . . . . . . . . . . . . . . . 10 52 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 53 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 54 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 55 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 57 Intellectual Property and Copyright Statements . . . . . . . . . . 16 59 1. Conventions 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119. 65 2. Introduction 67 This document describes a number of changes to the TCP congestion 68 control algorithm to to improve performance in high bandwidth-delay 69 product paths. 71 The current TCP congestion control algorithm is known to perform 72 poorly on paths where the TCP congestion window becomes large. 73 [Kelly02, Flo03, FAST04]. Following congestion, the congestion 74 window is halved and only increases at a rate of 1 packet per RTT. 75 As a result flows can take an unacceptably long time to recover their 76 window size after a congestion event. 78 A direct solution is to make the time between congestion events 79 smaller. This can be achieved by, for example, adjusting the AIMD 80 additive increase rate to be greater for flows with larger congestion 81 window. Backward compatibility with legacy TCP can be ensured 82 through the inclusion of a separate mode of operation that behaves as 83 legacy TCP in the appropriate circumstances. 85 The logic that orchestrates switching between the legacy and more 86 aggressive modes of operation can clearly be designed several ways. 87 One approach is to make the AIMD increase parameter, which we denote 88 here by alpha, a function of the flow congestion window. That is, 89 alpha is increased as congestion window increases thereby resulting 90 in an additive increase algorithm that directly scales with 91 congestion window. This is precisely the approach adopted in the 92 High-Speed TCP [Flo03] proposal. In addition to adjusting the AIMD 93 increase parameter alpha as a function of congestion window, this 94 proposal also increases the multiplicative decrease factor beta to 95 further increase the aggressiveness of a flow. (Note. On 96 multiplicative decrease, the congestion window cwnd is updated to 97 beta x cwnd. We use this definition of the backoff factor beta 98 throughout this document). 100 While such modifications might appear straightforward, it has been 101 shown [Sho04, Yi05] that they often negatively impact the behaviour 102 of networks of TCP flows. High-speed TCP[Flo03], BIC-TCP [BIC04] and 103 Cubic can exhibit slow convergence following network disturbances 104 such as the start-up of new flows; Scalable-TCP [Kelly02] is a 105 multiplicative-increase multiplicative-decrease strategy and as such 106 it is known that it may fail to converge to fairness in drop-tail 107 networks [Jain89]. 109 Scope 110 ----- 112 Our focus in this document is on the behaviour of long-lived flows 113 and so we do not consider changes to slow-start. We also seek to 114 make the smallest possible changes to the existing TCP congestion 115 control algorithm, and so confine consideration to the AIMD packet- 116 loss based paradigm. Use of jumbo packets is viewed as complementary 117 to the changes proposed here. 119 3. Additive Increase for High Bandwidth-Delay Product Paths 121 It is known that modifying the AIMD backoff factor can have a 122 significant impact on network responsiveness, and this is discussed 123 in more detail elsewhere [Sho04, Sho05]. In this document we confine 124 attention to modifications to the AIMD increase rate with the aim of 125 improving performance in high bandwidth-delay product paths. We 126 begin with the observation that making the AIMD increase rate an 127 increasing function of flow cwnd (as is done in the HS-TCP, BIC, 128 Cubic etc algorithms) means that flows with smaller cwnd are placed 129 at a disadvantage to flows with larger cwnd when competing for 130 bandwidth. This is a primary source of unfairness and slow 131 convergence. We therefore take an alternative approach. Noting that 132 it is the increase in congestion epoch duration with bandwidth-delay 133 product that is the source of many issues, we make the AIMD increase 134 rate purely a function of the elapsed time since the last congestion 135 event. This allows us to increase the aggressiveness of the AIMD 136 increase as the congestion epoch duration increases (so improving 137 performance in high bandwidth-delay product paths) while avoiding 138 placing flows with small cwnd at a consistent disadvantage. 140 RFC2591 specifies that during congestion avoidance, cwnd is 141 incremented by 1 full-sized segment per round-trip time (RTT). We 142 modify this behaviour to increase cwnd by alpha segments per RTT, 143 where alpha is calculated as follows. 145 if Delta <= Delta_L 146 alpha = 1 147 else 148 alpha = f_alpha(Delta) 150 where Delta is the time in seconds that has elapsed since the last 151 congestion event experienced by a flow and Delta_L is the threshold 152 for switching from standard/legacy operation to the new increase 153 function. Delta_L MUST be at least 1 second, although larger values 154 MAY be used. The increase function f_alpha is selected such that the 155 duration of the congestion epochs remains reasonably small as the 156 bandwidth-delay product on a path increases. Below, we discuss a 157 choice of increase function that yields convergence times that seem 158 reasonable. However, the precise responsiveness requirement in 159 future networks is currently not well defined and so the specific 160 choice of increase function may change. 162 Use of the following increase function is RECOMMENDED: 164 f_alpha(Delta) = 1 + 10(Delta-Delta_L)+0.5(Delta-Delta_L)^2 (1) 166 This choice yields the congestion epoch duration for a single flow, 167 as a function of congestion window size, shown in Table 1. 169 ------------------------------------- 170 Congestion Congestion 171 window epoch 172 (packets) duration (s) 173 ------------------------------------- 174 100 1.1 175 1000 3.1 176 2000 4.3 177 5000 6.6 178 10000 9.2 179 20000 12.8 180 50000 19.4 181 ------------------------------------- 182 Table 1 - Congestion epoch duration vs congestion window 183 size for an RTT of 100ms 185 4. Impact of Changes on Performance 187 4.1. RTT unfairness 189 The level of unfairness between flows with different RTT's is similar 190 to that with the standard TCP algorithm. This behaviour is confirmed 191 in experimental and simulation tests [HTCP04, Yi05]. 193 4.2. Friendliness 195 The mean AIMD increase parameter is shown in Table 2 for a range of 196 bandwidth-delay products. This an indication of the number of 197 standard TCP flows (neglecting statistical multiplexing of backoffs) 198 whose aggregate would be equivalent to a flow using increase function 199 (1). That is, an indication of friendliness and also of the packet 200 drop overhead associated with the AIMD probing action. 202 ------------------------------------------------------------------ 203 Congestion Effective number of standard TCP flows 204 window 205 (packets) 10ms RTT 100ms RTT 250ms RTT 206 ------------------------------------------------------------------ 207 10 1 1 1 208 100 1 2 5 209 1000 3 12 22 210 2000 4 19 32 211 5000 8 33 55 212 10000 12 49 82 213 20000 19 72 123 214 50000 32 122 208 215 ------------------------------------------------------------------ 216 Table 2 - Mean increase parameter (packets/RTT) vs congestion window 217 size 219 4.3. Responsiveness 221 Responsiveness is qualitatively similar to that of the current AIMD 222 congestion control algorithm, i.e. the convergence time of TCP flows 223 using an AIMD backoff factor of 0.5 is approximately 4 congestion 224 epochs, although the congestion epoch duration is significantly 225 shorter on high bandwidth-delay product paths (see Table 1). 227 4.4. Efficiency 229 Link utilisation depends on queue provisioning in a similar manner to 230 the current TCP congestion control algorithm. That is, for a single 231 flow (or multiple synchronised flows) 100% link utilisation requires 232 that the queue be sized as the bandwidth-delay product. Simulation 233 and experimental tests indicate that statistical multiplexing between 234 unsynchronised flows yields similar efficiency gains to standard TCP. 236 5. Optional RTT Scaling 238 We note that the parameter alpha determines the AIMD increase rate in 239 packets per RTT. Hence, flows with the same RTT have the same 240 increase rate in packets per second, but flows with different RTTs 241 have different increase rate in packets per second. It is this that 242 primarily leads to unfairness between flows with different RTTs. 243 Removing RTT unfairness is not one of our objectives here. However, 244 we note that an AIMD flow generates roughly alpha packet drops per 245 RTT as a result of its probing action. Hence, flows with short RTT 246 are more aggressive than flows with long RTT in the sense that they 247 generate more packet drops over intervals of time measured in 248 seconds. We can reduce the aggressiveness of short RTT flows by 249 scaling the increase parameter alpha with RTT. This need not 250 compromise the responsiveness of TCP flows. As noted in [Sh04, Sh05, 251 HTCP04], the convergence time of TCP flows using an AIMD backoff 252 factor of 0.5 is approximately 4 congestion epochs. Scaling alpha by 253 RTT leads to scaling of the congestion epoch duration to become 254 effectively the same for both short and long RTT flows. The 255 convergence time is therefore also scaled to be effectively the same 256 for both short and long RTT flows. 258 Such RTT scaling MAY be implemented by modifying the increase rule to 260 if Delta <= Delta_L 261 alpha = 1 262 else 263 alpha = K x f_alpha(Delta) 265 where K = RTT/RTT_ref. Note that RTT scaling is not applied in low- 266 speed conditions in order to maintain backward compatibility with 267 legacy TCP flows (ensuring adequate backward compatibility presented 268 a major difficulty in previous studies on the use of RTT scaling). 269 Note also that the scaling is proportional to RTT rather than RTT^2, 270 as we do not seek to achieve throughput fairness here. RTT_ref is 271 the reference RTT for which f_alpha is designed to ensure acceptable 272 congestion epoch durations, with the recommended value being 100ms. 274 6. Security Considerations 276 Security implications are not discussed in this document. 278 7. Acknowledgements 280 This work was supported by Science Foundation Ireland grants 00/PI.1/ 281 C067 and 04/IN3/I460. 283 8. Changelog 285 April 2008: Updated to use RFC2119 terminology. Discussion 286 streamlined. 288 9. Informative References 290 [Jain89] D.M. Chiu, R. Jain, Analysis of the increase and decrease 291 algorithms for congestion avoidance in computer networks. Computer 292 Networks and ISDN Systems, 1989. 294 [Flo03] S.Floyd, HighSpeed TCP for Large Congestion Windows . Sally 295 Floyd. IETF RFC 3649, Experimental, Dec 2003. 297 [FAST04] C. Jin, D.X. Wei, S,H. Low, FAST TCP: motivation, 298 architecture, algorithms, performance. Proc IEEE INFOCOM 2004. 300 [Kelly02] T. Kelly, On engineering a stable and scalable TCP variant, 301 Cambridge University Engineering Department Technical Report CUED/ 302 F-INFENG/TR.435, June 2002. 304 [HTCP04] D.J.Leith, R.N.Shorten, H-TCP Protocol for High-Speed Long- 305 Distance Networks. Proc. 2nd Workshop on Protocols for Fast Long 306 Distance Networks. Argonne, USA, 2004. 307 http://www.hamilton.ie/net/htcp3.pdf 309 [BIC04] L. Xu, K. Harfoush, I. Rhee, Binary Increase Congestion 310 Control for Fast Long-Distance Networks. Proc. INFOCOM 2004. 312 [Sho04] R.N.Shorten, D.J.Leith,J.Foy, R.Kilduff, Analysis and design 313 of congestion control in synchronised communication networks. 314 Automatica, 2004. http://www.hamilton.ie/net/synchronised.pdf 316 [Sho05] R.N.Shorten, F. Wirth,F., D.J. Leith, A positive systems 317 model of TCP-like congestion control: Asymptotic results. 318 http://www.hamilton.ie/net/unsynchronised_final.pdf 320 [Yi05] Y.Li, D.J.Leith, R.N.Shorten, Experimental evaluation of TCP 321 protocols of high-speed networks. http://www.hamilton.ie/net/eval/ 323 [Cot05] R.L. Cottrell, S. Ansari, P. Khandpur, R. Gupta, R. Hughes- 324 Jones, M. Chen, L. MacIntosh, F. Leers, Characterization and 325 Evaluation of TCP and UDP-Based Transport On Real Networks. . Proc. 326 3rd Workshop on Protocols for Fast Long-distance Networks, Lyon, 327 France, 2005. 329 [Hegde04] S. Hegde, D. Lapsley, B. Wydrowski, J. Lindheim, D.Wei, C. 330 Jin, S. Low, H. Newman, FAST TCP in High Speed Networks: An 331 Experimental Study. Proc. GridNets, San Jose, 2004. 333 Author's Address 335 Doug Leith 336 Hamilton Institute 337 NUI Maynooth 338 Maynooth, Co. Kildare 339 Ireland 341 Email: doug.leith@nuim.ie 343 Full Copyright Statement 345 Copyright (C) The IETF Trust (2008). 347 This document is subject to the rights, licenses and restrictions 348 contained in BCP 78, and except as set forth therein, the authors 349 retain all their rights. 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 Intellectual Property 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org.