idnits 2.17.1 draft-floyd-tcp-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 4 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 5 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-00.txt June, 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, limiting the number of segments by which the congestion 42 window is increased for one window of data during slow-start, in 43 order to improve performance for TCP connections with large 44 congestion windows. 46 1. Introduction 48 This note proposes a modification for TCP's slow-start for use with 49 TCP connections with large congestion windows. For TCP connections 50 that are able to use congestion windows of thousands (or tens of 51 thousands) of MSS-sized segments (for MSS the sender's MAXIMUM 52 SEGMENT SIZE), the current slow-start procedure can result in 53 increasing the congestion window by thousands of segments in a single 54 round-trip time. Such an increase can easily result in thousands of 55 packets being dropped in one round-trip time. This is often counter- 56 productive for the TCP flow itself, and is also hard on the rest of 57 the traffic sharing the congested link. This note proposes Limited 58 Slow-Start, limiting the number of segments by which the congestion 59 window is increased for one window of data during slow-start, in 60 order to improve performance for TCP connections with large 61 congestion windows. 63 When slow-start results in a large increase in the congestion window 64 in one round-trip time, the subsequent drop of a large number of 65 packets in the network can result in unnecessary retransmit timeouts 66 for the TCP connection. The TCP connection could end up in 67 congestion avoidance phase with a very small congestion window, and 68 could take a large number of round-trip times to recover its old 69 congestion window. This poor performance is illustrated in [F02]. 71 2. The Proposal for Limited Slow-Start 73 Limited Slow-Start introduces a parameter, "max_ssthresh", and the 74 slow-start is only modified for values of the congestion window 75 "cwnd" greater than "max_ssthresh". That is, for: 77 cwnd <= max_ssthresh 79 cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every 80 arriving ACK (acknowledgement) during slow-start, as is always the 81 case. For: 83 cwnd > max_ssthresh 85 the invariant is maintained that the congestion window is increased 86 during slow-start by at most max_ssthresh/2 MSS per round-trip time. 88 This is done as follows: 90 For each arriving ACK in slow-start: 91 If (cwnd <= max_ssthresh) 92 cwnd += MSS; 93 else 94 K = int(cwnd/(0.5 max_ssthresh)); 95 cwnd += int(MSS/K); 97 Thus during Limited Slow-Start the window is increased by 1/K MSS for 98 each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of 99 by 1 MSS as in the standard slow-start [RFC2581]. 101 Our current recommendation would be for max_ssthresh to be set to 100 102 MSS. (This is illustrated in the NS simulator, for snapshots after 103 May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and 104 "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory 105 "tcl/lib".) 107 With Limited Slow-Start, when the congestion window is greater than 108 max_ssthresh the window is increased by at most 1/2 MSS for each 109 arriving ACK, when the congestion window is greater than 1.5 110 max_ssthresh the window is increased by at most 1/3 MSS for each 111 arriving ACK, and so on. 113 With Limited Slow-Start it takes: 115 log(max_ssthresh) 117 round-trip times to reach a congestion window of max_ssthresh, and it 118 takes: 120 log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2) 122 round-trip times to reach a congestion window of cwnd, for a 123 congestion window greater than max_ssthresh. 125 By limiting the maximum increase in the congestion window in a round- 126 trip time, Limited Slow-Start can reduce the number of drops during 127 slow-start, and improve the performance of TCP connections with large 128 congestion windows. 130 3. Related Proposals 132 There has been considerable research on mechanisms for the TCP sender 133 to learn about the limitations of the available bandwidth, and to 134 exit slow-start before receiving a congestion indication from the 135 network [VEGAS,H96]. This draft proposes a simple limitation on 136 slow-start that can be effective in some cases even in the absence of 137 such mechanisms. 139 Rate-based pacing has also been proposed to improve the performance 140 of TCP during slow-start [VH97,AD98,KCRP99,ASA00]. We believe that 141 rate-based pacing could be of significant benefit, and could be used 142 in addition to the Limited Slow-Start in this proposal. 144 Appropriate Byte Counting [A01] proposes that TCP increase its 145 congestion window as a function of the number of bytes acknowledged, 146 rather than as a function of the number of ACKs received. 147 Appropriate Byte Counting is largely orthogonal to this proposal for 148 Limited Slow-Start. 150 (If I have missed acknowledgements to other relevent proposals, 151 including to other proposals to set the initial value of ssthresh, 152 please let me know.) 154 4. Acknowledgements 156 This proposal is part of a larger proposal for HighSpeed TCP for TCP 157 connections with large congestion windows, and resulted from 158 simulations done by Evandro de Souza, in joint work with Deb Agarwal. 159 This proposal for Limited Slow-Start drew in part from discussions 160 with Tom Kelly, who has used a similar modified slow-start in his own 161 research with congestion control for high-bandwidth connections. 163 5. Normative References 165 [A01] Mark Allman, "TCP Congestion Control with Appropriate Byte 166 Counting", draft-allman-tcp-abc-02.txt, internet-draft, work-in- 167 progress, November 2001. 169 [RFC2581] M. Allman and V. Paxson, "TCP Congestion Control", RFC 170 2581, April 1999. 172 6. Informative References 174 [AD98] Mohit Aron and Peter Druschel, "TCP: Improving Start-up 175 Dynamics by Adaptive Timers and Congestion Control"", TR98-318, Rice 176 University, 1998. URL "http://cs- 177 tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98-318/". 179 [ASA00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the 180 Performance of TCP Pacing", Proceedings of the 2000 IEEE Infocom 181 Conference, Tel-Aviv, Israel, March, 2000. URL 182 "http://www.cs.ucsd.edu/~savage/". 184 [F02] S. Floyd, "Performance Problems with TCP's Slow-Start", 2002. 185 URL "http://www.icir.org/floyd/hstcp/slowstart/". 187 [H96] J. C. Hoe, "Improving the Start-up Behavior of a Congestion 188 Control Scheme for TCP", SIGCOMM 96, 1996. URL 189 "http://www.acm.org/sigcomm/sigcomm96/program.html". 191 [KCRP99] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A 192 Simulation Study of Paced TCP", BBN Technical Memorandum No. 1218, 193 1999. URL "http://mimas.lcs.mit.edu/~jokulik/tcppacing.html". 195 [VEGAS] Vegas Web Page, University of Arizona. URL 196 "http://www.cs.arizona.edu/protocols/". 198 [VH97] Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing 199 for TCP", 1997. URL 200 "http://www.isi.edu/lsam/publications/rate_based_pacing/". 202 7. Security Considerations 204 This proposal makes no changes to the underlying security of TCP. 206 8. IANA Considerations 208 There are no IANA considerations regarding this document. 210 AUTHORS' ADDRESSES 212 Sally Floyd 213 Phone: +1 (510) 666-2989 214 ICIR (ICSI Center for Internet Research) 215 Email: floyd@icir.org 216 URL: http://www.icir.org/floyd/ 218 This draft was created in June 2002.