draft-leith-tcp-htcp-06 D. Leith Internet-Draft Hamilton Institute Intended status: Experimental April 7, 2008 Expires: October 9, 2008 H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 9, 2008. Leith Expires October 9, 2008 [Page 1]
Internet-Draft H-TCP April 2008 Abstract This document describes a number of changes to the TCP congestion control algorithm to to improve performance in high bandwidth-delay product paths. We focus on changes to the congestion avoidance mode, rather than slow-start. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Additive Increase for High Bandwidth-Delay Product Paths . . . 6 4. Impact of Changes on Performance . . . . . . . . . . . . . . . 8 4.1. RTT unfairness . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Friendliness . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Optional RTT Scaling . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Leith Expires October 9, 2008 [Page 2]
Internet-Draft H-TCP April 2008 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Leith Expires October 9, 2008 [Page 3]
Internet-Draft H-TCP April 2008 2. Introduction This document describes a number of changes to the TCP congestion control algorithm to to improve performance in high bandwidth-delay product paths. The current TCP congestion control algorithm is known to perform poorly on paths where the TCP congestion window becomes large. [Kelly02, Flo03, FAST04]. Following congestion, the congestion window is halved and only increases at a rate of 1 packet per RTT. As a result flows can take an unacceptably long time to recover their window size after a congestion event. A direct solution is to make the time between congestion events smaller. This can be achieved by, for example, adjusting the AIMD additive increase rate to be greater for flows with larger congestion window. Backward compatibility with legacy TCP can be ensured through the inclusion of a separate mode of operation that behaves as legacy TCP in the appropriate circumstances. The logic that orchestrates switching between the legacy and more aggressive modes of operation can clearly be designed several ways. One approach is to make the AIMD increase parameter, which we denote here by alpha, a function of the flow congestion window. That is, alpha is increased as congestion window increases thereby resulting in an additive increase algorithm that directly scales with congestion window. This is precisely the approach adopted in the High-Speed TCP [Flo03] proposal. In addition to adjusting the AIMD increase parameter alpha as a function of congestion window, this proposal also increases the multiplicative decrease factor beta to further increase the aggressiveness of a flow. (Note. On multiplicative decrease, the congestion window cwnd is updated to beta x cwnd. We use this definition of the backoff factor beta throughout this document). While such modifications might appear straightforward, it has been shown [Sho04, Yi05] that they often negatively impact the behaviour of networks of TCP flows. High-speed TCP[Flo03], BIC-TCP [BIC04] and Cubic can exhibit slow convergence following network disturbances such as the start-up of new flows; Scalable-TCP [Kelly02] is a multiplicative-increase multiplicative-decrease strategy and as such it is known that it may fail to converge to fairness in drop-tail networks [Jain89]. Scope ----- Our focus in this document is on the behaviour of long-lived flows Leith Expires October 9, 2008 [Page 4]
Internet-Draft H-TCP April 2008 and so we do not consider changes to slow-start. We also seek to make the smallest possible changes to the existing TCP congestion control algorithm, and so confine consideration to the AIMD packet- loss based paradigm. Use of jumbo packets is viewed as complementary to the changes proposed here. Leith Expires October 9, 2008 [Page 5]
Internet-Draft H-TCP April 2008 3. Additive Increase for High Bandwidth-Delay Product Paths It is known that modifying the AIMD backoff factor can have a significant impact on network responsiveness, and this is discussed in more detail elsewhere [Sho04, Sho05]. In this document we confine attention to modifications to the AIMD increase rate with the aim of improving performance in high bandwidth-delay product paths. We begin with the observation that making the AIMD increase rate an increasing function of flow cwnd (as is done in the HS-TCP, BIC, Cubic etc algorithms) means that flows with smaller cwnd are placed at a disadvantage to flows with larger cwnd when competing for bandwidth. This is a primary source of unfairness and slow convergence. We therefore take an alternative approach. Noting that it is the increase in congestion epoch duration with bandwidth-delay product that is the source of many issues, we make the AIMD increase rate purely a function of the elapsed time since the last congestion event. This allows us to increase the aggressiveness of the AIMD increase as the congestion epoch duration increases (so improving performance in high bandwidth-delay product paths) while avoiding placing flows with small cwnd at a consistent disadvantage. RFC2591 specifies that during congestion avoidance, cwnd is incremented by 1 full-sized segment per round-trip time (RTT). We modify this behaviour to increase cwnd by alpha segments per RTT, where alpha is calculated as follows. if Delta <= Delta_L alpha = 1 else alpha = f_alpha(Delta) where Delta is the time in seconds that has elapsed since the last congestion event experienced by a flow and Delta_L is the threshold for switching from standard/legacy operation to the new increase function. Delta_L MUST be at least 1 second, although larger values MAY be used. The increase function f_alpha is selected such that the duration of the congestion epochs remains reasonably small as the bandwidth-delay product on a path increases. Below, we discuss a choice of increase function that yields convergence times that seem reasonable. However, the precise responsiveness requirement in future networks is currently not well defined and so the specific choice of increase function may change. Use of the following increase function is RECOMMENDED: f_alpha(Delta) = 1 + 10(Delta-Delta_L)+0.5(Delta-Delta_L)^2 (1) This choice yields the congestion epoch duration for a single flow, Leith Expires October 9, 2008 [Page 6]
Internet-Draft H-TCP April 2008 as a function of congestion window size, shown in Table 1. ------------------------------------- Congestion Congestion window epoch (packets) duration (s) ------------------------------------- 100 1.1 1000 3.1 2000 4.3 5000 6.6 10000 9.2 20000 12.8 50000 19.4 ------------------------------------- Table 1 - Congestion epoch duration vs congestion window size for an RTT of 100ms Leith Expires October 9, 2008 [Page 7]
Internet-Draft H-TCP April 2008 4. Impact of Changes on Performance 4.1. RTT unfairness The level of unfairness between flows with different RTT's is similar to that with the standard TCP algorithm. This behaviour is confirmed in experimental and simulation tests [HTCP04, Yi05]. 4.2. Friendliness The mean AIMD increase parameter is shown in Table 2 for a range of bandwidth-delay products. This an indication of the number of standard TCP flows (neglecting statistical multiplexing of backoffs) whose aggregate would be equivalent to a flow using increase function (1). That is, an indication of friendliness and also of the packet drop overhead associated with the AIMD probing action. ------------------------------------------------------------------ Congestion Effective number of standard TCP flows window (packets) 10ms RTT 100ms RTT 250ms RTT ------------------------------------------------------------------ 10 1 1 1 100 1 2 5 1000 3 12 22 2000 4 19 32 5000 8 33 55 10000 12 49 82 20000 19 72 123 50000 32 122 208 ------------------------------------------------------------------ Table 2 - Mean increase parameter (packets/RTT) vs congestion window size 4.3. Responsiveness Responsiveness is qualitatively similar to that of the current AIMD congestion control algorithm, i.e. the convergence time of TCP flows using an AIMD backoff factor of 0.5 is approximately 4 congestion epochs, although the congestion epoch duration is significantly shorter on high bandwidth-delay product paths (see Table 1). 4.4. Efficiency Link utilisation depends on queue provisioning in a similar manner to the current TCP congestion control algorithm. That is, for a single flow (or multiple synchronised flows) 100% link utilisation requires that the queue be sized as the bandwidth-delay product. Simulation Leith Expires October 9, 2008 [Page 8]
Internet-Draft H-TCP April 2008 and experimental tests indicate that statistical multiplexing between unsynchronised flows yields similar efficiency gains to standard TCP. Leith Expires October 9, 2008 [Page 9]
Internet-Draft H-TCP April 2008 5. Optional RTT Scaling We note that the parameter alpha determines the AIMD increase rate in packets per RTT. Hence, flows with the same RTT have the same increase rate in packets per second, but flows with different RTTs have different increase rate in packets per second. It is this that primarily leads to unfairness between flows with different RTTs. Removing RTT unfairness is not one of our objectives here. However, we note that an AIMD flow generates roughly alpha packet drops per RTT as a result of its probing action. Hence, flows with short RTT are more aggressive than flows with long RTT in the sense that they generate more packet drops over intervals of time measured in seconds. We can reduce the aggressiveness of short RTT flows by scaling the increase parameter alpha with RTT. This need not compromise the responsiveness of TCP flows. As noted in [Sh04, Sh05, HTCP04], the convergence time of TCP flows using an AIMD backoff factor of 0.5 is approximately 4 congestion epochs. Scaling alpha by RTT leads to scaling of the congestion epoch duration to become effectively the same for both short and long RTT flows. The convergence time is therefore also scaled to be effectively the same for both short and long RTT flows. Such RTT scaling MAY be implemented by modifying the increase rule to if Delta <= Delta_L alpha = 1 else alpha = K x f_alpha(Delta) where K = RTT/RTT_ref. Note that RTT scaling is not applied in low- speed conditions in order to maintain backward compatibility with legacy TCP flows (ensuring adequate backward compatibility presented a major difficulty in previous studies on the use of RTT scaling). Note also that the scaling is proportional to RTT rather than RTT^2, as we do not seek to achieve throughput fairness here. RTT_ref is the reference RTT for which f_alpha is designed to ensure acceptable congestion epoch durations, with the recommended value being 100ms. Leith Expires October 9, 2008 [Page 10]
Internet-Draft H-TCP April 2008 6. Security Considerations Security implications are not discussed in this document. Leith Expires October 9, 2008 [Page 11]
Internet-Draft H-TCP April 2008 7. Acknowledgements This work was supported by Science Foundation Ireland grants 00/PI.1/ C067 and 04/IN3/I460. Leith Expires October 9, 2008 [Page 12]
Internet-Draft H-TCP April 2008 8. Changelog April 2008: Updated to use RFC2119 terminology. Discussion streamlined. Leith Expires October 9, 2008 [Page 13]
Internet-Draft H-TCP April 2008 9. Informative References [Jain89] D.M. Chiu, R. Jain, Analysis of the increase and decrease algorithms for congestion avoidance in computer networks. Computer Networks and ISDN Systems, 1989. [Flo03] S.Floyd, HighSpeed TCP for Large Congestion Windows . Sally Floyd. IETF RFC 3649, Experimental, Dec 2003. [FAST04] C. Jin, D.X. Wei, S,H. Low, FAST TCP: motivation, architecture, algorithms, performance. Proc IEEE INFOCOM 2004. [Kelly02] T. Kelly, On engineering a stable and scalable TCP variant, Cambridge University Engineering Department Technical Report CUED/ F-INFENG/TR.435, June 2002. [HTCP04] D.J.Leith, R.N.Shorten, H-TCP Protocol for High-Speed Long- Distance Networks. Proc. 2nd Workshop on Protocols for Fast Long Distance Networks. Argonne, USA, 2004. http://www.hamilton.ie/net/htcp3.pdf [BIC04] L. Xu, K. Harfoush, I. Rhee, Binary Increase Congestion Control for Fast Long-Distance Networks. Proc. INFOCOM 2004. [Sho04] R.N.Shorten, D.J.Leith,J.Foy, R.Kilduff, Analysis and design of congestion control in synchronised communication networks. Automatica, 2004. http://www.hamilton.ie/net/synchronised.pdf [Sho05] R.N.Shorten, F. Wirth,F., D.J. Leith, A positive systems model of TCP-like congestion control: Asymptotic results. http://www.hamilton.ie/net/unsynchronised_final.pdf [Yi05] Y.Li, D.J.Leith, R.N.Shorten, Experimental evaluation of TCP protocols of high-speed networks. http://www.hamilton.ie/net/eval/ [Cot05] R.L. Cottrell, S. Ansari, P. Khandpur, R. Gupta, R. Hughes- Jones, M. Chen, L. MacIntosh, F. Leers, Characterization and Evaluation of TCP and UDP-Based Transport On Real Networks. . Proc. 3rd Workshop on Protocols for Fast Long-distance Networks, Lyon, France, 2005. [Hegde04] S. Hegde, D. Lapsley, B. Wydrowski, J. Lindheim, D.Wei, C. Jin, S. Low, H. Newman, FAST TCP in High Speed Networks: An Experimental Study. Proc. GridNets, San Jose, 2004. Leith Expires October 9, 2008 [Page 14]
Internet-Draft H-TCP April 2008 Author's Address Doug Leith Hamilton Institute NUI Maynooth Maynooth, Co. Kildare Ireland Email: doug.leith@nuim.ie Leith Expires October 9, 2008 [Page 15]
Internet-Draft H-TCP April 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Leith Expires October 9, 2008 [Page 16]
