RFC 2415
Simulation Studies of Increased Initial TCP Window Size
RFC 2415: Simulation Studies of Increased Initial TCP Window Size 🎀
okay bestie, title block first 💅 This one is from K. Poduri and K. Nichols, both at Bay Networks, dated September 1998. It's Informational 🌸, so it's sharing research and findings, not setting a standard. It doesn't list anything it obsoletes or updates.
Status of This Memo
this memo gives info to the Internet community 🧚 it does NOT specify an Internet standard of any kind. distribution is unlimited, so share away!
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒
Abstract
okay so the big question here is whether a TCP connection should be allowed to start with a bigger initial window, going from one segment up to three or four segments 👀 it's been a hot topic in the tcp-impl working group. this doc covers simulation studies of what happens when you increase the initial window of TCP. both long-lived connections (file transfers) and short-lived web-browsing style connections got modeled 💖 everything ran on the publicly available ns-2 simulator, and the custom models and files are available too ✨
1. Introduction
so here's the tea 🫖 we ran a bunch of simulations with a bigger TCP initial window (IW). the main goals were to find out when the larger IW was a "win" and whether it messed with other traffic that was still using an IW of one segment 🧐
this study was inspired by chats at the Munich IETF tcp-impl and tcp-sat meetings. someone proposed bumping the IW to about 4K bytes (4380 bytes with 1460 byte segments) 🍓 people raised concerns about both whether it was useful and how it would affect everyone else. some studies showed the good effects on single connections, but nobody had shown results with a wide mix of traffic flowing at once 😭 that's where our ns-2 sims came in. early results got posted to the tcp-impl mailing list and presented at the tcp-impl WG meeting at the December 1997 IETF 🦋
2. Model and Assumptions
we simulated a network topology with a bottleneck link, and it looks like this 👑
10Mb, 10Mb,
(all 4 links) (all 4 links)
C n2_________ ______ n6 S
l n3_________\ /______ n7 e
i \\ 1.5Mb, 50ms // r
e n0 ------------------------ n1 v
n n4__________// \ \_____ n8 e
t n5__________/ \______ n9 r
s s
URLs --> <--- FTP & Web dataso the file downloading and web-browsing clients are hanging out on the nodes n2-n5 on the left side 🧚 they get served by the FTP and Web servers on the nodes n6-n9 on the right side. the links to and from those nodes are at 10 Mbps 💅 the bottleneck is between n1 and n0. all links are bi-directional, but only ACKs, SYNs, FINs, and URLs flow from left to right. we also ran some sims with data going right to left at the same time, and it had no effect on the results 🙈
in the sims we assumed all ftps grabbed 1-MB files, and every web page had exactly three embedded URLs 🌈 the web clients browse pretty aggressively, requesting a new page after a random delay uniformly distributed between 1 and 5 seconds. this isn't meant to be a realistic model of one person browsing, lowkey. it's meant to make a pretty heavy traffic load where each TCP connection still looks like real web traffic ✨ you can read more about these models used in earlier studies in references [3] and [4] 📚
the maximum TCP window was set to 11 packets, the maximum packet (or segment) size to 1460 bytes, and the buffer sizes to 25 packets 🎀 (the ns-2 TCPs need window and buffer sizes set in number of packets. in our tcp-full code some internal parameters are byte-oriented, but the external values still have to be in packets.) in our sims we varied the number of data segments sent into a new TCP connection (the initial window) from one to four, keeping every segment at 1460 bytes. a dropped packet causes a restart window of one segment to be used, just like in current practice 💖
for ns-2 users: the tcp-full code got modified to use an "application" class, and three application client-server pairs were written: a simple file transfer (ftp), a model of http1.0 style web connection, and a very rough model of http1.1 style web connection 🫶 the required files and scripts are under the contributed code section on the ns-simulator web page, at ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} or http://www-nrg.ee.lbl.gov/floyd/tcp_init_win.html 🍓
we ran sims with 8, 16, 32 web clients and a number of ftp clients ranging from 0 to 3 🔥 the IW was varied from 1 to 4, though the 4-packet case lies beyond what is currently recommended 👀 the figures of merit were goodput, the median page delay seen by the web clients, and the median file transfer delay seen by the ftp clients. the simulated run time was 360 seconds (kinda long, but it makes sure we get a solid sample). median values stayed the same for longer runs too, so they're stable 🧠✨
3. Results
okay so the ftp clients were the knob we turned to change how congested the link was 🎛️ remember, our ftp clients keep requesting 1 Mbyte transfers, so link utilization is over 90% as soon as even one ftp client is around. with three file transfer clients running at once, the congestion gets kinda pathological, but the recorded values are stable 💀 even though all connections use the same initial window, the effect of a bigger IW on a 1 Mbyte file transfer isn't detectable, so we focus on the web browsing connections 🙈 (in the tables, "webs" means the number of web clients and "ftps" means the number of file transfer clients.)
Table 1 shows the median delays the web transfers experienced as the TCP IW went up. there's clearly an improvement in web transfer delays as the IW increases, in many cases on the order of 30% 🎉 the big jump going from an IW of 1 to an IW of 2 is mainly because of the distribution of files each URL fetches (see references [1] and [2]). the median size of both primary and in-line URLs fits completely into two packets 💅 if file distributions change, this curve's shape might change too.
Table 1. Median web page delay
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
(s) (% decrease)
----------------------------------------------
8 0 0.56 14.3 17.9 16.1
8 1 1.06 18.9 25.5 32.1
8 2 1.18 16.1 17.1 28.9
8 3 1.26 11.9 19.0 27.0
16 0 0.64 11.0 15.6 18.8
16 1 1.04 17.3 24.0 35.6
16 2 1.22 17.2 20.5 25.4
16 3 1.31 10.7 21.4 22.1
32 0 0.92 17.6 28.6 21.0
32 1 1.19 19.6 25.0 26.1
32 2 1.43 23.8 35.0 33.6
32 3 1.56 19.2 29.5 33.3Table 2 shows the bottleneck link utilization and packet drop percentage from the same experiment 📊 packet drop rates did go up with IW, but in every case except the single most pathological overload, the increase in drop percentage was less than 1% 😤 a decrease in drop percentage shows up in some overloaded situations, specifically when ftp transfers ate most of the link bandwidth and a big pile of web transfers shared what was left 🍿 in that case, the web transfers get hit with severe packet loss, and some of the IW=4 web clients suffer multiple packet losses from the same window. that means longer recovery times than when there's only a single packet loss in a window 🥲 during recovery the connections are inactive, which eases congestion and so the packet drop percentage goes down. just know these observations only showed up in extremely overloaded scenarios ⚠️
Table 2. Link utilization and packet drop rates
Percentage Link Utilization | Packet drop rate
#Webs #FTPs IW=1 IW=2 IW=3 IW=4 |IW=1 IW=2 IW=3 IW=4
-----------------------------------------------------------------------
8 0 34 37 38 39 | 0.0 0.0 0.0 0.0
8 1 95 92 93 92 | 0.6 1.2 1.4 1.3
8 2 98 97 97 96 | 1.8 2.3 2.3 2.7
8 3 98 98 98 98 | 2.6 3.0 3.5 3.5
-----------------------------------------------------------------------
16 0 67 69 69 67 | 0.1 0.5 0.8 1.0
16 1 96 95 93 92 | 2.1 2.6 2.9 2.9
16 2 98 98 97 96 | 3.5 3.6 4.2 4.5
16 3 99 99 98 98 | 4.5 4.7 5.2 4.932 0 92 87 85 84 | 0.1 0.5 0.8 1.0 32 1 98 97 96 96 | 2.1 2.6 2.9 2.9 32 2 99 99 98 98 | 3.5 3.6 4.2 4.5 32 3 100 99 99 98 | 9.3 8.4 7.7 7.6
To get a more complete picture of performance, we computed the network power, which is goodput divided by median delay (in Mbytes/ms). We plotted it against IW for all scenarios. (Each scenario is uniquely identified by its number of webs and number of file transfers.) These values are in Figure 1 (in the pdf version), and they show a general advantage to increasing IW 📈💖. When a large number of web clients is combined with ftps, particularly multiple ftps, things get pathological 💀 because of the extreme congestion. In those cases there's no real trend when you increase the IW, and honestly the simulation results aren't very stable 🙈.
To get a clearer picture of what's happening across all the tested scenarios, we normalized the network power values for the non-pathological scenarios by the network power for that scenario at IW of one. These results are in Figure 2 ✨. As IW goes from one to four, network power increased by at least 15%, even in a congested scenario dominated by bulk transfer traffic 🔥. In simulations where web traffic has a dominant share of the available bandwidth, the increase in network power was up to 60% 👑.
The increase in network power at higher initial window sizes comes from an increase in throughput and a decrease in delay. Since the (slightly) increased drop rates came along with better performance, drop rate is clearly not an indicator of user level performance 🦋.
The gains the web clients see need to be balanced against what the file transfers are getting. We computed ftp network power and show it in Table 3 🎀. It looks like the improvement in network power seen by the web connections has a negligible effect on the concurrent file transfers 🫶. You can see from the table that there's a small variation in the network power of file transfers as the size of IW grows, but no particular trend 🤷♀️. So it's fair to say that the network power of file transfers essentially stayed the same. Still, a larger IW does let web transfers grab slightly more bandwidth than a smaller IW, and ngl that's worth noting. This could mean fewer bytes transferred for FTP applications, or a slight decrease in network power as we computed it 🥺.
Table 3. Network power of file transfers with an increase in the TCP IW size
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
--------------------------------------------
8 1 4.7 4.2 4.2 4.2
8 2 3.0 2.8 3.0 2.8
8 3 2.2 2.2 2.2 2.2
16 1 2.3 2.4 2.4 2.5
16 2 1.8 2.0 1.8 1.9
16 3 1.4 1.6 1.5 1.7
32 1 0.7 0.9 1.3 0.9
32 2 0.8 1.0 1.3 1.1
32 3 0.7 1.0 1.2 1.0The simulations above all used http1.0 style web connections, so the natural next question is how things change when we move to http1.1 🌸. We simulated a rough model of this behavior by using one connection to send all the information from both the primary URL and the three embedded, or in-line, URLs. Since the transfer is now made up of four web files, the steep improvement between an IW of 1 and an IW of two (from the earlier results) gets smoothed out 🧚. The results are in Tables 4 & 5 and Figs. 3 & 4. Sometimes going from IW 3 to 4 actually decreases the network power 😭, because of a non-increase or a slight decrease in throughput. TCP connections opening with a higher window size into a very congested network might hit some packet drops and, as a result, a slight decrease in throughput. This suggests that increasing the initial window sizes to even higher values (>4) may not always give a favorable network performance 💅. You can see this clearly in Figure 4, where network power drops for the two highly congested cases.
Table 4. Median web page delay for http1.1
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
(s) (% decrease)
----------------------------------------------
8 0 0.47 14.9 19.1 21.3
8 1 0.84 17.9 19.0 25.0
8 2 0.99 11.5 17.3 23.0
8 3 1.04 12.1 20.2 28.3
16 0 0.54 07.4 14.8 20.4
16 1 0.89 14.6 21.3 27.0
16 2 1.02 14.7 19.6 25.5
16 3 1.11 09.0 17.0 18.9
32 0 0.94 16.0 29.8 36.2
32 1 1.23 12.2 28.5 21.1
32 2 1.39 06.5 13.7 12.2
32 3 1.46 04.0 11.0 15.0Table 5. Network power of file transfers with an increase in the TCP IW size
#Webs #FTPs IW=1 IW=2 IW=3 IW=4
--------------------------------------------
8 1 4.2 4.2 4.2 3.7
8 2 2.7 2.5 2.6 2.3
8 3 2.1 1.9 2.0 2.0
16 1 1.8 1.8 1.5 1.4
16 2 1.5 1.2 1.1 1.5
16 3 1.0 1.0 1.0 1.0
32 1 0.3 0.3 0.5 0.3
32 2 0.4 0.3 0.4 0.4
32 3 0.4 0.3 0.4 0.5For further insight, we went back to the http1.0 model and mixed some web-browsing connections using IWs of one with those using IWs of three 🍓. In this experiment, we first simulated a total of 16 web-browsing connections, all using IW of one. Then the clients were split into two groups of 8 each: one group used IW=1 and the other used IW=3.
We repeated the simulations for a total of 32 and 64 web-browsing clients, split into groups of 16 and 32 respectively. Table 6 shows these results. We report the goodput (in Mbytes), the web page delays (in milli seconds), the percent utilization of the link, and the percent of packets dropped 📊.
Table 6. Results for half-and-half scenario
Median Page Delays and Goodput (MB) | Link Utilization (%) & Drops (%)
#Webs IW=1 | IW=3 | IW=1 | IW=3
G.put dly | G.put dly | L.util Drops| L.util Drops
------------------|-------------------|---------------|---------------
16 35.5 0.64| 36.4 0.54 | 67 0.1 | 69 0.7
8/8 16.9 0.67| 18.9 0.52 | 68 0.5 |
------------------|-------------------|---------------|---------------
32 48.9 0.91| 44.7 0.68 | 92 3.5 | 85 4.3
16/16 22.8 0.94| 22.9 0.71 | 89 4.6 |
------------------|-------------------|---------------|----------------
64 51.9 1.50| 47.6 0.86 | 98 13.0 | 91 8.6
32/32 29.0 1.40| 22.0 1.20 | 98 12.0 |Unsurprisingly, the non-split experiments match our earlier results: clients with IW=3 outperform clients with IW=1 💅. Running the 8/8 and 16/16 splits shows that a mix of IW=3 and IW=1 has no negative effect on the IW=1 conversations, while the IW=3 conversations keep their performance 🫶. The 32/32 split is where it gets messy, though 😬. Web-browsing connections with IW=3 are adversely affected there. We believe this is due to the pathological dynamics of this extremely congested scenario. Since embedded URLs open their connections simultaneously, a very large number of TCP connections arrive at the bottleneck link, and that causes multiple packet losses for the IW=3 conversations. The myriad problems of this simultaneous opening strategy are, of course, part of the motivation for developing http1.1. 🧚♀️
4. Discussion ✨
The indications from these results are that increasing the initial window size to 3 packets (or 4380 bytes) helps improve perceived performance 🌈. There are many further variations on these simulation scenarios, and we've made our simulation models and scripts available so that others can run their own experiments 🎀.
We also used the RED queue management included with ns-2 to run some other simulation studies. We haven't reported those results here since we don't consider the studies complete 🙈. We found that by adding RED to the bottleneck link, we got performance gains similar to those we found with increased IWs without RED (with an IW of 1). Others may want to look into this further 🔍.
Although the simulation sets were run for a T1 link, several scenarios with varying levels of congestion and varying numbers of web and ftp clients were analyzed. It's reasonable to expect the results would scale to links with higher bandwidth. Still, interested readers could investigate this aspect further 🚀.
We also used the RED queue management included with ns-2 to run some other simulation studies. We haven't reported those results here since we don't consider the studies complete 🙈. We found that by adding RED to the bottleneck link, we got performance gains similar to those we found with increased IWs without RED (with an IW of 1). Others may want to look into this further 🔍.
5. References 📚
[1] B. Mah, "An Empirical Model of HTTP Network Traffic", Proceedings of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
[2] C.R. Cunha, A. Bestavros, M.E. Crovella, "Characteristics of WWW Client-based Traces", Boston University Computer Science Technical Report BU-CS-95-010, July 18, 1995.
[3] K.M. Nichols and M. Laubach, "Tiers of Service for Data Access in a HFC Architecture", Proceedings of SCTE Convergence Conference, January, 1997.
[4] K.M. Nichols, "Improving Network Simulation with Feedback", available from knichols@baynetworks.com
6. Acknowledgements 🫶
This work benefited from discussions with and comments from Van Jacobson 💜.
7. Security Considerations 💀
This document discusses a simulation study of the effects of a proposed change to TCP. Consequently, there are no security considerations directly related to the document 🔒. There are also no known security considerations associated with the proposed change 🛡️.
8. Authors' Addresses 🎀
Kedarnath Poduri
Bay Networks
4401 Great America Parkway
SC01-04
Santa Clara, CA 95052-8185
Phone: +1-408-495-2463
Fax: +1-408-495-1299
EMail: kpoduri@Baynetworks.com
Kathleen Nichols
Bay Networks
4401 Great America Parkway
SC01-04
Santa Clara, CA 95052-8185
EMail: knichols@baynetworks.comFull Copyright Statement ✨
Okay bestie, the legal bit 📜💅. The Internet Society owns the copyright on this doc (1998), and all rights are reserved 🔒.
Here's the deal. You're allowed to copy this doc and share it with anyone 🫶. You can also make derivative works that comment on or explain it, or help people build with it 🛠️. You can publish and distribute those too, in whole or in part, with no restrictions of any kind 🎉. The one catch: the copyright notice and this paragraph have to stay on every copy and every derivative work 📌.
Now the big plot twist 😭. This document itself may not be modified in any way. You can't remove the copyright notice, and you can't scrub out references to the Internet Society or other Internet organizations 🙅♀️. The only exceptions are two. First, you can change it when it's needed for developing Internet standards, but then you have to follow the copyright procedures defined in the Internet Standards process 📚. Second, you can translate it into languages other than English 🌍.
The permissions above are perpetual, which means they never expire ♾️💖. The Internet Society and its successors or assigns can't take them back either 🙌.
⚠️ Disclaimer, bestie, please read this part 🥺: This document and the information in it are provided on an "AS IS" basis. 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
- ietf: rfc2415 1998-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms