wdiff draft-floyd-incr-init-win-01.txt draft-floyd-incr-init-win-02.txt

Internet Engineering Task Force Mark
TCP Implementation Working Group M. Allman
INTERNET DRAFT NASA Lewis/Sterling Software
File: draft-floyd-incr-init-win-01.txt Sally draft-floyd-incr-init-win-02.txt S. Floyd
LBL
Craig
LBNL
C. Partridge
BBN Technologies
March, 1998
Expires: September,
April, 1998

Increasing TCP's Initial Window

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''

To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check
the
``1id-abstracts.txt'' "1id-abstracts.txt" listing contained in the Internet- Drafts Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ds.internic.net ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

Abstract

This is a note to suggest changing document specifies an increase in the permitted initial window in
for TCP from 1 one segment to roughly 4K bytes. This draft considers document
discusses the advantages and disadvantages of such a change, as well as
outlining
some experimental results that indicate the costs and benefits
of
making such a change to TCP, TCP.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and pointing out remaining research
questions.
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119].

1. TCP Modification

This draft suggests allowing document specifies an increase in the permitted upper bound
for TCP's initial window used by a TCP
connection to increase from 1 one segment to between 2 two
and 4 four segments. In most cases, this will result change results in an upper
bound on the initial window of roughly 4K bytes (although given a
large segment size, the permitted initial window of two segments
could be significantly larger than 4K bytes). The proposed upper bound for
the initial window
size is given more precisely in (1):

min (4*MSS, max (2*MSS, 4380 bytes)) (1)

Or, more specifically

Equivalently, the upper bound for the initial window size
is based on the maximum segment size (MSS), as follows:

MSS

If (MSS <= 1095 bytes: bytes)
then win = <= 4 * MSS
1095 MSS;
If (1095 bytes < MSS < 2190 bytes: bytes)
then win = 4380
MSS => 2190 bytes: <= 4380;
If (2190 bytes <= MSS)
then win = <= 2 * MSS MSS;

This increased initial window would be is optional: that a TCP MAY
start with a larger initial window, not that it SHOULD.

This upper bound for the initial window size represents a change would only apply
from RFC 2001 [S97], which specifies that the congestion window be
initialized to one segment. If implementation experience proves
successful, then the intent is for this change to be incorporated
into a revision to RFC 2001.

This change applies to the initial window of the
connection, connection in the
first round trip time (RTT) of transmission following the TCP
three-way handshake. That is, Neither the SYN/ACK nor its acknowledgment
(ACK) in the
three way three-way handshake should not increase the initial window
size above that outlined in equation (1). However, if If the SYN or SYN/ACK is lost
lost, the initial window used by a sender after a correctly
transmitted SYN MUST be 1 one segment.

Some

TCP implementations use slow start in as many as three different ways:
(1) to re-start start a new connection (the initial window); (2) to restart
a transmission after a long idle period. In this case, the initial window used
should be the same as the initial window used at the beginning of
the transfer. period (the restart window); and
(3) to restart after a retransmit timeout (the loss window). The
change proposed in this document would not change affects the behavior after a retransmit timeout, when value of the sender would
continue to slow start from an initial window of one segment.

2. Advantages of Larger Initial Windows

1. For connections transmitting only a small amount of data,
window. Optionally, a
larger initial TCP MAY set the restart window would reduce to the transmission time
(assuming moderate segment drop rates). For many email (SMTP
[Pos82]) and web page (HTTP [BLFN96, FJGFBL97]) transfers that
are less than 4K bytes,
same value used for the larger initial window would reduce window. These changes do NOT
change the data transfer time to a single RTT.

2. For connections that will be able to use large congestion
windows, this modification eliminates up to three RTTs and a
delayed ACK timeout during loss window, which must remain 1 (to permit the initial slow-start phase. This
would be lowest
possible window size in the case of particular benefit for high-bandwidth
large-propagation-delay TCP connections, such as those over
satellite links.

3. severe congestion).

2. Implementation Issues

