As per Relevance of the word increase, we have this rfc below:
Network Working Group K.
Request for Comments: 2415 K.
Catetgory: Informational Bay
September 1998
Simulation Studies of Increased Initial TCP Window
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
An increase in the permissible initial window size of a
connection, from one segment to three or four segments, has
under discussion in the tcp-impl working group. This document
some simulation studies of the effects of increasing the
window size of TCP. Both long-lived TCP connections (file transfers
and short-lived web-browsing style connections were modeled.
simulations were performed using the publicly available ns-2
simulator and our custom models and files are also available
1.
We present results from a set of simulations with increased
initial window (IW). The main objectives were to explore
conditions under which the larger IW was a "win" and to determine
effects, if any, the larger IW might have on other traffic
using an IW of one segment
This study was inspired by discussions at the Munich IETF tcp-
and tcp-sat meetings. A proposal to increase the IW size to about 4
bytes (4380 bytes in the case of 1460 byte segments) was discussed
Concerns about both the utility of the increase and its effect
other traffic were raised. Some studies were presented showing
positive effects of increased IW on individual connections, but
studies were shown with a wide variety of simultaneous traffic flows
It appeared that some of the questions being raised could
addressed in an ns-2 simulation. Early results from our
were previously posted to the tcp-impl mailing list and presented
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
We simulated a network topology with a bottleneck link as shown
10Mb, 10Mb
(all 4 links) (all 4 links
C n2_________ ______ n6
l n3_________\ /______ n7
i \\ 1.5Mb, 50ms //
e n0 ------------------------ n1
n n4__________// \ \_____ n8
t n5__________/ \______ n9
s
URLs --> <--- FTP & Web
File downloading and web-browsing clients are attached to the
(n2-n5) on the left-hand side. These clients are served by the
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
is between n1 and n0. All links are bi-directional, but only ACKs
SYNs, FINs, and URLs are flowing from left to right. Some
were also performed with data traffic flowing from right to
simultaneously, but it had no effect on the results
In the simulations we assumed that all ftps transferred 1-MB
and that all web pages had exactly three embedded URLs. The
clients are browsing quite aggressively, requesting a new page
a random delay uniformly distributed between 1 and 5 seconds. This
not meant to realistically model a single user's web-
pattern, but to create a reasonably heavy traffic load
individual tcp connections accurately reflect real web traffic.
discussion of these models as used in earlier studies is available
references [3] and [4].
The maximum tcp window was set to 11 packets, maximum packet (
segment) size to 1460 bytes, and buffer sizes were set at 25 packets
(The ns-2 TCPs require setting window sizes and buffer sizes
number of packets. In our tcp-full code some of the
parameters have been set to be byte-oriented, but external
must still be set in number of packets.) In our simulations,
varied the number of data segments sent into a new TCP connection (
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
"application" class and three application client-server pairs
written: a simple file transfer (ftp), a model of http1.0 style
connection and a very rough model of http1.1 style web connection
The required files and scripts for these simulations are
under the contributed code section on the ns-simulator web page
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
clients ranging from 0 to 3. The IW was varied from 1 to 4,
the 4-packet case lies beyond what is currently recommended.
figures of merit used were goodput, the median page delay seen by
web clients and the median file transfer delay seen by the
clients. The simulated run time was rather large, 360 seconds,
ensure an adequate sample. (Median values remained the same
simulations with larger run times and can be considered stable
3.
In our simulations, we varied the number of file transfer clients
order to change the congestion of the link. Recall that our
clients continuously request 1 Mbyte transfers, so the
utilization is over 90% when even a single ftp client is present
When three file transfer clients are running simultaneously,
resultant congestion is somewhat pathological, making the
recorded stable. Though all connections use the same initial window
the effect of increasing the IW on a 1 Mbyte file transfer is
detectable, thus we focus on the web browsing connections. (In
tables, we use "webs" to indicate number of web clients and "ftps"
indicate the number of file transfer clients attached.) Table 1
the median delays experienced by the web transfers with an
in the TCP IW. There is clearly an improvement in transfer
for the web connections with increase in the IW, in many cases on
order of 30%. The steepness of the performance improvement
from an IW of 1 to an IW of 2 is mainly due to the distribution
files fetched by each URL (see references [1] and [2]); the
size of both primary and in-line URLs fits completely into
packets. If file distributions change, the shape of this curve
also change
Poduri & Nichols Informational [Page 3]
RFC 2415 TCP Window Size September 1998
Table 1. Median web page
#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
percentage of the same experiment. Packet drop rates did
with IW, but in all cases except that of the single most
overload, the increase in drop percentage was less than 1%.
decrease in packet drop percentage is observed in some
situations, specifically when ftp transfers consumed most of the
bandwidth and a large number of web transfers shared the
bandwidth of the link. In this case, the web transfers
severe packet loss and some of the IW=4 web clients suffer
packet losses from the same window, resulting in longer
times than when there is a single packet loss in a window. During
recovery time, the connections are inactive which
congestion and thus results in a decrease in the packet
percentage. It should be noted that such observations were made
in extremely overloaded scenarios
Poduri & Nichols Informational [Page 4]
RFC 2415 TCP Window Size September 1998
Table 2. Link utilization and packet drop
Percentage Link Utilization | Packet drop
#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
network power, goodput divided by median delay (in Mbytes/ms),
plotted it against IW for all scenarios. (Each scenario is
identified by its number of webs and number of file transfers.)
plot these values in Figure 1 (in the pdf version), illustrating
general advantage to increasing IW. When a large number of
clients is combined with ftps, particularly multiple ftps
pathological cases result from the extreme congestion. In
cases, there appears to be no particular trend to the results
increasing the IW, in fact simulation results are not
stable
To get a clearer picture of what is happening across all the
scenarios, we normalized the network power values for the non
pathological scenario by the network power for that scenario at IW
one. These results are plotted in Figure 2. As IW is increased
one to four, network power increased by at least 15%, even in
congested scenario dominated by bulk transfer traffic. In
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
to an increase in throughput and a decrease in the delay. Since
(slightly) increased drop rates were accompanied by
performance, drop rate is clearly not an indicator of user
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
against the performance the file transfers are seeing. We
ftp network power and show this in Table 3. It appears that
improvement in network power seen by the web connections
negligible effect on the concurrent file transfers. It can
observed from the table that there is a small variation in
network power of file transfers with an increase in the size of
but no particular trend can be seen. It can be concluded that
network power of file transfers essentially remained the same
However, it should be noted that a larger IW does allow web
to gain slightly more bandwidth than with a smaller IW. This
mean fewer bytes transferred for FTP applications or a
decrease in network power as computed by us
Table 3. Network power of file transfers with an increase in the
IW
#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,
natural question is to ask how results are affected by migration
http1.1. A rough model of this behavior was simulated by using
connection to send all of the information from both the primary
and the three embedded, or in-line, URLs. Since the transfer size
now made up of four web files, the steep improvement in
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
power owing to a non-increase or a slight decrease in the throughput
TCP connections opening up with a higher window size into a
congested network might experience some packet drops and
a slight decrease in the throughput. This indicates that increase
the initial window sizes to further higher values (>4) may not
result in a favorable network performance. This can be seen
in Figure 4 where the network power shows a decrease for the
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
TCP IW
#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
web-browsing connections with IWs of one with those using IWs
three. In this experiment, we first simulated a total of 16 web
browsing connections, all using IW of one. Then the clients
split into two groups of 8 each, one of which uses IW=1 and the
used IW=3.
We repeated the simulations for a total of 32 and 64 web-
clients, splitting those into groups of 16 and 32 respectively.
6 shows these results. We report the goodput (in Mbytes), the
page delays (in milli seconds), the percent utilization of the
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
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
------------------|-------------------|---------------|---------------
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
earlier results, clients with IW=3 outperform clients with IW=1.
results of running the 8/8 and 16/16 splits show that running
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
IW=3 are adversely affected. We believe this is due to
pathological dynamics of this extremely congested scenario.
embedded URLs open their connections simultaneously, very
number of TCP connections are arriving at the bottleneck
resulting in multiple packet losses for the IW=3 conversations.
myriad problems of this simultaneous opening strategy is, of course
part of the motivation for the development of http1.1.
4.
The indications from these results are that increasing the
window size to 3 packets (or 4380 bytes) helps to improve
performance. Many further variations on these simulation
are possible and we've made our simulation models and
available in order to facilitate others' experiments
We also used the RED queue management included with ns-2 to
some other simulation studies. We have not reported on those
here since we don't consider the studies complete. We found that
adding RED to the bottleneck link, we achieved similar
gains (with an IW of 1) to those we found with increased IWs
RED. Others may wish to investigate this further
Although the simulation sets were run for a T1 link,
scenarios with varying levels of congestion and varying number of
and ftp clients were analyzed. It is reasonable to expect that
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
some other simulation studies. We have not reported on those
here since we don't consider the studies complete. We found that
adding RED to the bottleneck link, we achieved similar
gains (with an IW of 1) to those we found with increased IWs
RED. Others may wish to investigate this further
5.
[1] B. Mah, "An Empirical Model of HTTP Network Traffic",
of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
[2] C.R. Cunha, A. Bestavros, M.E. Crovella, "Characteristics of
Client-based Traces", Boston University Computer
Technical Report BU-CS-95-010, July 18, 1995.
[3] K.M. Nichols and M. Laubach, "Tiers of Service for Data Access
a HFC Architecture", Proceedings of SCTE Convergence Conference
January, 1997.
[4] K.M. Nichols, "Improving Network Simulation with Feedback",
available from knichols@baynetworks.
6.
This work benefited from discussions with and comments from
Jacobson
7. Security
This document discusses a simulation study of the effects of
proposed change to TCP. Consequently, there are no
considerations directly related to the document. There are also
known security considerations associated with the proposed change
Poduri & Nichols Informational [Page 9]
RFC 2415 TCP Window Size September 1998
8. Authors'
Kedarnath
Bay
4401 Great America
SC01-04
Santa Clara, CA 95052-8185
Phone: +1-408-495-2463
Fax: +1-408-495-1299
EMail: kpoduri@Baynetworks.
Kathleen
Bay
4401 Great America
SC01-04
Santa Clara, CA 95052-8185
EMail: knichols@baynetworks.
Poduri & Nichols Informational [Page 10]
RFC 2415 TCP Window Size September 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Poduri & Nichols Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
