home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group K. Poduri
- Request for Comments: 2415 K. Nichols
- Category: Informational Bay Networks
- September 1998
-
-
- Simulation Studies of Increased Initial TCP Window Size
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- Abstract
-
- An increase in the permissible initial window size of a TCP
- connection, from one segment to three or four segments, has been
- under discussion in the tcp-impl working group. This document covers
- some simulation studies of the effects of increasing the initial
- window size of TCP. Both long-lived TCP connections (file transfers)
- and short-lived web-browsing style connections were modeled. The
- simulations were performed using the publicly available ns-2
- simulator and our custom models and files are also available.
-
- 1. Introduction
-
- We present results from a set of simulations with increased TCP
- initial window (IW). The main objectives were to explore the
- conditions under which the larger IW was a "win" and to determine the
- effects, if any, the larger IW might have on other traffic flows
- using an IW of one segment.
-
- This study was inspired by discussions at the Munich IETF tcp-impl
- and tcp-sat meetings. A proposal to increase the IW size to about 4K
- bytes (4380 bytes in the case of 1460 byte segments) was discussed.
- Concerns about both the utility of the increase and its effect on
- other traffic were raised. Some studies were presented showing the
- positive effects of increased IW on individual connections, but no
- studies were shown with a wide variety of simultaneous traffic flows.
- It appeared that some of the questions being raised could be
- addressed in an ns-2 simulation. Early results from our simulations
- were previously posted to the tcp-impl mailing list and presented at
- the tcp-impl WG meeting at the December 1997 IETF.
-
-
-
- Poduri & Nichols Informational [Page 1]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 2. Model and Assumptions
-
- We simulated a network topology with a bottleneck link as shown:
-
- 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 data
-
- File downloading and web-browsing clients are attached to the nodes
- (n2-n5) on the left-hand side. These clients are served by the FTP
- and Web servers attached to the nodes (n6-n9) on the right-hand side.
- The links to and from those nodes are at 10 Mbps. The bottleneck link
- is between n1 and n0. All links are bi-directional, but only ACKs,
- SYNs, FINs, and URLs are flowing from left to right. Some simulations
- were also performed with data traffic flowing from right to left
- simultaneously, but it had no effect on the results.
-
- In the simulations we assumed that all ftps transferred 1-MB files
- and that all web pages had exactly three embedded URLs. The web
- clients are browsing quite aggressively, requesting a new page after
- a random delay uniformly distributed between 1 and 5 seconds. This is
- not meant to realistically model a single user's web-browsing
- pattern, but to create a reasonably heavy traffic load whose
- individual tcp connections accurately reflect real web traffic. Some
- discussion of these models as used in earlier studies is available in
- references [3] and [4].
-
- The maximum tcp window was set to 11 packets, maximum packet (or
- segment) size to 1460 bytes, and buffer sizes were set at 25 packets.
- (The ns-2 TCPs require setting window sizes and buffer sizes in
- number of packets. In our tcp-full code some of the internal
- parameters have been set to be byte-oriented, but external values
- must still be set in number of packets.) In our simulations, we
- varied the number of data segments sent into a new TCP connection (or
- initial window) from one to four, keeping all segments at 1460 bytes.
- A dropped packet causes a restart window of one segment to be used,
- just as in current practice.
-
-
-
-
-
- Poduri & Nichols Informational [Page 2]
-
- RFC 2415 TCP Window Size September 1998
-
-
- For ns-2 users: The tcp-full code was 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 for these simulations are available
- under the contributed code section on the ns-simulator web page at
- the sites ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} or http://www-
- nrg.ee.lbl.gov/floyd/tcp_init_win.html.
-
- Simulations were run 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 used 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 rather large, 360 seconds, to
- ensure an adequate sample. (Median values remained the same for
- simulations with larger run times and can be considered stable)
-
- 3. Results
-
- In our simulations, we varied the number of file transfer clients in
- order to change the congestion of the link. Recall that our ftp
- clients continuously request 1 Mbyte transfers, so the link
- utilization is over 90% when even a single ftp client is present.
- When three file transfer clients are running simultaneously, the
- resultant congestion is somewhat pathological, making the values
- recorded stable. Though all connections use the same initial window,
- the effect of increasing the IW on a 1 Mbyte file transfer is not
- detectable, thus we focus on the web browsing connections. (In the
- tables, we use "webs" to indicate number of web clients and "ftps" to
- indicate the number of file transfer clients attached.) Table 1 shows
- the median delays experienced by the web transfers with an increase
- in the TCP IW. There is clearly an improvement in transfer delays
- for the web connections with increase in the IW, in many cases on the
- order of 30%. The steepness of the performance improvement going
- from an IW of 1 to an IW of 2 is mainly due to the distribution of
- files fetched by each URL (see references [1] and [2]); the median
- size of both primary and in-line URLs fits completely into two
- packets. If file distributions change, the shape of this curve may
- also change.
-
-
-
-
-
-
-
-
-
-
-
- Poduri & Nichols Informational [Page 3]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 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.3
-
- Table 2 shows the bottleneck link utilization and packet drop
- percentage of the same experiment. Packet drop rates did increase
- with IW, but in all cases except that of the single most pathological
- overload, the increase in drop percentage was less than 1%. A
- decrease in packet drop percentage is observed in some overloaded
- situations, specifically when ftp transfers consumed most of the link
- bandwidth and a large number of web transfers shared the remaining
- bandwidth of the link. In this case, the web transfers experience
- severe packet loss and some of the IW=4 web clients suffer multiple
- packet losses from the same window, resulting in longer recovery
- times than when there is a single packet loss in a window. During the
- recovery time, the connections are inactive which alleviates
- congestion and thus results in a decrease in the packet drop
- percentage. It should be noted that such observations were made only
- in extremely overloaded scenarios.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Poduri & Nichols Informational [Page 4]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 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.9
- -----------------------------------------------------------------------
- 32 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, goodput divided by median delay (in Mbytes/ms), and
- plotted it against IW for all scenarios. (Each scenario is uniquely
- identified by its number of webs and number of file transfers.) We
- plot these values in Figure 1 (in the pdf version), illustrating a
- general advantage to increasing IW. When a large number of web
- clients is combined with ftps, particularly multiple ftps,
- pathological cases result from the extreme congestion. In these
- cases, there appears to be no particular trend to the results of
- increasing the IW, in fact simulation results are not particularly
- stable.
-
- To get a clearer picture of what is happening across all the tested
- scenarios, we normalized the network power values for the non-
- pathological scenario by the network power for that scenario at IW of
- one. These results are plotted in Figure 2. As IW is increased 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 is due
- to an increase in throughput and a decrease in the delay. Since the
- (slightly) increased drop rates were accompanied by better
- performance, drop rate is clearly not an indicator of user level
- performance.
-
-
-
-
-
- Poduri & Nichols Informational [Page 5]
-
- RFC 2415 TCP Window Size September 1998
-
-
- The gains in performance seen by the web clients need to be balanced
- against the performance the file transfers are seeing. We computed
- ftp network power and show this in Table 3. It appears that the
- improvement in network power seen by the web connections has
- negligible effect on the concurrent file transfers. It can be
- observed from the table that there is a small variation in the
- network power of file transfers with an increase in the size of IW
- but no particular trend can be seen. It can be concluded that the
- network power of file transfers essentially remained the same.
- However, it should be noted that a larger IW does allow web transfers
- to gain slightly more bandwidth than with a smaller IW. This could
- mean fewer bytes transferred for FTP applications or a slight
- decrease in network power as computed by us.
-
- 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.0
-
- The above simulations all used http1.0 style web connections, thus, a
- natural question is to ask how results are affected by migration to
- http1.1. A rough model of this behavior was simulated by using one
- connection to send all of the information from both the primary URL
- and the three embedded, or in-line, URLs. Since the transfer size is
- now made up of four web files, the steep improvement in performance
- between an IW of 1 and an IW of two, noted in the previous results,
- has been smoothed. Results are shown in Tables 4 & 5 and Figs. 3 & 4.
- Occasionally an increase in IW from 3 to 4 decreases the network
- power owing to a non-increase or a slight decrease in the throughput.
- TCP connections opening up with a higher window size into a very
- congested network might experience some packet drops and consequently
- a slight decrease in the throughput. This indicates that increase of
- the initial window sizes to further higher values (>4) may not always
- result in a favorable network performance. This can be seen clearly
- in Figure 4 where the network power shows a decrease for the two
- highly congested cases.
-
-
-
-
-
- Poduri & Nichols Informational [Page 6]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 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.0
-
-
- Table 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.5
-
- For further insight, we returned to the http1.0 model and mixed some
- web-browsing connections with 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 of which uses IW=1 and the other
- used IW=3.
-
- We repeated the simulations for a total of 32 and 64 web-browsing
- clients, splitting those 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.
-
-
-
-
-
- Poduri & Nichols Informational [Page 7]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 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 are consistent with our
- earlier results, clients with IW=3 outperform clients with IW=1. The
- results of running the 8/8 and 16/16 splits show that running a
- mixture of IW=3 and IW=1 has no negative effect on the IW=1
- conversations, while IW=3 conversations maintain their performance.
- However, the 32/32 split shows that web-browsing connections with
- IW=3 are adversely affected. We believe this is due to the
- pathological dynamics of this extremely congested scenario. Since
- embedded URLs open their connections simultaneously, very large
- number of TCP connections are arriving at the bottleneck link
- resulting in multiple packet losses for the IW=3 conversations. The
- myriad problems of this simultaneous opening strategy is, of course,
- part of the motivation for the development of http1.1.
-
- 4. Discussion
-
- The indications from these results are that increasing the initial
- window size to 3 packets (or 4380 bytes) helps to improve perceived
- performance. Many further variations on these simulation scenarios
- are possible and we've made our simulation models and scripts
- available in order to facilitate others' experiments.
-
- We also used the RED queue management included with ns-2 to perform
- some other simulation studies. We have not reported on those results
- here since we don't consider the studies complete. We found that by
- adding RED to the bottleneck link, we achieved similar performance
- gains (with an IW of 1) to those we found with increased IWs without
- RED. Others may wish to investigate this further.
-
- Although the simulation sets were run for a T1 link, several
- scenarios with varying levels of congestion and varying number of web
- and ftp clients were analyzed. It is reasonable to expect that the
- results would scale for links with higher bandwidth. However,
-
-
-
- Poduri & Nichols Informational [Page 8]
-
- RFC 2415 TCP Window Size September 1998
-
-
- interested readers could investigate this aspect further.
-
- We also used the RED queue management included with ns-2 to perform
- some other simulation studies. We have not reported on those results
- here since we don't consider the studies complete. We found that by
- adding RED to the bottleneck link, we achieved similar performance
- gains (with an IW of 1) to those we found with increased IWs without
- RED. Others may wish to investigate 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Poduri & Nichols Informational [Page 9]
-
- RFC 2415 TCP Window Size September 1998
-
-
- 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.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Poduri & Nichols Informational [Page 10]
-
- RFC 2415 TCP Window Size September 1998
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Poduri & Nichols Informational [Page 11]
-
-