idnits 2.17.1 draft-ietf-tsvwg-slowstart-00.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 6 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 7 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) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Downref: Normative reference to an Experimental RFC: RFC 3465 Summary: 5 errors (**), 0 flaws (~~), 3 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-ietf-tsvwg-slowstart-00.txt July, 2003 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 describes an optional modification for TCP's slow-start for 32 use with TCP connections with large congestion windows. For TCP 33 connections that are able to use congestion windows of thousands (or 34 tens of thousands) of MSS-sized segments (for MSS the sender's 35 MAXIMUM 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 describes 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-02.txt: 48 New name of draft. 50 Changes from draft-floyd-tcp-slowstart-01.txt: 52 * Minor changes in language to submit for an Experimental RFC. 54 Changes from draft-floyd-tcp-slowstart-00.txt: 56 * Small changes in presentation. 58 * The addition of a section of Experiments. 60 * More citations to related work. 62 1. Introduction 64 This note describes an optional modification for TCP's slow-start for 65 use with TCP connections with large congestion windows. For TCP 66 connections that are able to use congestion windows of thousands (or 67 tens of thousands) of MSS-sized segments (for MSS the sender's 68 MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in 69 increasing the congestion window by thousands of segments in a single 70 round-trip time. Such an increase can easily result in thousands of 71 packets being dropped in one round-trip time. This is often counter- 72 productive for the TCP flow itself, and is also hard on the rest of 73 the traffic sharing the congested link. This note describes Limited 74 Slow-Start, limiting the number of segments by which the congestion 75 window is increased for one window of data during slow-start, in 76 order to improve performance for TCP connections with large 77 congestion windows. 79 When slow-start results in a large increase in the congestion window 80 in one round-trip time, a large number of packets might be dropped in 81 the network (even with carefully-tuned active queue management 82 mechanisms in the routers). This drop of a large number of packets 83 in the network can result in unnecessary retransmit timeouts for the 84 TCP connection. The TCP connection could end up in congestion 85 avoidance phase with a very small congestion window, and could take a 86 large number of round-trip times to recover its old congestion 87 window. This poor performance is illustrated in [F02]. 89 2. The Proposal for Limited Slow-Start 91 Limited Slow-Start introduces a parameter, "max_ssthresh", and the 92 slow-start is only modified for values of the congestion window 93 "cwnd" greater than "max_ssthresh". That is, during Slow-Start, when 94 cwnd <= max_ssthresh, 96 cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every 97 arriving ACK (acknowledgement) during slow-start, as is always the 98 case. During Limited Slow-Start, when 100 max_ssthresh < cwnd <= ssthresh, 102 the invariant is maintained that the congestion window is increased 103 during slow-start by at most max_ssthresh/2 MSS per round-trip time. 104 This is done as follows: 106 For each arriving ACK in slow-start: 107 If (cwnd <= max_ssthresh) 108 cwnd += MSS; 109 else 110 K = int(cwnd/(0.5 max_ssthresh)); 111 cwnd += int(MSS/K); 113 Thus during Limited Slow-Start the window is increased by 1/K MSS for 114 each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of 115 by 1 MSS as in the standard slow-start [RFC2581]. 117 When 119 ssthresh < cwnd, 121 slow-start is exited, and the sender is in the Congestion Avoidance 122 phase. 124 Our recommendation would be for max_ssthresh to be set to 100 MSS. 125 (This is illustrated in the NS simulator, for snapshots after May 1, 126 2002, in the tests "./test-all-tcpHighspeed tcp1A" and "./test-all- 127 tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib". Setting 128 max_ssthresh to Infinity causes the TCP connection in NS not to use 129 Limited Slow-Start.) 131 With Limited Slow-Start, when the congestion window is greater than 132 max_ssthresh the window is increased by at most 1/2 MSS for each 133 arriving ACK, when the congestion window is greater than 1.5 134 max_ssthresh the window is increased by at most 1/3 MSS for each 135 arriving ACK, and so on. 137 With Limited Slow-Start it takes: 139 log(max_ssthresh) 141 round-trip times to reach a congestion window of max_ssthresh, and it 142 takes: 144 log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2) 146 round-trip times to reach a congestion window of cwnd, for a 147 congestion window greater than max_ssthresh. 149 Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it 150 would take 836 round-trip times to reach a congestion window of 151 83,000 packets, compared to 16 round-trip times without Limited Slow- 152 Start (assuming no packet drops). With Limited Slow-Start, the 153 largest transient queue during slow-start would be 100 packets; 154 without Limited Slow-Start, the transient queue during Slow-Start 155 would reach more than 32,000 packets. 157 By limiting the maximum increase in the congestion window in a round- 158 trip time, Limited Slow-Start can reduce the number of drops during 159 slow-start, and improve the performance of TCP connections with large 160 congestion windows. 162 3. Experimental Results 164 Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 165 kernel, and performed experiments comparing TCP with and without 166 Limited Slow-Start [D02]. Results so far show improved performance 167 for TCPs using Limited Slow-Start. There are also several 168 experiments comparing different values for max_ssthresh. 170 4. Related Proposals 172 There has been considerable research on mechanisms for the TCP sender 173 to learn about the limitations of the available bandwidth, and to 174 exit slow-start before receiving a congestion indication from the 175 network [VEGAS,H96]. Other proposals set TCP's slow-start parameter 176 ssthresh based on information from previous TCP connections to the 177 same destination [WS95,G00]. This draft proposes a simple limitation 178 on slow-start that can be effective in some cases even in the absence 179 of such mechanisms. The max_ssthresh parameter does not replace 180 ssthresh, but is an additional parameter. Thus, Limited Slow-Start 181 could be used in addition to mechanisms for setting ssthresh. 183 Rate-based pacing has also been proposed to improve the performance 184 of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that 185 rate-based pacing could be of significant benefit, and could be used 186 in addition to the Limited Slow-Start in this proposal. 188 Appropriate Byte Counting [RFC3465] proposes that TCP increase its 189 congestion window as a function of the number of bytes acknowledged, 190 rather than as a function of the number of ACKs received. 191 Appropriate Byte Counting is largely orthogonal to this proposal for 192 Limited Slow-Start. 194 Limited Slow-Start is also orthogonal to other proposals to change 195 mechanisms for exiting slow-start. For example, FACK TCP includes an 196 overdamping mechanism to decrease the congestion window somewhat more 197 aggressively when a loss occurs during slow-start [MM96]. It is also 198 true that larger values for the MSS would reduce the size of the 199 congestion window in units of MSS needed to fill a given pipe, and 200 therefore would reduce the size of the transient queue in units of 201 MSS. 203 5. Acknowledgements 205 This proposal is part of a larger proposal for HighSpeed TCP for TCP 206 connections with large congestion windows, and resulted from 207 simulations done by Evandro de Souza, in joint work with Deb Agarwal. 208 This proposal for Limited Slow-Start drew in part from discussions 209 with Tom Kelly, who has used a similar modified slow-start in his own 210 research with congestion control for high-bandwidth connections. We 211 also thank Tom Dunigan for his experiments with Limited Slow-Start. 213 We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End 214 Research Group, and members of the Transport Area Working Group, for 215 feedback on this document. 217 6. Normative References 219 [RFC2581] M. Allman and V. Paxson, "TCP Congestion Control", RFC 220 2581, April 1999. 222 [RFC3465] Mark Allman, "TCP Congestion Control with Appropriate Byte 223 Counting", RFC 3465, February 2003. 225 7. Informative References 227 [AD98] Mohit Aron and Peter Druschel, "TCP: Improving Start-up 228 Dynamics by Adaptive Timers and Congestion Control"", TR98-318, Rice 229 University, 1998. URL "http://cs- 230 tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98-318/". 232 [ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the 233 Performance of TCP Pacing", Proceedings of the 2000 IEEE Infocom 234 Conference, Tel-Aviv, Israel, March, 2000. URL 235 "http://www.cs.ucsd.edu/~savage/". 237 [D02] T. Dunigan, "Floyd's TCP slow-start and AIMD mods", 2002. URL 238 "http://www.csm.ornl.gov/~dunigan/net100/floyd.html". 240 [F02] S. Floyd, "Performance Problems with TCP's Slow-Start", 2002. 241 URL "http://www.icir.org/floyd/hstcp/slowstart/". 243 [G00] A. Gurtov, "TCP Performance in the Presence of Congestion and 244 Corruption Losses", Master's Thesis, University of Helsinki, 245 Department of Computer Science, Helsinki, December 2000. URL 246 "http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html". 248 [H96] J. C. Hoe, "Improving the Start-up Behavior of a Congestion 249 Control Scheme for TCP", SIGCOMM 96, 1996. URL 250 "http://www.acm.org/sigcomm/sigcomm96/program.html". 252 [KCRP99] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A 253 Simulation Study of Paced TCP", BBN Technical Memorandum No. 1218, 254 1999. URL "http://mimas.lcs.mit.edu/~jokulik/tcppacing.html". 256 [MM96] M. Mathis and J. Mahdavi, "Forward Acknowledgment: Refining 257 TCP Congestion Control", SIGCOMM, August 1996. 259 [VEGAS] Vegas Web Page, University of Arizona. URL 260 "http://www.cs.arizona.edu/protocols/". 262 [VH97] Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing 263 for TCP", 1997. URL 264 "http://www.isi.edu/lsam/publications/rate_based_pacing/". 266 [WS95] G. Wright and W. Stevens, "TCP/IP Illustrated", Volume 2, 267 Addison-Wesley Publishing Company, 1995. 269 8. Security Considerations 271 This proposal makes no changes to the underlying security of TCP. 273 8. IANA Considerations 275 There are no IANA considerations regarding this document. 277 AUTHORS' ADDRESSES 279 Sally Floyd 280 Phone: +1 (510) 666-2989 281 ICIR (ICSI Center for Internet Research) 282 Email: floyd@icir.org 283 URL: http://www.icir.org/floyd/ 284 This draft was first created in June 2002.