|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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] |
|
|
|
|
|
|
