idnits 2.17.1 draft-floyd-tcp-slowstart-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-allman-tcp-abc-02 ** Downref: Normative reference to an Experimental draft: draft-allman-tcp-abc (ref. 'A01') ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sally Floyd 3 INTERNET DRAFT ICSI 4 draft-floyd-tcp-slowstart-01.txt August, 2002 6 Limited Slow-Start for TCP with Large Congestion Windows 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This note proposes a modification for TCP's slow-start for use with 32 TCP connections with large congestion windows. For TCP connections 33 that are able to use congestion windows of thousands (or tens of 34 thousands) of MSS-sized segments (for MSS the sender's MAXIMUM 35 SEGMENT SIZE), the current slow-start procedure can result in 36 increasing the congestion window by thousands of segments in a single 37 round-trip time. Such an increase can easily result in thousands of 38 packets being dropped in one round-trip time. This is often counter- 39 productive for the TCP flow itself, and is also hard on the rest of 40 the traffic sharing the congested link. This note proposes Limited 41 Slow-Start as an optional mechanism for limiting the number of 42 segments by which the congestion window is increased for one window 43 of data during slow-start, in order to improve performance for TCP 44 connections with large congestion windows. 46 Changes from draft-floyd-tcp-slowstart-00.txt: 48 * Small changes in presentation. 50 * The addition of a section of Experiments. 52 * More citations to related work. 54 1. Introduction 56 This note proposes a modification for TCP's slow-start for use with 57 TCP connections with large congestion windows. For TCP connections 58 that are able to use congestion windows of thousands (or tens of 59 thousands) of MSS-sized segments (for MSS the sender's MAXIMUM 60 SEGMENT SIZE), the current slow-start procedure can result in 61 increasing the congestion window by thousands of segments in a single 62 round-trip time. Such an increase can easily result in thousands of 63 packets being dropped in one round-trip time. This is often counter- 64 productive for the TCP flow itself, and is also hard on the rest of 65 the traffic sharing the congested link. This note proposes Limited 66 Slow-Start, limiting the number of segments by which the congestion 67 window is increased for one window of data during slow-start, in 68 order to improve performance for TCP connections with large 69 congestion windows. 71 When slow-start results in a large increase in the congestion window 72 in one round-trip time, a large number of packets might be dropped in 73 the network (even with carefully-tuned active queue management 74 mechanisms in the routers). This drop of a large number of packets 75 in the network can result in unnecessary retransmit timeouts for the 76 TCP connection. The TCP connection could end up in congestion 77 avoidance phase with a very small congestion window, and could take a 78 large number of round-trip times to recover its old congestion 79 window. This poor performance is illustrated in [F02]. 81 2. The Proposal for Limited Slow-Start 83 Limited Slow-Start introduces a parameter, "max_ssthresh", and the 84 slow-start is only modified for values of the congestion window 85 "cwnd" greater than "max_ssthresh". That is, during Slow-Start, when 87 cwnd <= max_ssthresh, 89 cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every 90 arriving ACK (acknowledgement) during slow-start, as is always the 91 case. During Limited Slow-Start, when 92 max_ssthresh < cwnd <= ssthresh, 94 the invariant is maintained that the congestion window is increased 95 during slow-start by at most max_ssthresh/2 MSS per round-trip time. 96 This is done as follows: 98 For each arriving ACK in slow-start: 99 If (cwnd <= max_ssthresh) 100 cwnd += MSS; 101 else 102 K = int(cwnd/(0.5 max_ssthresh)); 103 cwnd += int(MSS/K); 105 Thus during Limited Slow-Start the window is increased by 1/K MSS for 106 each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of 107 by 1 MSS as in the standard slow-start [RFC2581]. 109 When 111 ssthresh < cwnd, 113 slow-start is exited, and the sender is in the Congestion Avoidance 114 phase. 116 Our current recommendation would be for max_ssthresh to be set to 100 117 MSS. (This is illustrated in the NS simulator, for snapshots after 118 May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and 119 "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory 120 "tcl/lib".) However, max_ssthresh is an optional, configurable 121 parameter. TCP implementations that do not wish to use Limited Slow- 122 Start would set max_ssthresh to Infinity. 124 With Limited Slow-Start, when the congestion window is greater than 125 max_ssthresh the window is increased by at most 1/2 MSS for each 126 arriving ACK, when the congestion window is greater than 1.5 127 max_ssthresh the window is increased by at most 1/3 MSS for each 128 arriving ACK, and so on. 130 With Limited Slow-Start it takes: 132 log(max_ssthresh) 134 round-trip times to reach a congestion window of max_ssthresh, and it 135 takes: 137 log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2) 139 round-trip times to reach a congestion window of cwnd, for a 140 congestion window greater than max_ssthresh. 142 Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it 143 would take 836 round-trip times to reach a congestion window of 144 83,000 packets, compared to 16 round-trip times without Limited Slow- 145 Start (assuming no packet drops). With Limited Slow-Start, the 146 largest transient queue during slow-start would be 100 packets; 147 without Limited Slow-Start, the transient queue during Slow-Start 148 would reach more than 32,000 packets. 150 By limiting the maximum increase in the congestion window in a round- 151 trip time, Limited Slow-Start can reduce the number of drops during 152 slow-start, and improve the performance of TCP connections with large 153 congestion windows. 155 3. Experimental Results 157 Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 158 kernel, and performed experiments comparing TCP with and without 159 Limited Slow-Start [D02]. Preliminary results show improved 160 performance for TCPs using Limited Slow-Start. There are also 161 several experiments comparing different values for max_ssthresh. 163 More experiments will be needed to more fully evaluate Limited Slow- 164 Start. 166 4. Related Proposals 168 There has been considerable research on mechanisms for the TCP sender 169 to learn about the limitations of the available bandwidth, and to 170 exit slow-start before receiving a congestion indication from the 171 network [VEGAS,H96]. Other proposals set TCP's slow-start parameter 172 ssthresh based on information from previous TCP connections to the 173 same destination [WS95,G00]. This draft proposes a simple limitation 174 on slow-start that can be effective in some cases even in the absence 175 of such mechanisms. The max_ssthresh parameter does not replace 176 ssthresh, but is an additional parameter. Thus, Limited Slow-Start 177 could be used in addition to mechanisms for setting ssthresh. 179 Rate-based pacing has also been proposed to improve the performance 180 of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that 181 rate-based pacing could be of significant benefit, and could be used 182 in addition to the Limited Slow-Start in this proposal. 184 Appropriate Byte Counting [A01] proposes that TCP increase its 185 congestion window as a function of the number of bytes acknowledged, 186 rather than as a function of the number of ACKs received. 187 Appropriate Byte Counting is largely orthogonal to this proposal for 188 Limited Slow-Start. 190 Limited Slow-Start is also orthogonal to other proposals to change 191 mechanisms for exiting slow-start. For example, FACK TCP includes an 192 overdamping mechanism to decrease the congestion window somewhat more 193 aggressively when a loss occurs during slow-start [MM96]. It is also 194 true that larger values for the MSS would reduce the size of the 195 congestion window in units of MSS needed to fill a given pipe, and 196 therefore would reduce the size of the transient queue in units of 197 MSS. 199 5. Acknowledgements 201 This proposal is part of a larger proposal for HighSpeed TCP for TCP 202 connections with large congestion windows, and resulted from 203 simulations done by Evandro de Souza, in joint work with Deb Agarwal. 204 This proposal for Limited Slow-Start drew in part from discussions 205 with Tom Kelly, who has used a similar modified slow-start in his own 206 research with congestion control for high-bandwidth connections. We 207 also thank Tom Dunigan for his experiments with Limited Slow-Start. 209 We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End 210 Research Group, and members of the Transport Area Working Group, for 211 feedback on this document. 213 6. Normative References 215 [A01] Mark Allman, "TCP Congestion Control with Appropriate Byte 216 Counting", draft-allman-tcp-abc-02.txt, internet-draft, work-in- 217 progress, November 2001. 219 [RFC2581] M. Allman and V. Paxson, "TCP Congestion Control", RFC 220 2581, April 1999. 222 7. Informative References 224 [AD98] Mohit Aron and Peter Druschel, "TCP: Improving Start-up 225 Dynamics by Adaptive Timers and Congestion Control"", TR98-318, Rice 226 University, 1998. URL "http://cs- 227 tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98-318/". 229 [ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the 230 Performance of TCP Pacing", Proceedings of the 2000 IEEE Infocom 231 Conference, Tel-Aviv, Israel, March, 2000. URL 232 "http://www.cs.ucsd.edu/~savage/". 234 [D02] T. Dunigan, "Floyd's TCP slow-start and AIMD mods", 2002. URL 235 "http://www.csm.ornl.gov/~dunigan/net100/floyd.html". 237 [F02] S. Floyd, "Performance Problems with TCP's Slow-Start", 2002. 238 URL "http://www.icir.org/floyd/hstcp/slowstart/". 240 [G00] A. Gurtov, "TCP Performance in the Presence of Congestion and 241 Corruption Losses", Master's Thesis, University of Helsinki, 242 Department of Computer Science, Helsinki, December 2000. URL 243 "http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html". 245 [H96] J. C. Hoe, "Improving the Start-up Behavior of a Congestion 246 Control Scheme for TCP", SIGCOMM 96, 1996. URL 247 "http://www.acm.org/sigcomm/sigcomm96/program.html". 249 [KCRP99] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A 250 Simulation Study of Paced TCP", BBN Technical Memorandum No. 1218, 251 1999. URL "http://mimas.lcs.mit.edu/~jokulik/tcppacing.html". 253 [MM96] M. Mathis and J. Mahdavi, "Forward Acknowledgment: Refining 254 TCP Congestion Control", SIGCOMM, August 1996. 256 [VEGAS] Vegas Web Page, University of Arizona. URL 257 "http://www.cs.arizona.edu/protocols/". 259 [VH97] Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing 260 for TCP", 1997. URL 261 "http://www.isi.edu/lsam/publications/rate_based_pacing/". 263 [WS95] G. Wright and W. Stevens, "TCP/IP Illustrated", Volume 2, 264 Addison-Wesley Publishing Company, 1995. 266 8. Security Considerations 268 This proposal makes no changes to the underlying security of TCP. 270 8. IANA Considerations 272 There are no IANA considerations regarding this document. 274 AUTHORS' ADDRESSES 276 Sally Floyd 277 Phone: +1 (510) 666-2989 278 ICIR (ICSI Center for Internet Research) 279 Email: floyd@icir.org 280 URL: http://www.icir.org/floyd/ 282 This draft was created in August 2002.