idnits 2.17.1 draft-floyd-tcp-slowstart-02.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) ** 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-floyd-tcp-slowstart-02.txt June, 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-01.txt: 48 * Minor changes in language to submit for an Experimental RFC. 50 Changes from draft-floyd-tcp-slowstart-00.txt: 52 * Small changes in presentation. 54 * The addition of a section of Experiments. 56 * More citations to related work. 58 1. Introduction 60 This note describes an optional modification for TCP's slow-start for 61 use with TCP connections with large congestion windows. For TCP 62 connections that are able to use congestion windows of thousands (or 63 tens of thousands) of MSS-sized segments (for MSS the sender's 64 MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in 65 increasing the congestion window by thousands of segments in a single 66 round-trip time. Such an increase can easily result in thousands of 67 packets being dropped in one round-trip time. This is often counter- 68 productive for the TCP flow itself, and is also hard on the rest of 69 the traffic sharing the congested link. This note describes Limited 70 Slow-Start, limiting the number of segments by which the congestion 71 window is increased for one window of data during slow-start, in 72 order to improve performance for TCP connections with large 73 congestion windows. 75 When slow-start results in a large increase in the congestion window 76 in one round-trip time, a large number of packets might be dropped in 77 the network (even with carefully-tuned active queue management 78 mechanisms in the routers). This drop of a large number of packets 79 in the network can result in unnecessary retransmit timeouts for the 80 TCP connection. The TCP connection could end up in congestion 81 avoidance phase with a very small congestion window, and could take a 82 large number of round-trip times to recover its old congestion 83 window. This poor performance is illustrated in [F02]. 85 2. The Proposal for Limited Slow-Start 87 Limited Slow-Start introduces a parameter, "max_ssthresh", and the 88 slow-start is only modified for values of the congestion window 89 "cwnd" greater than "max_ssthresh". That is, during Slow-Start, when 91 cwnd <= max_ssthresh, 93 cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every 94 arriving ACK (acknowledgement) during slow-start, as is always the 95 case. During Limited Slow-Start, when 97 max_ssthresh < cwnd <= ssthresh, 99 the invariant is maintained that the congestion window is increased 100 during slow-start by at most max_ssthresh/2 MSS per round-trip time. 101 This is done as follows: 103 For each arriving ACK in slow-start: 104 If (cwnd <= max_ssthresh) 105 cwnd += MSS; 106 else 107 K = int(cwnd/(0.5 max_ssthresh)); 108 cwnd += int(MSS/K); 110 Thus during Limited Slow-Start the window is increased by 1/K MSS for 111 each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of 112 by 1 MSS as in the standard slow-start [RFC2581]. 114 When 116 ssthresh < cwnd, 118 slow-start is exited, and the sender is in the Congestion Avoidance 119 phase. 121 Our recommendation would be for max_ssthresh to be set to 100 MSS. 122 (This is illustrated in the NS simulator, for snapshots after May 1, 123 2002, in the tests "./test-all-tcpHighspeed tcp1A" and "./test-all- 124 tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib". Setting 125 max_ssthresh to Infinity causes the TCP connection in NS not to use 126 Limited Slow-Start.) 128 With Limited Slow-Start, when the congestion window is greater than 129 max_ssthresh the window is increased by at most 1/2 MSS for each 130 arriving ACK, when the congestion window is greater than 1.5 131 max_ssthresh the window is increased by at most 1/3 MSS for each 132 arriving ACK, and so on. 134 With Limited Slow-Start it takes: 136 log(max_ssthresh) 138 round-trip times to reach a congestion window of max_ssthresh, and it 139 takes: 141 log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2) 143 round-trip times to reach a congestion window of cwnd, for a 144 congestion window greater than max_ssthresh. 146 Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it 147 would take 836 round-trip times to reach a congestion window of 148 83,000 packets, compared to 16 round-trip times without Limited Slow- 149 Start (assuming no packet drops). With Limited Slow-Start, the 150 largest transient queue during slow-start would be 100 packets; 151 without Limited Slow-Start, the transient queue during Slow-Start 152 would reach more than 32,000 packets. 154 By limiting the maximum increase in the congestion window in a round- 155 trip time, Limited Slow-Start can reduce the number of drops during 156 slow-start, and improve the performance of TCP connections with large 157 congestion windows. 159 3. Experimental Results 161 Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100 162 kernel, and performed experiments comparing TCP with and without 163 Limited Slow-Start [D02]. Results so far show improved performance 164 for TCPs using Limited Slow-Start. There are also several 165 experiments comparing different values for max_ssthresh. 167 4. Related Proposals 169 There has been considerable research on mechanisms for the TCP sender 170 to learn about the limitations of the available bandwidth, and to 171 exit slow-start before receiving a congestion indication from the 172 network [VEGAS,H96]. Other proposals set TCP's slow-start parameter 173 ssthresh based on information from previous TCP connections to the 174 same destination [WS95,G00]. This draft proposes a simple limitation 175 on slow-start that can be effective in some cases even in the absence 176 of such mechanisms. The max_ssthresh parameter does not replace 177 ssthresh, but is an additional parameter. Thus, Limited Slow-Start 178 could be used in addition to mechanisms for setting ssthresh. 180 Rate-based pacing has also been proposed to improve the performance 181 of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that 182 rate-based pacing could be of significant benefit, and could be used 183 in addition to the Limited Slow-Start in this proposal. 185 Appropriate Byte Counting [RFC3465] proposes that TCP increase its 186 congestion window as a function of the number of bytes acknowledged, 187 rather than as a function of the number of ACKs received. 188 Appropriate Byte Counting is largely orthogonal to this proposal for 189 Limited Slow-Start. 191 Limited Slow-Start is also orthogonal to other proposals to change 192 mechanisms for exiting slow-start. For example, FACK TCP includes an 193 overdamping mechanism to decrease the congestion window somewhat more 194 aggressively when a loss occurs during slow-start [MM96]. It is also 195 true that larger values for the MSS would reduce the size of the 196 congestion window in units of MSS needed to fill a given pipe, and 197 therefore would reduce the size of the transient queue in units of 198 MSS. 200 5. Acknowledgements 202 This proposal is part of a larger proposal for HighSpeed TCP for TCP 203 connections with large congestion windows, and resulted from 204 simulations done by Evandro de Souza, in joint work with Deb Agarwal. 205 This proposal for Limited Slow-Start drew in part from discussions 206 with Tom Kelly, who has used a similar modified slow-start in his own 207 research with congestion control for high-bandwidth connections. We 208 also thank Tom Dunigan for his experiments with Limited Slow-Start. 210 We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End 211 Research Group, and members of the Transport Area Working Group, for 212 feedback on this document. 214 6. Normative References 216 [RFC2581] M. Allman and V. Paxson, "TCP Congestion Control", RFC 217 2581, April 1999. 219 [RFC3465] Mark Allman, "TCP Congestion Control with Appropriate Byte 220 Counting", RFC 3465, February 2003. 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.