RFC 2414

Increasing TCP's Initial Window

📅 published September 1998, from ietf

Increasing TCP's Initial Window ✨

Okay bestie, this is RFC 2414 🎀 It was written by M. Allman (NASA Lewis/Sterling Software), S. Floyd (LBNL), and C. Partridge (BBN Technologies) in September 1998, and it's filed under the Network Working Group 🍓 The category is Experimental, so it's an experiment and not a standard 🧪 The title block doesn't list any RFC it obsoletes or updates. It just sits there being iconic on its own ✨

Status of this Memo

This memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested, and distribution of this memo is unlimited 💖

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

Abstract

This document specifies an increase in the permitted initial window for TCP, going from one segment to roughly 4K bytes 🦋 It digs into the advantages and disadvantages of that change, and it shares experimental results showing the costs and benefits of the change to TCP 📊

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 💅

1. TCP Modification

Okay so this document bumps up the permitted upper bound for TCP's initial window, from one segment to somewhere between two and four segments 🌸 Most of the time that works out to roughly 4K bytes. But if the segment size is large, the permitted initial window of two segments could be way bigger than 4K bytes 😭 The upper bound is given more precisely in equation (1):

          min (4*MSS, max (2*MSS, 4380 bytes))               (1)

Equivalently, the upper bound for the initial window size depends on the maximum segment size (MSS) like this:

        If (MSS <= 1095 bytes)
            then win <= 4 * MSS;
        If (1095 bytes < MSS < 2190 bytes)
            then win <= 4380;
        If (2190 bytes <= MSS)
            then win <= 2 * MSS;

This increased initial window is optional: that a TCP MAY start with a larger initial window, not that it SHOULD. 🫶

This upper bound for the initial window size is a glow-up from RFC 2001 [S97], which says the congestion window gets initialized to one segment 💜 If implementation experience proves successful, then the intent is for this change to be folded into a revision of RFC 2001 🔥

This change applies to the initial window of the connection in the first round trip time (RTT) of transmission after the TCP three-way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in the three-way handshake should increase the initial window size above what's outlined in equation (1) ✨ If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment 🙈

TCP implementations use slow start in as many as three different ways: (1) to start a new connection (the initial window); (2) to restart a transmission after a long idle period (the restart window); and (3) to restart after a retransmit timeout (the loss window). This document's change affects the value of the initial window, which is the main character here 👑 Optionally, a TCP MAY set the restart window to the minimum of the value used for the initial window and the current value of cwnd. In other words, using a larger value for the restart window should never increase the size of cwnd 🧚 These changes do NOT change the loss window, which must remain 1 segment, so the window stays as small as possible in the case of severe congestion 🌧️

2. Implementation Issues

Okay so when larger initial windows are implemented along with Path MTU Discovery [MD90], and the MSS being used turns out to be too large, the congestion window `cwnd' SHOULD be reduced to prevent large bursts of smaller segments 🌊 Specifically, `cwnd' SHOULD be reduced by the ratio of the old segment size to the new segment size 📉

When larger initial windows are implemented along with Path MTU Discovery [MD90], there are alternatives. You can set the "Don't Fragment" (DF) bit in all segments in the initial window, or you can set the "Don't Fragment" (DF) bit in just one of the segments. Which of these two is best is an open question 🤔 We'd hope implementation experiences will shed light on it. If you set the DF bit in all segments and the initial packets are too large, then all of the initial packets will be dropped in the network 💀 If you set the DF bit in only one segment and the initial packets are too large, then all but one of the initial packets will be fragmented in the network. When you go with that second option, setting the DF bit in the last segment in the initial window gives the least chance for needless retransmissions when the initial segment size is found to be too large, because it minimizes the chances of duplicate ACKs triggering a Fast Retransmit 🦋 Still, more attention needs to be paid to how larger initial windows and Path MTU Discovery interact 👀

The larger initial window proposed here is not meant to encourage web browsers to open multiple simultaneous TCP connections, all with large initial windows 🙅‍♀️ When web browsers open simultaneous TCP connections to the same destination, it works against TCP's congestion control mechanisms [FF98], no matter how big the initial window is. Combining that behavior with larger initial windows makes the unfairness to other traffic in the network even worse 😤

3. Advantages of Larger Initial Windows

  1. When the initial window is one segment, a receiver using delayed ACKs [Bra89] is forced to wait for a timeout before generating an ACK 😩 With an initial window of at least two segments, the receiver will generate an ACK after the second data segment arrives. That gets rid of the wait on the timeout, which is often up to 200 msec ⚡
  2. For connections transmitting only a small amount of data, a larger initial window reduces the transmission time, assuming at most moderate segment drop rates 📦 For a lot of email (SMTP [Pos82]) and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less than 4K bytes, the larger initial window would cut the data transfer time down to a single RTT 🎉
  3. For connections that can use large congestion windows, this modification eliminates up to three RTTs and a delayed ACK timeout during the initial slow-start phase 🚀 This is especially helpful for high-bandwidth, large-propagation-delay TCP connections, like the ones over satellite links 🛰️

4. Disadvantages of Larger Initial Windows for the Individual Connection

In high-congestion environments, particularly for routers that have a bias against bursty traffic (like typical Drop Tail router queues), a TCP connection can sometimes be better off starting with an initial window of one segment 🥲 There are scenarios where a connection slow-starting from one segment might not have any segments dropped, while a connection starting with an initial window of four segments might hit unnecessary retransmits because the router can't handle small bursts. That could lead to an unnecessary retransmit timeout 😵 For a large-window connection that can recover without a retransmit timeout, this could cause an unnecessarily early switch from the slow-start phase to the congestion-avoidance phase of the window increase algorithm. These premature segment drops are unlikely in uncongested networks with sufficient buffering, or in moderately-congested networks where the congested router uses active queue management (such as Random Early Detection [FJ93, RFC2309]) 🛡️

Some TCP connections will still get better performance with the higher initial window, even if the burstiness of the initial window causes premature segment drops 🌟 That's true if (1) the TCP connection recovers from the segment drop without a retransmit timeout, and (2) the TCP connection is ultimately limited to a small congestion window, either by network congestion or by the receiver's advertised window 💖

5. Disadvantages of Larger Initial Windows for the Network 🌐

okay bestie, let's talk about the network's side of things 💅 In terms of congestion collapse, we look at two separate dangers for the network. The first danger is a scenario where a large number of segments on congested links are duplicates, meaning segments the receiver already got. The second danger is a scenario where a large number of segments on congested links get dropped later in the network before they reach their final destination.

When we think about the negative effect on other traffic, a possible downside of larger initial windows is that they could raise the general packet drop rate in the network. We'll go through all three issues below 🫶

Duplicate segments:

As we covered in the previous section, the larger initial window could occasionally cause a segment to be dropped from the initial window, when that segment might not have been dropped if the sender had slow-started from an initial window of one segment. BUT Appendix A shows that even in this case, the larger initial window would not result in the transmission of a large number of duplicate segments ✨ no duplicate flood, we're safe 💖

Segments dropped later in the network:

So how much would the larger initial window for TCP increase the number of segments on congested links that get dropped before reaching their destination? This can only happen for connections with multiple congested links. Some segments might use up scarce bandwidth on the first congested link along the path, only to get dropped later along the path 😭

First, lots of TCP connections will only have one congested link along the path. Segments dropped from these connections do not "waste" scarce bandwidth, and they do not contribute to congestion collapse 🎀

Now, some network paths will have multiple congested links, and segments dropped from the initial window could use scarce bandwidth on the earlier congested links before finally getting dropped on the later ones. To the extent that the drop rate is independent of the initial window used by TCP segments, this problem of congested links carrying segments that will be dropped before reaching their destination will look about the same for TCP connections that start by sending four segments or one segment. Same vibes either way 🦋

An increased packet drop rate:

For a network with a high segment drop rate, increasing the TCP initial window could push the segment drop rate even higher. Part of the reason is that routers with Drop Tail queue management have a hard time with bursty traffic when things are congested 💀 However, given uncorrelated arrivals for TCP connections, the larger TCP initial window should not significantly increase the segment drop rate. Simulation-based explorations of these issues are discussed in Section 7.2 🧚

These potential dangers for the network get tested in the simulations and experiments described in the section below 🔥 Our judgement is that while there are dangers of congestion collapse in the current Internet (see [FF98] for a discussion of the dangers of congestion collapse from an increased deployment of UDP connections without end-to-end congestion control), there is no such danger to the network from increasing the TCP initial window to 4K bytes. Main character energy for 4K 👑

6. Typical Levels of Burstiness for TCP Traffic. 🌈

Larger TCP initial windows would not dramatically increase the burstiness of TCP traffic on the Internet today, because that traffic is already fairly bursty 😭 Bursts of two and three segments are already typical of TCP [Flo97]. A delayed ACK (covering two previously unacknowledged segments) received during congestion avoidance makes the congestion window slide and two segments get sent. That same delayed ACK received during slow start makes the window slide by two segments and then get incremented by one segment, which gives you a three-segment burst 🍓

Bursts of four and five segments for TCP are not rare, though they're not necessarily typical. Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK to cover four previously unacknowledged segments. During congestion avoidance this leads to a four-segment burst, and during slow start a five-segment burst is generated 🙈

