As per Relevance of the word increase, we have this rfc below:
Network Working Group M.
Request for Comments: 2414 NASA Lewis/Sterling
Category: Experimental S.
C.
BBN
September 1998
Increasing TCP's Initial
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document specifies an increase in the permitted initial
for TCP from one segment to roughly 4K bytes. This
discusses the advantages and disadvantages of such a change
outlining experimental results that indicate the costs and
of such a change to TCP
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
1. TCP
This document specifies an increase in the permitted upper bound
TCP's initial window from one segment to between two and
segments. In most cases, this change results in an upper bound
the initial window of roughly 4K bytes (although given a
segment size, the permitted initial window of two segments could
significantly larger than 4K bytes). The upper bound for the
window is given more precisely in (1):
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
Allman, et. al. Experimental [Page 1]
RFC 2414 Increasing TCP's Initial Window September 1998
Equivalently, the upper bound for the initial window size is based
the maximum segment size (MSS), as follows
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
a larger initial window, not that it SHOULD
This upper bound for the initial window size represents a change
RFC 2001 [S97], which specifies that the congestion window
initialized to one segment. If implementation experience
successful, then the intent is for this change to be
into a revision to RFC 2001.
This change applies to the initial window of the connection in
first round trip time (RTT) of transmission following the TCP three
way handshake. Neither the SYN/ACK nor its acknowledgment (ACK)
the three-way handshake should increase the initial window size
that outlined in equation (1). If the SYN or SYN/ACK is lost,
initial window used by a sender after a correctly transmitted
MUST be one segment
TCP implementations use slow start in as many as three
ways: (1) to start a new connection (the initial window); (2)
restart a transmission after a long idle period (the restart window);
and (3) to restart after a retransmit timeout (the loss window).
change proposed in this document affects the value of the
window. Optionally, a TCP MAY set the restart window to the
of the value used for the initial window and the current value
cwnd (in other words, using a larger value for the restart
should never increase the size of cwnd). These changes do NOT
the loss window, which must remain 1 segment (to permit the
possible window size in the case of severe congestion).
2. Implementation
When larger initial windows are implemented along with Path
Discovery [MD90], and the MSS being used is found to be too large
the congestion window `cwnd' SHOULD be reduced to prevent
bursts of smaller segments. Specifically, `cwnd' SHOULD be
by the ratio of the old segment size to the new segment size
Allman, et. al. Experimental [Page 2]
RFC 2414 Increasing TCP's Initial Window September 1998
When larger initial windows are implemented along with Path
Discovery [MD90], alternatives are to set the "Don't Fragment" (DF
bit in all segments in the initial window, or to set the "Don'
Fragment" (DF) bit in one of the segments. It is an open
which of these two alternatives is best; we would hope
implementation experiences will shed light on this. In the
case of setting the DF bit in all segments, if the initial
are too large, then all of the initial packets will be dropped in
network. In the second case of setting the DF bit in only
segment, if the initial packets are too large, then all but one
the initial packets will be fragmented in the network. When
second case is followed, setting the DF bit in the last segment
the initial window provides the least chance for
retransmissions when the initial segment size is found to be
large, because it minimizes the chances of duplicate ACKs
a Fast Retransmit. However, more attention needs to be paid to
interaction between larger initial windows and Path MTU Discovery
The larger initial window proposed in this document is not
as an encouragement for web browsers to open multiple
TCP connections all with large initial windows. When web
open simultaneous TCP connections to the same destination, this
against TCP's congestion control mechanisms [FF98], regardless of
size of the initial window. Combining this behavior with
initial windows further increases the unfairness to other traffic
the network
3. Advantages of Larger Initial
1. When the initial window is one segment, a receiver
delayed ACKs [Bra89] is forced to wait for a timeout
generating an ACK. With an initial window of at least
segments, the receiver will generate an ACK after the second
segment arrives. This eliminates the wait on the timeout (
up to 200 msec).
2. For connections transmitting only a small amount of data,
larger initial window reduces the transmission time (assuming
most moderate segment drop rates). For many email (SMTP [Pos82])
and web page (HTTP [BLFN96, FJGFBL97]) transfers that are
than 4K bytes, the larger initial window would reduce the
transfer time to a single RTT
3. For connections that will be able to use large
windows, this modification eliminates up to three RTTs and
delayed ACK timeout during the initial slow-start phase.
Allman, et. al. Experimental [Page 3]
RFC 2414 Increasing TCP's Initial Window September 1998
would be of particular benefit for high-bandwidth large
propagation-delay TCP connections, such as those over
links
4. Disadvantages of Larger Initial Windows for the
In high-congestion environments, particularly for routers that have
bias against bursty traffic (as in the typical Drop Tail
queues), a TCP connection can sometimes be better off starting
an initial window of one segment. There are scenarios where a
connection slow-starting from an initial window of one segment
not have segments dropped, while a TCP connection starting with
initial window of four segments might experience
retransmits due to the inability of the router to handle
bursts. This could result in an unnecessary retransmit timeout.
a large-window connection that is able to recover without
retransmit timeout, this could result in an unnecessarily-
transition from the slow-start to the congestion-avoidance phase
the window increase algorithm. These premature segment drops
unlikely to occur in uncongested networks with sufficient
or in moderately-congested networks where the congested router
active queue management (such as Random Early Detection [FJ93,
RFC2309]).
Some TCP connections will receive better performance with the
initial window even if the burstiness of the initial window
in premature segment drops. This will be true if (1) the
connection recovers from the segment drop without a
timeout, and (2) the TCP connection is ultimately limited to a
congestion window by either network congestion or by the receiver'
advertised window
5. Disadvantages of Larger Initial Windows for the
In terms of the potential for congestion collapse, we consider
separate potential dangers for the network. The first danger
be a scenario where a large number of segments on congested
were duplicate segments that had already been received at
receiver. The second danger would be a scenario where a large
of segments on congested links were segments that would be
later in the network before reaching their final destination
In terms of the negative effect on other traffic in the network,
potential disadvantage of larger initial windows would be that
increase the general packet drop rate in the network. We
these three issues below
Allman, et. al. Experimental [Page 4]
RFC 2414 Increasing TCP's Initial Window September 1998
Duplicate segments
As described in the previous section, the larger initial
could occasionally result in a segment dropped from the
window, when that segment might not have been dropped if
sender had slow-started from an initial window of one segment
However, Appendix A shows that even in this case, the
initial window would not result in the transmission of a
number of duplicate segments
Segments dropped later in the network
How much would the larger initial window for TCP increase
number of segments on congested links that would be
before reaching their final destination? This is a problem
can only occur for connections with multiple congested links
where some segments might use scarce bandwidth on the
congested link along the path, only to be dropped later along
path
First, many of the TCP connections will have only one
link along the path. Segments dropped from these connections
not "waste" scarce bandwidth, and do not contribute to
collapse
However, some network paths will have multiple congested links
and segments dropped from the initial window could use
bandwidth along the earlier congested links before
being dropped on subsequent congested links. To the extent
the drop rate is independent of the initial window used by
segments, the problem of congested links carrying segments
will be dropped before reaching their destination will be
for TCP connections that start by sending four segments or
segment
An increased packet drop rate
For a network with a high segment drop rate, increasing the
initial window could increase the segment drop rate even further
This is in part because routers with Drop Tail queue
have difficulties with bursty traffic in times of congestion
However, given uncorrelated arrivals for TCP connections,
larger TCP initial window should not significantly increase
segment drop rate. Simulation-based explorations of these
are discussed in Section 7.2.
Allman, et. al. Experimental [Page 5]
RFC 2414 Increasing TCP's Initial Window September 1998
These potential dangers for the network are explored in
and experiments described in the section below. Our judgement
be, while there are dangers of congestion collapse in the
Internet (see [FF98] for a discussion of the dangers of
collapse from an increased deployment of UDP connections
end-to-end congestion control), there is no such danger to
network from increasing the TCP initial window to 4K bytes
6. Typical Levels of Burstiness for TCP Traffic
Larger TCP initial windows would not dramatically increase
burstiness of TCP traffic in the Internet today, because such
is already fairly bursty. Bursts of two and three segments
already typical of TCP [Flo97]; A delayed ACK (covering
previously unacknowledged segments) received during
avoidance causes the congestion window to slide and two segments
be sent. The same delayed ACK received during slow start causes
window to slide by two segments and then be incremented by
segment, resulting in a three-segment burst. While not
typical, bursts of four and five segments for TCP are not rare
Assuming delayed ACKs, a single dropped ACK causes the subsequent
to cover four previously unacknowledged segments. During
avoidance this leads to a four-segment burst and during slow start
five-segment burst is generated
There are also changes in progress that reduce the
problems posed by moderate traffic bursts. One such change is
deployment of higher-speed links in some parts of the network,
a burst of 4K bytes can represent a small quantity of data. A
change, for routers with sufficient buffering, is the deployment
queue management mechanisms such as RED, which is designed to
tolerant of transient traffic bursts
7. Simulations and Experimental
7.1 Studies of TCP Connections using that Larger Initial
This section surveys simulations and experiments that have been
to explore the effect of larger initial windows on the TCP
using that larger window. The first set of experiments
performance over satellite links. Larger initial windows have
shown to improve performance of TCP connections over
channels [All97b]. In this study, an initial window of four
(512 byte MSS) resulted in throughput improvements of up to 30%
(depending upon transfer size). [KAGT98] shows that the use
larger initial windows results in a decrease in transfer time in
tests over the ACTS satellite system. A study involving
Allman, et. al. Experimental [Page 6]
RFC 2414 Increasing TCP's Initial Window September 1998
of a large number of HTTP transactions over hybrid fiber coax (HFC
indicates that the use of larger initial windows decreases the
required to load WWW pages [Nic97].
A second set of experiments has explored TCP performance over
modem links. In experiments over a 28.8 bps dialup channel [All97a
AHO98], a four-segment initial window decreased the transfer time
a 16KB file by roughly 10%, with no accompanying increase in the
rate. A particular area of concern has been TCP performance over
speed tail circuits (e.g., dialup modem links) with routers
small buffers. A simulation study [SP97] investigated the effects
using a larger initial window on a host connected by a slow
link and a router with a 3 packet buffer. The study concluded
for the scenario investigated, the use of larger initial windows
not harmful to TCP performance. Questions have been
concerning the effects of larger initial windows on the transfer
for short transfers in this environment, but these effects have
been quantified. A question has also been raised concerning
possible effect on existing TCP connections sharing the link
7.2 Studies of Networks using Larger Initial
This section surveys simulations and experiments investigating
impact of the larger window on other TCP connections sharing
path. Experiments in [All97a, AHO98] show that for 16 KB
to 100 Internet hosts, four-segment initial windows resulted in
small increase in the drop rate of 0.04 segments/transfer. While
drop rate increased slightly, the transfer time was reduced
roughly 25% for transfers using the four-segment (512 byte MSS
initial window when compared to an initial window of one segment
One scenario of concern is heavily loaded links. For instance,
couple of years ago, one of the trans-Atlantic links was so
loaded that the correct congestion window size for a connection
about one segment. In this environment, new connections using
initial windows would be starting with windows that were four
too big. What would the effects be? Do connections thrash
A simulation study in [PN98] explores the impact of a larger
window on competing network traffic. In this investigation, HTTP
FTP flows share a single congested gateway (where the number of
and FTP flows varies from one simulation set to another). For
simulation set, the paper examines aggregate link utilization
packet drop rates, median web page delay, and network power for
FTP transfers. The larger initial window generally resulted
increased throughput, slightly-increased packet drop rates, and
increase in overall network power. With the exception of
scenario, the larger initial window resulted in an increase in
Allman, et. al. Experimental [Page 7]
RFC 2414 Increasing TCP's Initial Window September 1998
drop rate of less than 1% above the loss rate experienced when
a one-segment initial window; in this scenario, the drop
increased from 3.5% with one-segment initial windows, to 4.5%
four-segment initial windows. The overall conclusions were
increasing the TCP initial window to three packets (or 4380 bytes
helps to improve perceived performance
Morris [Mor97] investigated larger initial windows in a
congested network with transfers of size 20K. The loss rate
networks where all TCP connections use an initial window of
segments is shown to be 1-2% greater than in a network where
connections use an initial window of one segment. This
held in scenarios where the loss rates with one-segment
windows ranged from 1% to 11%. In addition, in networks
connections used an initial window of four segments, TCP
spent more time waiting for the retransmit timer (RTO) to expire
resend a segment than was spent when using an initial window of
segment. The time spent waiting for the RTO timer to
represents idle time when no useful work was being accomplished
that connection. These results show that in a very
environment, where each connection's share of the
bandwidth is close to one segment, using a larger initial window
cause a perceptible increase in both loss rates and
timeouts
8. Security
This document discusses the initial congestion window permitted
TCP connections. Changing this value does not raise any known
security issues with TCP
9.
This document proposes a small change to TCP that may be
to short-lived TCP connections and those over links with long
(saving several RTTs during the initial slow-start phase).
10.
We would like to acknowledge Vern Paxson, Tim Shepard, members of
End-to-End-Interest Mailing List, and members of the IETF
Implementation Working Group for continuing discussions of
issues for discussions and feedback on this document
Allman, et. al. Experimental [Page 8]
RFC 2414 Increasing TCP's Initial Window September 1998
11.
[All97a] Mark Allman. An Evaluation of TCP with Larger
Windows. 40th IETF Meeting -- TCP Implementations WG
December, 1997. Washington, DC
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann,
Evaluation of TCP with Larger Initial Windows,
1998. Submitted to ACM Computer Communication Review
URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers
initwin.ps".
[All97b] Mark Allman. Improving TCP Performance Over
Channels. Master's thesis, Ohio University, June 1997.
[BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, "
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
Tahoe, Reno, and SACK TCP. Computer
Review, 26(3), July 1996.
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-
Congestion Control in the Internet. Submitted to
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
gateways for Congestion Avoidance. IEEE/ACM
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".
Allman, et. al. Experimental [Page 9]
RFC 2414 Increasing TCP's Initial Window September 1998
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran.
Page Transfer Rates Over Geo-Stationary Satellite Links
March 1998. Proceedings of the Sixth
Conference on Telecommunication Systems.
"http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".
[MD90] Mogul, J., and S. Deering, "Path MTU Discovery",
1191, November 1990.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "
Selective Acknowledgment Options", RFC 2018,
1996.
[Mor97] Robert Morris. Private communication, 1997. Cited
acknowledgement purposes only
[Nic97] Kathleen Nichols. Improving Network Simulation
Feedback. Com21, Inc. Technical Report. Available
http://www.com21.com/pages/papers/068.pdf
[PN98] Poduri, K., and K. Nichols, "Simulation Studies
Increased Initial TCP Window Size", RFC 2415,
1998.
[Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, August 1982.
[RF97] Ramakrishnan, K., and S. Floyd, "A Proposal to
Explicit Congestion Notification (ECN) to IPv6 and
TCP", Work in Progress
[RFC2119] Bradner, S., "Key words for use in RFCs to
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
Queue Management and Congestion Avoidance in
Internet", RFC 2309, April 1998.
[S97] Stevens, W., "TCP Slow Start, Congestion Avoidance,
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[SP97] Shepard, T., and C. Partridge, "When TCP Starts Up
Four Packets Into Only Three Buffers", RFC 2416,
September 1998.
Allman, et. al. Experimental [Page 10]
RFC 2414 Increasing TCP's Initial Window September 1998
12. Author's
Mark
NASA Lewis Research Center/Sterling
21000 Brookpark
MS 54-2
Cleveland, OH 44135
EMail: mallman@lerc.nasa.
http://gigahertz.lerc.nasa.gov/~mallman
Sally
Lawrence Berkeley National
One Cyclotron
Berkeley, CA 94720
EMail: floyd@ee.lbl.
Craig
BBN
10 Moulton
Cambridge, MA 02138
EMail: craig@bbn.
Allman, et. al. Experimental [Page 11]
RFC 2414 Increasing TCP's Initial Window September 1998
13. Appendix - Duplicate
In the current environment (without Explicit Congestion
[Flo94] [RF97]), all TCPs use segment drops as indications from
network about the limits of available bandwidth. We argue here
the change to a larger initial window should not result in the
retransmitting a large number of duplicate segments that have
been received at the receiver
If one segment is dropped from the initial window, there are
different ways for TCP to recover: (1) Slow-starting from a window
one segment, as is done after a retransmit timeout, or after
Retransmit in Tahoe TCP; (2) Fast Recovery without
acknowledgments (SACK), as is done after three duplicate ACKs in
TCP; and (3) Fast Recovery with SACK, for TCP where both the
and the receiver support the SACK option [MMFR96]. In all
cases, if a single segment is dropped from the initial window,
duplicate segments (i.e., segments that have already been received
the receiver) are transmitted. Note that for a TCP sending
512-byte segments in the initial window, a single segment drop
not require a retransmit timeout, but can be recovered from using
Fast Retransmit algorithm (unless the retransmit timer
prematurely). In addition, a single segment dropped from an
window of three segments might be repaired using the fast
algorithm, depending on which segment is dropped and whether or
delayed ACKs are used. For example, dropping the first segment of
three segment initial window will always require waiting for
timeout. However, dropping the third segment will always
recovery via the fast retransmit algorithm, as long as no ACKs
lost
Next we consider scenarios where the initial window contains two
four segments, and at least two of those segments are dropped.
all segments in the initial window are dropped, then clearly
duplicate segments are retransmitted, as the receiver has not
received any segments. (It is still a possibility that these
segments used scarce bandwidth on the way to their drop point;
issue was discussed in Section 5.)
When two segments are dropped from an initial window of
segments, the sender will only send a duplicate segment if the
two of the three segments were dropped, and the sender does
receive a packet with the SACK option acknowledging the
segment
When two segments are dropped from an initial window of
segments, an examination of the six possible scenarios (which
don't go through here) shows that, depending on the position of
Allman, et. al. Experimental [Page 12]
RFC 2414 Increasing TCP's Initial Window September 1998
dropped packets, in the absence of SACK the sender might send
duplicate segment. There are no scenarios in which the sender
two duplicate segments
When three segments are dropped from an initial window of
segments, then, in the absence of SACK, it is possible that
duplicate segment will be sent, depending on the position of
dropped segments
The summary is that in the absence of SACK, there are some
with multiple segment drops from the initial window where
duplicate segment will be transmitted. There are no scenarios
more that one duplicate segment will be transmitted. Our
is that the number of duplicate segments transmitted as a result of
larger initial window should be small
Allman, et. al. Experimental [Page 13]
RFC 2414 Increasing TCP's Initial Window September 1998
14. 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
Allman, et. al. Experimental [Page 14]
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