When the larger initial window is 1 segment, a receiver employing
delayed acknowledgments (ACK) [Bra89] windows are implemented along with Path MTU
Discovery [MD90], and the MSS being used is forced found to wait for a
timeout before generating an ACK. With a larger initial window, be too large,
the receiver will congestion window `cwnd' SHOULD be able reduced to generate an ACK after prevent large
bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced
by the second
data segment arrives. This eliminates ratio of the need old segment size to wait on the
timeout (0.1 seconds, or more).

3. Implementation Issues new segment size.

When larger initial windows are implemented along with Path MTU
Discovery [MD90], only one of alternatives are to set the "Don't Fragment" (DF)
bit in all segments in the initial window
should have window, or to set the "Don't
Fragment" (DF) bit set. Preliminary analysis
indicates in one of the segments. It is an open question
which of these two alternatives is best; we would hope that
implementation experiences will shed light on this. In the first
case of setting the DF bit in all segments, if the initial packets
are too large, then all of the initial packets will be dropped in
the network. In the second case of setting the DF bit in only one
segment, if the initial packets are too large, then all but one of
the initial packets will be fragmented in the network. When the
second case is followed, setting the DF bit in the last segment in
the initial window provides the least chance for needless
retransmissions and
large line-rate bursts of segments when the initial segment size is found to be too large. In addition, if the MSS being used is found
to be too
large, because it minimizes the cwnd should be reduced to prevent large bursts
of smaller segments. Specifically, cwnd should be reduced by the
ratio chances of the old segment size to the new segment size. duplicate ACKs
triggering a Fast Retransmit. However, more attention needs to be
paid to the interaction between larger initial windows and Path MTU
Discovery.

The larger initial window proposed in this document SHOULD NOT be
viewed is not intended
as an encouragement for web browsers to open multiple simultaneous
TCP connections all with larger large initial windows. (Web When web browsers should not
open four simultaneous TCP connections to the same destination in any case, because destination, this
works against TCP's congestion control mechanisms [FF98]). [FF98],
regardless of the size of the initial window. Combining this
behavior with larger initial windows further increases the
unfairness to other traffic in the network.

3. Advantages of Larger Initial Windows

1. When the initial window is one segment, a receiver employing
delayed ACKs [Bra89] is forced to wait for a timeout before
generating an ACK. With an initial window of at least two
segments, the receiver will generate an ACK after the second
data segment arrives. This eliminates the wait on the timeout
(often up to 200 msec).

2. For connections transmitting only a small amount of data, a
larger initial window reduces the transmission time (assuming
moderate segment drop rates). For many email (SMTP [Pos82])
and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less
than 4K bytes, the larger initial window would reduce the data
transfer time to a single RTT.

3. For connections that will be able to use large congestion
windows, this modification eliminates up to three RTTs and a
delayed ACK timeout during the initial slow-start phase. This
would be of particular benefit for high-bandwidth
large-propagation-delay TCP connections, such as those over
satellite links.

4. Disadvantages of Larger Initial Windows for the Individual
Connection

In high-congestion environments, particularly for routers that have
a bias against bursty traffic (as in the typical Drop Tail router
queues), a TCP connection can sometimes be better off starting with
an initial window of one segment. There are scenarios where a TCP
connection slow-starting from an initial window of one segment might
not have segments dropped, while a TCP connection starting with an
initial window of four segments might experience unnecessary
retransmits due to the inability of the router to handle small
bursts. This could result in an unnecessary retransmit timeout.
For a large-window connection that is able to recover without a
retransmit timeout, this could result in an unnecessarily-early
transition from the slow-start to the congestion-avoidance phase of
the window increase algorithm. These premature segment drops should
not happen occur in uncongested networks, networks with sufficient buffering or in
moderately-congested networks where the congested router used uses
active queue management (such as Random Early Detection [FJ93]).

Some TCP connections will receive better performance with the higher
initial window even if the burstiness of the initial window results
in premature segment drops. This will be true if (1) the TCP
connection recovers from the segment drop without a retransmit
timeout, and (2) the TCP connection is ultimately limited to a small
congestion window by either network congestion or by the receiver's
advertised window.

5. Disadvantages of Larger Initial Windows for the Network

In terms of the potential for congestion collapse, we consider two
separate potential dangers for the network. The first danger would
be a scenario where a large number of segments on congested links
were duplicate or unnecessarily-retransmitted segments that had already been received at the
receiver. The second danger would be a scenario where a large
number of segments on congested links were segments that would be
dropped later in the network before reaching their final
destination.

Unnecessarily-retransmitted

In terms of the negative effect on other traffic in the network, a
potential disadvantage of larger initial windows would be that they
increase the general packet drop rate in the network. We discuss
these three issues below.

Duplicate segments:

As described in the previous section, the larger initial window
could occasionally result in a segment dropped from the initial
window, when that segment might not have been dropped if the
sender had slow-started from an initial window of one segment.
However, Appendix A shows that even in this case, the larger
initial window would not result in the transmission of a large
number of
unnecessarily-retransmitted duplicate segments.

Segments dropped later in the network:

How much would the larger initial window for TCP increase the
number of segments on congested links that would be dropped
before reaching their final destination? This is a problem that
can only occur for connections with multiple congested links,
where some segments might use scarce bandwidth on the first
congested link along the path, only to be dropped later along
the path.

First, many of the TCP connections will have only one congested
link along the path. Segments dropped from these connections do
not ``waste'' scarce bandwidth, and do not contribute to
congestion collapse.

However, some network paths will have multiple congested links,
and segments dropped from the initial window could use scarce
bandwidth along the earlier congested links before ultimately
being dropped on subsequent congested links. To the extent
that the drop rate is independent of the initial window used by
TCP segments, the problem of congested links carrying segments
that will be dropped before reaching their destination will be
similar for TCP connections that start by sending four segments
or one segment.

An increased packet drop rate:

For a network with a high segment drop rate, increasing the
initial TCP congestion
initial window could increase the segment drop rate even
further. This is in part because routers with drop
tail Drop Tail queue
management have difficulties with bursty traffic in times of
congestion. However, this should be a second order
effect. Given given uncorrelated arrivals for TCP
connections, the larger initial TCP congestion initial window should generally not
significantly increase the segment drop rate.

6. Network Changes

There Simulation-based
explorations of these issues are other changes discussed in the network that make a larger initial
window less of a problem. Section 7.2.

These include potential dangers for the increasing deployment
of higher-speed links where 4K bytes is a rather small quantity of
data network are explored in simulations
and experiments described in the deployment of queue management mechanisms such as RED
that section below. Our judgement
would be, while there are more tolerant dangers of transient traffic bursts. The congestion collapse in the
current Internet (see [FF98] for a discussion of the dangers of
congestion collapse most likely now come not from a 4K
initial burst from TCP connections, but from the an increased deployment of UDP connections
without end-to-end congestion control.

7. Concerns

All the experiments (see section 8) with larger initial windows have
tested how control), there is no such danger to
the larger window affects network from increasing the TCP connection that uses
the larger window. No one has thoroughly studied the impact of the
larger initial window on other TCP connections. In particular, no one has a
thorough set to 4K bytes.

6. Typical Levels of answers about what happens when a Burstiness for TCP Traffic.

Larger TCP bursts a
larger initial window into or across a path already being shared by
a set windows would not dramatically increase the
burstiness of established TCP connections.

Part of the reason for this omission is the assumption that the
effect is small. For example, traffic in much of the Internet bursts today, because such
traffic is already fairly bursty. Bursts of 2 two and 3 three segments
are common and bursts already typical of 4 and 5 segments are not
rare. TCP [Flo97]; A delayed ACK (covering two
previously unacknowledged segments) received during congestion
avoidance causes the congestion window to slide and 2 two segments to
be sent. The same delayed ACK received during slow start causes
the window to slide by 2 two segments and then be incremented by 1 one
segment, leading to resulting in a 3 segment three-segment burst. While not necessarily
typical, bursts of four and five segments for TCP are not rare.
Assuming delayed ACKs, a single dropped ACK causes the subsequent
ACK to cover 4 four previously unacknowledged segments. During
congestion avoidance this leads to a 4 segment four-segment burst and during
slow start a 5
segment five-segment burst is generated.

However, there

There are some common scenarios where a larger initial
window might have an effect. One example is low speed tail circuits
with routers with small buffers. For instance, imagine a dialup
link connecting routers each of which have a handful of buffers.
Further imagine also changes in progress that reduce the link is already being shared performance
problems posed by a few TCP
connections. Then a new connection launches a large initial window,
causing losses. How long will it be before the connections resume
sharing moderate traffic bursts. One such change is the link fairly? Are there any signs
deployment of a capture effect, higher-speed links in which the new TCP gets a large fraction some parts of the bandwidth? (A
capture effect could ensure that, say, an SMTP server got more
bandwidth than network,
where a long running FTP).

Another scenario burst of concern is heavily loaded links. For instance, 4K bytes can represent a couple of years ago, one small quantity of the trans-Atlantic links was so
heavily loaded that the correct congestion window size data.
A second change, for a
connection was about one segment. In this environment, new
connections using larger initial windows would be starting routers with
windows that were four times too big. What would sufficient buffering, is the effects be?
Do connections thrash?

8.
deployment of queue management mechanisms such as RED, which is
designed to be tolerant of transient traffic bursts.

7. Simulations and Experimental Results

8.1

7.1 Studies of TCP Connections using that Larger Initial Windows

A number of studies Window

This section surveys simulations and experiments that have been done using larger initial windows.
The first study considers the effects on the global Internet, as
well as on slow dialup modem links [All97a]. These test results
show that for 16 KB transfers
used to 100 Internet hosts, 4 segment
initial windows resulted in an increase in explore the drop rate effect of 0.04
segments/transfer. While the drop rate increased slightly, the
transfer time was reduced by roughly 25% for transfers using a 4
segment (512 byte MSS) initial window when compared to an larger initial
window of 1 segment. Tests over a 28.8 bps dialup channel showed no
increase in windows on the drop rate and a transfer time decrease of roughly
10% over standard TCP when
connection using a 4 segment initial window.

In another study, that larger window. The first set of experiments
explores performance over satellite links. Larger initial windows
have been shown to improve performance of TCP connections over
satellite channels [All97b]. In this study, an initial window of 4
four segments (512 byte MSS) resulted in throughput improvements of
up to 30% (depending upon transfer size).

Next, [HAGT98] shows that the
use of larger initial windows results in a decrease in transfer
time in HTTP tests over the ACTS satellite system. A study
involving simulations of a large number of HTTP transactions over
hybrid fiber coax (HFC) indicates that the use of larger initial
windows decreases the time required to load WWW pages [Nic97]. [HAGT98] also shows that the use

A second set of larger initial windows
results in experiments has explored TCP performance over
dialup modem links. In experiments over a decrease in 28.8 bps dialup channel
[All97a, AHO98], a four-segment initial window decreased the
transfer time of a 16KB file by roughly 10%, with no accompanying
increase in HTTP tests over the ACTS
satellite system. drop rate. A particular area of concern has been
TCP performance over low speed tail circuits (e.g., dialup modem
links) with routers with small buffers. A simulation study [SP97]
investigated the effects of using a larger initial window on a host
connected by a slow modem link and a router with a 3 packet
buffer [SP97]. This
buffer. The study found concluded that in this environment, for the scenario investigated,
the use of larger initial windows slightly improved was not harmful to TCP
performance.

8.2 Questions have been raised concerning the effects of
larger initial windows on the transfer time for short transfers in
this environment, but these effects have not been quantified. A
question has also been raised concerning the possible effect on
existing TCP connections sharing the link.

7.2 Studies of Networks using Larger Initial Windows

This section surveys simulations and experiments investigating the
impact of the larger window on other TCP connections sharing the
path. Experiments in [All97a, AHO98] show that for 16 KB transfers
to 100 Internet hosts, four-segment initial windows resulted in a
small increase in the drop rate of 0.04 segments/transfer. While
the drop rate increased slightly, the transfer time was reduced by
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, a couple of years ago, one of the trans-Atlantic links
was so heavily loaded that the correct congestion window size for a
connection was about one segment. In this environment, new
connections using larger initial windows would be starting with
windows that were four times too big. What would the effects be?
Do connections thrash?

A simulation study of how in [PN98] explores the use impact of a larger
initial window impacts on competing network traffic is outlined in [PN98]. traffic. In this
investigation, a number of HTTP and FTP flows were sharing share a single congested gateway (the exact
(where the number of flows was varied in this
study). The study showed improvement in HTTP transfer times on and FTP flows varies from one simulation
set to another). For each simulation set, the
order of 30% in many scenarios. In addition, a paper examines
aggregate link utilization and packet drop rates, median web page
delay, and network power for the FTP transfers. The larger initial
window slightly generally resulted in increased the segment throughput,
slightly-increased packet drop rate (only rates, and an increase in overall
network power. With the exception of one scenario
increased scenario, the larger
initial window resulted in an increase in the drop rate more of less
than 1% above the loss rate experienced when using an a one-segment
initial window; in this scenario, the drop rate increased from
3.5% with one-segment initial windows, to 4.5% with four-segment
initial windows. The overall conclusions were that increasing the
TCP initial window of 1 segment). to three packets (or 4380 bytes) helps to
improve perceived performance.

Morris [Mor97] investigated larger initial windows in a very
congested
network. network with transfers of size 20K. The loss rate in
networks where all TCP connections use an initial window of 4 four
segments is shown to be 1-2% greater than in a network where all
connections use an initial window of 1 one segment. This
relationship held in scenarios where the loss rates with
one-segment initial windows ranged from 1% to 11%. In addition, in
networks where connections used an initial window of
4 four segments, roughly 5-10%
TCP connections spent more time was spent waiting for the retransmit timer
(RTO) to expire to resend a segment than was spent when using an
initial window of 1 one segment. The time spent waiting for the RTO
timer to expire represents idle time when no useful work was being accomplished.
accomplished for that connection. These results show that in a
very congested environment, where each connection's share of the
bottleneck bandwidth is close to 1 one segment, using a larger
initial window
degrades performance. can cause a perceptible increase in both loss rates
and retransmit timeouts.

8. Security Considerations

This document discusses the initial congestion window permitted
for TCP connections. Changing this value does not raise any known
new security issues with TCP.

9. Conclusion

This draft suggests document proposes a small change to TCP that may be beneficial to
short lived
short-lived TCP connections and those over links with long RTTs
(saving several RTTs during the initial slow-start phase).

10. Acknowledgments

We would like to acknowledge Vern Paxson, Tim Shepard and the Shepard, members of
the End-to-End-Interest Mailing List List, and members of the IETF TCP
Implementation Working Group for continuing discussions of these
issues.
issues for discussions and feedback on this document.

11. References

[All97a] Mark Allman. An Evaluation of TCP with Larger Initial
Windows. 40th IETF Meeting -- TCP Implementations WG.
December, 1997. Washington, DC.

[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An
Evaluation of TCP with Larger Initial Windows, March 1998.
Submitted to ACM Computer Communication Review. URL
"http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps".

[All97b] Mark Allman. Improving TCP Performance Over Satellite
Channels. Master's thesis, Ohio University, June 1997.

[BLFN96] Tim Berners-Lee, R. Fielding, and H. Nielsen. Hypertext
Transfer Protocol -- HTTP/1.0, May 1996. RFC 1945.

[Bra89] Robert Braden. Requirements for Internet Hosts --
Communication Layers, October 1989. RFC 1122.

[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP. Computer Communication Review,
26(3), July 1996.

[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End
Congestion Control in the Internet. Submitted to IEEE
Transactions on Networking. URL
"http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html".

[FJGFBL97] R. Fielding, Jeffrey C. Mogul, Jim Gettys, H. Frystyk,
and Tim Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1,
January 1997. RFC 2068.

[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways
for Congestion Avoidance. IEEE/ACM Transactions 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/.

[HAGT98]

[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".

[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP
Page Transfer Rates Over Geo-Stationary Satellite Links. March
1998. Proceedings of the Sixth International Conference on
Telecommunication Systems. To Appear. URL
"http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".

[MD90] Jeffrey C. Mogul and Steve Deering. Path MTU Discovery,
November 1990. RFC 1191.

[MMFR96] Matt Mathis, Jamshid Mahdavi, Sally Floyd and Allyn
Romanow. TCP Selective Acknowledgment Options, October 1996.
RFC 2018.

[Mor97] Robert Morris. Private communication. communication, 1997. Cited for
acknowledgement purposes only.

[Nic97] Kathleen Nichols. Improving Network Simulation with
Feedback. Com21, Inc. Technical Report. Available from
http://www.com21.com/pages/papers/068.pdf.

[PN98] Poduri, K., and Nichols, K., Simulation Studies of Increased
Initial TCP Window Size, February 1998. Internet-Draft
draft-ietf-tcpimpl-poduri-00.txt (work in progress).

[Pos82] Jon Postel. Simple Mail Transfer Protocol, August 1982.
RFC 821.

[RF97] Ramakrishnan, K.K., and Floyd, S., A Proposal to Add Explicit
Congestion Notification (ECN) to IPv6 and to TCP. Internet-Draft
draft-kksjf-ecn-00.txt (work in progress). November 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[S97] W. Stevens, TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms. RFC 2001, Proposed
Standard, January 1997.

[SP97] Tim Shepard and Craig Partridge. When TCP Starts Up With
Four Packets Into Only Three Buffers, July 1997. Internet-Draft
draft-shepard-TCP-4-packets-3-buff-00.txt (work in progress).

12. Author's Addresses

Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Road
MS 54-2
Cleveland, OH 44135
mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/

Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720
floyd@ee.lbl.gov

Craig Partridge
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
craig@bbn.com

13. Appendix A - Duplicate Segments

In the current environment (without Explicit Congestion
Notification [Flo94] [RF97]), all TCPs use segment drops as
indications from the network about the limits of available
bandwidth. The We argue here that the change to a larger initial
window should not result in the sender retransmitting
a large number of
unnecessarily-retransmitted segments. duplicate segments that have already been
received at the receiver.

If a one segment is dropped from the initial window, there are three
different ways for TCP to recover: (1) Slow-starting from a window
of one segment, as is done after a retransmit timeout, or after Fast
Retransmit in Tahoe TCP; (2) Fast Recovery without selective
acknowledgments (SACK), as is done after three duplicate ACKs in
Reno TCP; and (3) Fast Recovery with SACK, for TCP where both the
sender and the receiver support the SACK option [MMFR96]. In all
three cases, if a single segment is dropped from the initial window,
there are
no unnecessarily-retransmitted segments. duplicate segments (i.e., segments that have already been
received at the receiver) are transmitted. Note that for a
TCP sending four 512-byte segments in the initial window, a single
segment drop will not require a retransmit timeout, but can be
recovered from using the Fast Retransmit algorithm. algorithm (unless the
retransmit timer expires prematurely). In addition, a single
segment dropped from an initial window of three segments may might be
repaired using the fast retransmit algorithm, depending on which
segment is dropped and whether or not delayed ACKs are used. For
example, dropping the first segment of a three segment initial
window will always require waiting for a timeout. However,
dropping the third segment will always allow recovery via the fast
retransmit
algorithm.

We now algorithm, as long as no ACKs are lost.

Next we consider scenarios where the case when multiple initial window contains
two to four segments, and at least two of those segments are dropped.
If all segments in the initial window are dropped, then clearly
no duplicate segments are retransmitted, as the receiver has not yet
received any segments. (It is still a possibility that these dropped from
segments used scarce bandwidth on the way to their drop point;
this issue was discussed in Section 5.)

When two segments are dropped from an initial window. Using window of three
segments, the sender will only send a duplicate segment if the
first recovery method, slow-starting from two of the three segments were dropped, and the sender does
not receive a packet with the SACK option acknowledging the third
segment.

When two segments are dropped from an initial window of one segment, four
segments, an examination of the number six possible scenarios (which we
don't go through here) shows that, depending on the position of unnecessarily-retransmitted
segments is limited [FF96]. In the second case
dropped packets, in the absence of Fast Recovery
without SACK, multiple segment drops SACK the sender might send one
duplicate segment. There are no scenarios in which the sender
sends two duplicate segments.

When three segments are dropped from a an initial window of data generally
result four segments,
then, in a retransmit timeout. Again, the number absence of
unnecessarily-retransmitted segments SACK, it is small. In possible that one duplicate
segment will be sent, depending on the third case, position of the dropped segments.

The summary is that in the absence of Fast Recovery with SACK, there can only be
unnecessarily-retransmitted segments if a precise pattern of ACK
segments are also lost [Flo96], or if segments are
seriously-reordered in some
scenarios with multiple segment drops from the network. In any case, initial window where
one duplicate segment will be transmitted. There are no scenarios
where more that one duplicate segment will be transmitted. Our
conclusion is that the number of
unnecessarily-retransmitted duplicate segments due to transmitted as
a result of a larger initial window should be small.

Author's Addresses

Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Road
MS 54-2
Cleveland, OH 44135
mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/

Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720
floyd@ee.lbl.gov

Craig Partridge
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
craig@bbn.com

14. Full Copyright Statement

[This section would be filled in with the standard template if
this document advances to an RFC.]