There are also changes in progress that reduce the performance problems posed by moderate traffic bursts. One is the deployment of higher-speed links in some parts of the network, where a burst of 4K bytes can represent a small quantity of data ⭐ Another change, for routers with sufficient buffering, is the deployment of queue management mechanisms such as RED, which is designed to be tolerant of transient traffic bursts 💜

7. Simulations and Experimental Results 🧪

7.1 Studies of TCP Connections using that Larger Initial Window

This section surveys the simulations and experiments that have been used to explore the effect of larger initial windows on the TCP connection using that larger window ✨ The first set of experiments looks at performance over satellite links. Larger initial windows have been shown to improve performance of TCP connections over satellite channels [All97b]. In this study, an initial window of four segments (512 byte MSS) gave throughput improvements of up to 30% (depending on transfer size) 🛰️ [KAGT98] shows that using larger initial windows decreases transfer time in HTTP tests over the ACTS satellite system. And a study with simulations of a large number of HTTP transactions over hybrid fiber coax (HFC) finds that larger initial windows decrease the time required to load WWW pages [Nic97] 🌸

A second set of experiments explored TCP performance over dialup modem links. In experiments over a 28.8 bps dialup channel [All97a, AHO98], a four-segment initial window decreased the transfer time of a 16KB file by roughly 10%, with no accompanying increase in the drop rate 📞 A particular area of concern has been TCP performance over low speed tail circuits (e.g., dialup modem links) with routers that have small buffers 😬 A simulation study [SP97] looked at the effects of using a larger initial window on a host connected by a slow modem link and a router with a 3 packet buffer. The study concluded that, for the scenario investigated, the use of larger initial windows was not harmful to TCP performance 💖 Questions have been raised about the effects of larger initial windows on the transfer time for short transfers in this environment, but these effects have not been quantified. A question has also been raised about the possible effect on existing TCP connections sharing the link 🤔

7.2 Studies of Networks using Larger Initial Windows

This section surveys simulations and experiments that investigate the impact of the larger window on other TCP connections sharing the path 👀 Experiments in [All97a, AHO98] show that for 16 KB transfers to 100 Internet hosts, four-segment initial windows resulted in a small increase in the drop rate of 0.04 segments/transfer. Even though the drop rate went up a little, transfer time dropped by roughly 25% for transfers using the four-segment (512 byte MSS) initial window compared to an initial window of one segment 🎉

One scenario of concern is heavily loaded links. For instance, a couple of years ago, one of the trans-Atlantic links was so heavily loaded that the correct congestion window size for a connection was about one segment. In that environment, new connections using larger initial windows would be starting with windows that were four times too big 😱 So what would the effects be? Do connections thrash? 🌀

A simulation study in [PN98] explores the impact of a larger initial window on competing network traffic. In this investigation, HTTP and FTP flows share a single congested gateway (where the number of HTTP and FTP flows varies from one simulation set to another). For each simulation set, the paper examines aggregate link utilization and packet drop rates, median web page delay, and network power for the FTP transfers. The larger initial window generally resulted in increased throughput, slightly increased packet drop rates, and an increase in overall network power 📈 With one exception, the larger initial window resulted in an increase in the drop rate of less than 1% above the loss rate seen with a one-segment initial window. In that one scenario, the drop rate went from 3.5% with one-segment initial windows to 4.5% with four-segment initial windows 🫠 The overall conclusions were that increasing the TCP initial window to three packets (or 4380 bytes) helps to improve perceived performance 💅

Morris [Mor97] investigated larger initial windows in a very congested network with transfers of size 20K. The loss rate in networks where all TCP connections use an initial window of four segments is shown to be 1-2% greater than in a network where all connections use an initial window of one segment. This relationship held in scenarios where the loss rates with one-segment initial windows ranged from 1% to 11% 📉 Also, in networks where connections used an initial window of four segments, TCP connections spent more time waiting for the retransmit timer (RTO) to expire so they could resend a segment than they did with an initial window of one segment. That time waiting for the RTO timer to expire is idle time, when no useful work is getting done for that connection 😤 These results show that in a very congested environment, where each connection's share of the bottleneck bandwidth is close to one segment, using a larger initial window can cause a noticeable increase in both loss rates and retransmit timeouts 🚨

8. Security Considerations 🔐

⚠️ This document discusses the initial congestion window permitted for TCP connections. Changing this value does not raise any known new security issues with TCP.

9. Conclusion 🍑

This document proposes a small change to TCP that may be beneficial to short-lived TCP connections and to those over links with long RTTs, saving several RTTs during the initial slow-start phase ✨

10. Acknowledgments 🫶

We would like to acknowledge Vern Paxson, Tim Shepard, members of the End-to-End-Interest Mailing List, and members of the IETF TCP Implementation Working Group for their continuing discussions of these issues and for their feedback on this document 💜

