RFC 3742

Limited Slow-Start for TCP with Large Congestion Windows 🎀

Okay bestie, this is RFC 3742 🦋 It was written by Sally Floyd of ICSI, it's marked Category: Experimental, and it dropped in March 2004. It doesn't list anything it obsoletes or updates, so it's a standalone experiment 💅

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community, so it isn't an Internet standard of any kind 🧚 Feedback and suggestions for making it better are very much wanted, and you're free to share it as widely as you like 💜

Copyright Notice 🌸

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🔥

Okay so this doc is about a tweak to TCP's slow-start, specifically for TCP connections with huge congestion windows 😭 When a connection can use windows of thousands (or tens of thousands) of MSS-sized segments (MSS being the sender's MAXIMUM SEGMENT SIZE), regular slow-start can blow the congestion window up by thousands of segments in one round-trip time. That's giving chaos, because thousands of packets can get dropped in a single RTT. It usually backfires for the flow itself, and it's rude to everyone else sharing the congested link 💀

So this note introduces Limited Slow-Start 🦋 It's an optional mechanism that caps how many segments the congestion window can grow by during one window of data in slow-start. The goal is better performance for those big-window connections ✨

1. Introduction 🌈

Same energy as the abstract, bestie 💅 This note is an optional tweak to TCP's slow-start for connections with large congestion windows. When those connections can use windows of thousands (or tens of thousands) of MSS-sized segments (MSS again meaning the sender's MAXIMUM SEGMENT SIZE), normal slow-start can grow the window by thousands of segments in one round-trip time. That's a lot of packets to dump into the network at once, and it can easily cause thousands of drops in a single RTT. It's counter-productive for the flow itself, and it's also a nightmare for the other traffic on the congested link 😭 This note describes Limited Slow-Start, which caps how many segments the congestion window grows by during one window of data in slow-start, so those big-window connections perform better 🎀

Here's the drama 🙈 When slow-start causes a huge jump in one RTT, a ton of packets can get dropped, even if the routers are running carefully tuned active queue management. Those mass drops can trigger unnecessary retransmit timeouts. The connection can then end up in congestion avoidance with a tiny congestion window, and it might take a whole lot of round-trip times just to get back to where it was 💔 This poor performance is illustrated in [F02].

2. The Proposal for Limited Slow-Start 💖

Limited Slow-Start brings in a parameter called "max_ssthresh" and changes slow-start for the cases where "cwnd" is bigger than "max_ssthresh" 🦋 So, during slow-start, when:

   cwnd <= max_ssthresh,

the congestion window grows by one MSS (MAXIMUM SEGMENT SIZE) for every arriving ACK (acknowledgement) during slow-start, same as always 💅 Then, during Limited Slow-Start, when:

   max_ssthresh < cwnd <= ssthresh,

the invariant is kept so the congestion window grows by at most max_ssthresh/2 MSS per round-trip time during slow-start. Here's how that works 🧚

   For each arriving ACK in slow-start:
     If (cwnd <= max_ssthresh)
        cwnd += MSS;
     else
        K = int(cwnd/(0.5 max_ssthresh));
        cwnd += int(MSS/K);

So the window grows by 1/K MSS for each arriving ACK, where K = int(cwnd/(0.5 max_ssthresh)). Standard slow-start [RFC2581] would instead add 1 MSS per ACK, so this is a major glow-down 💅

When:

   ssthresh < cwnd

slow-start is exited, and the sender moves into the Congestion Avoidance phase 🌸

Our recommendation is to set max_ssthresh to 100 MSS ✨ (You can see this in the NS [NS] simulator, using snapshots after May 1, 2002, with the tests "./test-all-tcpHighspeed tcp1A" and "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory "tcl/lib". Setting max_ssthresh to Infinity makes the TCP connection in NS skip Limited Slow-Start 🙃)

With Limited Slow-Start, once the congestion window is bigger than max_ssthresh, the window grows by at most 1/2 MSS per ACK. Once it's bigger than 1.5 max_ssthresh, it grows by at most 1/3 MSS per ACK, and so on 🌈

Now the numbers, because they're iconic 📊 With Limited Slow-Start, it takes:

   log(max_ssthresh)

round-trip times to reach a congestion window of max_ssthresh, and for a congestion window bigger than max_ssthresh, it takes:

   log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)

round-trip times to reach a congestion window of cwnd 🧮

Plugging in max_ssthresh = 100 MSS: it takes 836 round-trip times to reach a congestion window of 83,000 packets. Without Limited Slow-Start (assuming no packet drops), it only takes 16 RTTs 😳 But the transient queue is the real win. With Limited Slow-Start, the largest transient queue during slow-start is 100 packets. Without it, the transient queue during slow-start would hit more than 32,000 packets 💀

By capping how much the window can jump in one RTT, Limited Slow-Start cuts the number of drops during slow-start and helps TCP connections with large congestion windows perform better 👑

3. Experimental Results 🧪

Tom Dunigan added Limited Slow-Start to the Linux 2.4.16 Web100 kernel and ran experiments comparing TCP with and without it [D02]. So far the results show better performance for the TCPs using Limited Slow-Start 🎉 There are also several experiments comparing different values for max_ssthresh 🍓

4. Related Proposals 🦋

Okay, there's been a ton of research on ways for the TCP sender to figure out how much bandwidth is actually available, so it can leave slow-start before the network sends a congestion signal [VEGAS,H96]. Other proposals set TCP's slow-start parameter ssthresh using info from previous TCP connections to the same destination [WS95,G00]. This document proposes a simple limit on slow-start that can work well in some cases even without those mechanisms 🧚 The max_ssthresh parameter doesn't replace ssthresh. It's an extra parameter, so Limited Slow-Start can be used alongside mechanisms that set ssthresh 💜

Rate-based pacing has also been proposed to improve TCP during slow-start [VH97,AD98,KCRP99,ASA00]. The authors believe rate-based pacing could be a big help, and that it could be used together with the Limited Slow-Start in this proposal ✨

Appropriate Byte Counting [RFC3465] proposes that TCP grow its congestion window based on the number of bytes acknowledged, instead of the number of ACKs received. That's mostly independent of this Limited Slow-Start proposal 🌸

Limited Slow-Start is also orthogonal to other proposals that change how slow-start gets exited 🙌 For example, FACK TCP has an overdamping mechanism that cuts the congestion window more aggressively when a loss happens during slow-start [MM96]. It's also true that larger MSS values would shrink the congestion window, measured in MSS units, needed to fill a given pipe, which would shrink the transient queue in MSS units too 🫶

5. Acknowledgements 💅

This proposal is part of a bigger proposal for HighSpeed TCP, aimed at TCP connections with large congestion windows. It came out of simulations done by Evandro de Souza, in joint work with Deb Agarwal 👑 The Limited Slow-Start piece partly comes from discussions with Tom Kelly, who uses a similar modified slow-start in his own research on congestion control for high-bandwidth connections 🌈 Thanks also to Tom Dunigan for his Limited Slow-Start experiments 🧚

Thanks as well to Andrei Gurtov, Reiner Ludwig, the members of the End-to-End Research Group, and the members of the Transport Area Working Group, for feedback on this document 💖

6. Security Considerations 🔐

This proposal makes no changes to the underlying security of TCP 🫶

7. References 📚

7.1. Normative References

   [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
             Control", RFC 2581, April 1999.

   [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
             Counting (ABC)", RFC 3465, February 2003.

7.2. Informative References

Full Copyright Statement ✨

Okay bestie, time for the legal bit 💅 Copyright (C) The Internet Society (2004). 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 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. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt 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. Send that info to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💖