11. References ✨

okay so here's the reading list, bestie 📚 every single citation is kept exactly as written, so you can go hunting for any of them 🦋

  • [All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting -- TCP Implementations WG. December, 1997. Washington, DC.
  • [AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. Submitted to ACM Computer Communication Review. URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps".
  • [All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
  • [BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
  • [Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
  • [FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
  • [FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking. URL "http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".
  • [FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
  • [FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
  • [Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
  • [Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
  • [Flo97] Floyd, S., Increasing TCP's Initial Window. Viewgraphs, 40th IETF Meeting - TCP Implementations WG. December, 1997. URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
  • [KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".
  • [MD90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
  • [MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
  • [Mor97] Robert Morris. Private communication, 1997. Cited for acknowledgement purposes only.
  • [Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
  • [PN98] Poduri, K., and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
  • [Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
  • [RF97] Ramakrishnan, K., and S. Floyd, "A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Work in Progress.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
  • [S97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
  • [SP97] Shepard, T., and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.

12. Author's Addresses 💌

here's where to find the crew 🫶 the addresses are kept exactly as they were

Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Road
MS 54-2
Cleveland, OH 44135

EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/


Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720

EMail: floyd@ee.lbl.gov


Craig Partridge
BBN Technologies
10 Moulton Street
Cambridge, MA 02138

EMail: craig@bbn.com

13. Appendix - Duplicate Segments 🔁

okay so this appendix is the big question 👑 when TCP sends a bigger initial window, does it end up resending segments the receiver already has? spoiler: it's giving "not really" 💅

the setup: without Explicit Congestion Notification [Flo94] [RF97], every TCP uses segment drops as its signal about how much bandwidth is available. the argument here is that switching to a larger initial window should not cause the sender to retransmit a big pile of duplicate segments that the receiver has already got. ✨

if ONE segment gets dropped from the initial window, TCP has three ways to recover 🔥

  1. slow-starting from a window of one segment, which is what happens after a retransmit timeout, or after Fast Retransmit in Tahoe TCP;
  2. Fast Recovery without selective acknowledgments (SACK), which is what Reno TCP does after three duplicate ACKs;
  3. Fast Recovery with SACK, for TCP where both the sender and the receiver support the SACK option [MMFR96].

in all three cases, a single dropped segment from the initial window means NO duplicate segments (segments the receiver has already received) get sent 🙌 also, for a TCP sending four 512-byte segments in the initial window, one dropped segment won't need a retransmit timeout. it can be recovered with Fast Retransmit (unless the retransmit timer expires early).

a single drop from a three-segment initial window might be fixed with Fast Retransmit too, depending on which segment got dropped and whether delayed ACKs are in use. for example, dropping the first segment of a three-segment window will ALWAYS mean waiting for a timeout 😭 but dropping the third segment will ALWAYS allow recovery through Fast Retransmit, as long as no ACKs get lost.

next up, scenarios where the initial window has two to four segments and at least two of them get dropped. if EVERY segment in the initial window is dropped, then clearly no duplicates get retransmitted, because the receiver hasn't received anything yet 🥺 (it's still possible those dropped segments used scarce bandwidth on the way to the drop point, and that issue was already discussed in Section 5.)

  • two drops out of a three-segment window: the sender only sends a duplicate if the first two of the three segments were dropped AND the sender doesn't get a packet with the SACK option acknowledging the third segment.
  • two drops out of a four-segment window: there are six possible scenarios (we're not going through all of them here, bestie). depending on where the drops land, without SACK the sender might send one duplicate segment. there are NO scenarios where it sends two duplicates.
  • three drops out of a four-segment window: without SACK, one duplicate segment might get sent, depending on where the dropped segments are.

the summary? without SACK, there are some multiple-drop scenarios in the initial window where ONE duplicate segment gets transmitted. there are no scenarios where MORE than one duplicate gets transmitted. so our conclusion is that the number of duplicate segments caused by a larger initial window should be small 🌸 that's a W for the bigger window ✨

okay legal era, but make it cute 🎀 this is the official copyright stuff, and all the details are kept

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

so, you're allowed to copy this document and share it with others 💖 you can also write derivative works that comment on or explain it, or that help with implementing it, and publish and distribute those in whole or in part with no real restrictions. the one condition: the above copyright notice and this paragraph have to be included on all copies and derivative works.

BUT the document itself can't be modified in any way. that includes removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are: developing Internet standards (in which case the copyright procedures defined in the Internet Standards process must be followed), or translating it into languages other than English. 🌈

those permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them ⭐

the disclaimer, verbatim because it's important 🙈

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
📦 where this page comes from