draft-ietf-tsvwg-initwin-00.txt   draft-ietf-tsvwg-initwin-01.txt 
Internet Engineering Task Force Mark Allman Internet Engineering Task Force Mark Allman
INTERNET DRAFT BBN/NASA GRC INTERNET DRAFT BBN/NASA GRC
File: draft-ietf-tsvwg-initwin-00.txt May, 2001 File: draft-ietf-tsvwg-initwin-01.txt February, 2002
Expires: November, 2001 Expires: August, 2002
Sally Floyd Sally Floyd
ACIRI ICIR
Craig Partridge Craig Partridge
BBN Technologies BBN Technologies
Increasing TCP's Initial Window Increasing TCP's Initial Window
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies an increase in the permitted initial window This document specifies an increase in the permitted initial window
for TCP from one segment to roughly 4K bytes. This document for TCP from one segment to roughly 4K bytes. This document also
discusses the advantages and disadvantages of such a change, discusses the advantages and disadvantages of the change, outlining
outlining experimental results that indicate the costs and benefits experimental results that indicate the costs and benefits.
of such a change to TCP.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. TCP Modification 1. TCP Modification
This document specifies an increase in the permitted upper bound for This document specifies an increase in the permitted upper bound for
TCP's initial window from one segment to between two and four TCP's initial window from one segment to between two and four
segments. In most cases, this change results in an upper bound on segments. In most cases, this change results in an upper bound on
the initial window of roughly 4K bytes (although given a large the initial window of roughly 4K bytes (although given a large
segment size, the permitted initial window of two segments could be segment size, the permitted initial window of two segments may be
significantly larger than 4K bytes). The upper bound for the significantly larger than 4K bytes). The upper bound for the
initial window is given more precisely in (1): initial window is given more precisely in (1):
min (4*MSS, max (2*MSS, 4380 bytes)) (1) min (4*MSS, max (2*MSS, 4380 bytes)) (1)
Equivalently, the upper bound for the initial window size is based Equivalently, the upper bound for the initial window size is based
on the maximum segment size (MSS), as follows: on the maximum segment size (MSS), as follows:
If (MSS <= 1095 bytes) If (MSS <= 1095 bytes)
then win <= 4 * MSS; then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes) If (1095 bytes < MSS < 2190 bytes)
then win <= 4380; then win <= 4380;
If (2190 bytes <= MSS) If (2190 bytes <= MSS)
then win <= 2 * MSS; then win <= 2 * MSS;
This increased initial window is optional: that a TCP MAY start with This increased initial window is optional: that a TCP MAY start with
a larger initial window, not that it SHOULD. a larger initial window, not that it SHOULD.
This upper bound for the initial window size represents a change This upper bound for the initial window size represents a change
from RFC 2001 [RFC2581], which specifies that the congestion window be from RFC 2581 [RFC2581], which specified that the congestion window
initialized to one segment. If implementation experience proves be initialized to one or two segments.
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 in the This change applies to the initial window of the connection in the
first round trip time (RTT) of transmission following the TCP three- first round trip time (RTT) of data transmission following the TCP three-
way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in
the three-way handshake should increase the initial window size the three-way handshake should increase the initial window size
above that outlined in equation (1). If the SYN or SYN/ACK is lost, above that outlined in equation (1). If the SYN or SYN/ACK is lost,
the initial window used by a sender after a correctly transmitted the initial window used by a sender after a correctly transmitted
SYN MUST be one segment. SYN MUST be one segment consisting of MSS bytes.
TCP implementations use slow start in as many as three different TCP implementations use slow start in as many as three different
ways: (1) to start a new connection (the initial window); (2) to ways: (1) to start a new connection (the initial window); (2) to
restart a transmission after a long idle period (the restart restart transmission after a long idle period (the restart window);
window); and (3) to restart after a retransmit timeout (the loss and (3) to restart transmission after a retransmit timeout (the loss
window). The change proposed in this document affects the value of window). The change specified in this document affects the value of
the initial window. Optionally, a TCP MAY set the restart window to the initial window. Optionally, a TCP MAY set the restart window to
the minimum of the value used for the initial window and the current the minimum of the value used for the initial window and the current
value of cwnd (in other words, using a larger value for the restart value of cwnd (in other words, using a larger value for the restart
window should never increase the size of cwnd). These changes do window should never increase the size of cwnd). These changes do
NOT change the loss window, which must remain 1 segment (to permit NOT change the loss window, which must remain 1 segment of MSS bytes
the lowest possible window size in the case of severe congestion). (to permit the lowest possible window size in the case of severe
congestion).
2. Implementation Issues 2. Implementation Issues
When larger initial windows are implemented along with Path MTU When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], and the MSS being used is found to be too large, Discovery [RFC1191], and the MSS being used is found to be too large,
the congestion window `cwnd' SHOULD be reduced to prevent large the congestion window `cwnd' SHOULD be reduced to prevent large
bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced
by the ratio of the old segment size to the new segment size. by the ratio of the old segment size to the new segment size.
When larger initial windows are implemented along with Path MTU When larger initial windows are implemented along with Path MTU
Discovery [RFC1191], alternatives are to set the "Don't Fragment" (DF) Discovery [RFC1191], alternatives are to set the "Don't Fragment"
bit in all segments in the initial window, or to set the "Don't (DF) bit in all segments in the initial window, or to set the "Don't
Fragment" (DF) bit in one of the segments. It is an open question Fragment" (DF) bit in one of the segments. It is an open question
which of these two alternatives is best; we would hope that which of these two alternatives is best; we would hope that
implementation experiences will shed light on this. In the first implementation experiences will shed light on this question. In the
case of setting the DF bit in all segments, if the initial packets first 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 packets are too large, then all of the initial packets will be
the network. In the second case of setting the DF bit in only one dropped in the network. In the second case of setting the DF bit in
segment, if the initial packets are too large, then all but one of only one segment, if the initial packets are too large, then all but
the initial packets will be fragmented in the network. When the one of the initial packets will be fragmented in the network. When
second case is followed, setting the DF bit in the last segment in the second case is followed, setting the DF bit in the last segment
the initial window provides the least chance for needless in the initial window provides the least chance for needless
retransmissions when the initial segment size is found to be too retransmissions when the initial segment size is found to be too
large, because it minimizes the chances of duplicate ACKs triggering large, because it minimizes the chances of duplicate ACKs triggering
a Fast Retransmit. However, more attention needs to be paid to the a Fast Retransmit. However, more attention needs to be paid to the
interaction between larger initial windows and Path MTU Discovery. interaction between larger initial windows and Path MTU Discovery.
The larger initial window proposed in this document is not intended The larger initial window specified in this document is not intended
as an encouragement for web browsers to open multiple simultaneous as encouragement for web browsers to open multiple simultaneous
TCP connections all with large initial windows. When web browsers TCP connections all with large initial windows. When web browsers
open simultaneous TCP connections to the same destination, this open simultaneous TCP connections to the same destination, this
works against TCP's congestion control mechanisms [FF98], regardless works against TCP's congestion control mechanisms [FF98], regardless
of the size of the initial window. Combining this behavior with of the size of the initial window. Combining this behavior with
larger initial windows further increases the unfairness to other larger initial windows further increases the unfairness to other
traffic in the network. traffic in the network.
3. Advantages of Larger Initial Windows 3. Advantages of Larger Initial Windows
1. When the initial window is one segment, a receiver employing 1. When the initial window is one segment, a receiver employing
delayed ACKs [RFC1122] is forced to wait for a timeout before delayed ACKs [RFC1122] is forced to wait for a timeout before
generating an ACK. With an initial window of at least two generating an ACK. With an initial window of at least two
segments, the receiver will generate an ACK after the second segments, the receiver will generate an ACK after the second
data segment arrives. This eliminates the wait on the timeout data segment arrives. This eliminates the wait on the timeout
(often up to 200 msec). (often up to 200 msec, and possibly up to 500 msec [RFC1122]).
2. For connections transmitting only a small amount of data, a 2. For connections transmitting only a small amount of data, a
larger initial window reduces the transmission time (assuming at larger initial window reduces the transmission time (assuming at
most moderate segment drop rates). For many email (SMTP most moderate segment drop rates). For many email (SMTP
[Pos82]) and web page (HTTP [RFC1945, RFC2068]) transfers that [Pos82]) and web page (HTTP [RFC1945, RFC2068]) transfers that
are less than 4K bytes, the larger initial window would reduce are less than 4K bytes, the larger initial window would reduce
the data transfer time to a single RTT. the data transfer time to a single RTT.
3. For connections that will be able to use large congestion 3. For connections that will be able to use large congestion
windows, this modification eliminates up to three RTTs and a windows, this modification eliminates up to three RTTs and a
delayed ACK timeout during the initial slow-start phase. This delayed ACK timeout during the initial slow-start phase. This
would be of particular benefit for high-bandwidth large- will be of particular benefit for high-bandwidth large-
propagation-delay TCP connections, such as those over satellite propagation-delay TCP connections, such as those over satellite
links. links.
4. Disadvantages of Larger Initial Windows for the Individual 4. Disadvantages of Larger Initial Windows for the Individual
Connection Connection
In high-congestion environments, particularly for routers that have In high-congestion environments, particularly for routers that have
a bias against bursty traffic (as in the typical Drop Tail router a bias against bursty traffic (as in the typical Drop Tail router
queues), a TCP connection can sometimes be better off starting with queues), a TCP connection can sometimes be better off starting with
an initial window of one segment. There are scenarios where a TCP an initial window of one segment. There are scenarios where a TCP
skipping to change at page 4, line 18 skipping to change at page 4, line 16
bursts. This could result in an unnecessary retransmit timeout. bursts. This could result in an unnecessary retransmit timeout.
For a large-window connection that is able to recover without a For a large-window connection that is able to recover without a
retransmit timeout, this could result in an unnecessarily-early retransmit timeout, this could result in an unnecessarily-early
transition from the slow-start to the congestion-avoidance phase of transition from the slow-start to the congestion-avoidance phase of
the window increase algorithm. These premature segment drops are the window increase algorithm. These premature segment drops are
unlikely to occur in uncongested networks with sufficient buffering unlikely to occur in uncongested networks with sufficient buffering
or in moderately-congested networks where the congested router uses or in moderately-congested networks where the congested router uses
active queue management (such as Random Early Detection [FJ93, active queue management (such as Random Early Detection [FJ93,
RFC2309]). RFC2309]).
Some TCP connections will receive better performance with the higher Some TCP connections will receive better performance with the larger
initial window even if the burstiness of the initial window results initial window even if the burstiness of the initial window results
in premature segment drops. This will be true if (1) the TCP in premature segment drops. This will be true if (1) the TCP
connection recovers from the segment drop without a retransmit connection recovers from the segment drop without a retransmit
timeout, and (2) the TCP connection is ultimately limited to a small timeout, and (2) the TCP connection is ultimately limited to a small
congestion window by either network congestion or by the receiver's congestion window by either network congestion or by the receiver's
advertised window. advertised window.
5. Disadvantages of Larger Initial Windows for the Network 5. Disadvantages of Larger Initial Windows for the Network
In terms of the potential for congestion collapse, we consider two In terms of the potential for congestion collapse, we consider two
skipping to change at page 5, line 35 skipping to change at page 5, line 33
For a network with a high segment drop rate, increasing the TCP For a network with a high segment drop rate, increasing the TCP
initial window could increase the segment drop rate even initial window could increase the segment drop rate even
further. This is in part because routers with Drop Tail queue further. This is in part because routers with Drop Tail queue
management have difficulties with bursty traffic in times of management have difficulties with bursty traffic in times of
congestion. However, given uncorrelated arrivals for TCP congestion. However, given uncorrelated arrivals for TCP
connections, the larger TCP initial window should not connections, the larger TCP initial window should not
significantly increase the segment drop rate. Simulation-based significantly increase the segment drop rate. Simulation-based
explorations of these issues are discussed in Section 7.2. explorations of these issues are discussed in Section 7.2.
These potential dangers for the network are explored in simulations These potential dangers for the network are explored in simulations
and experiments described in the section below. Our judgment would and experiments described in the section below. Our judgment is that
be, while there are dangers of congestion collapse in the current while there are dangers of congestion collapse in the current
Internet (see [FF98] for a discussion of the dangers of congestion Internet (see [FF98] for a discussion of the dangers of congestion
collapse from an increased deployment of UDP connections without collapse from an increased deployment of UDP connections without
end-to-end congestion control), there is no such danger to the end-to-end congestion control), there is no such danger to the
network from increasing the TCP initial window to 4K bytes. network from increasing the TCP initial window to 4K bytes.
6. Interactions with the Retransmission Timer 6. Interactions with the Retransmission Timer
Using a larger initial burst of data can exacerbate existing Using a larger initial burst of data can exacerbate existing
problems with spurious retransmit timeouts on low-bandwidth paths, problems with spurious retransmit timeouts on low-bandwidth paths,
assuming the standard algorithm for determining the TCP assuming the standard algorithm for determining the TCP
retransmission timeout (RTO) [RFC2988]. The problem is that across retransmission timeout (RTO) [RFC2988]. The problem is that across
low-bandwidth network paths on which the transmission time of a low-bandwidth network paths on which the transmission time of a
packet is a large portion of the round-trip time, the small packets packet is a large portion of the round-trip time, the small packets
used to establish the connection do not seed the RTO appropriately. used to establish a TCP connection do not seed the RTO estimator appropriately.
When the first window of data packets is transmitted, the sender's When the first window of data packets is transmitted, the sender's
retransmit timer could expire before the acknowledgments for those retransmit timer could expire before the acknowledgments for those
packets are received. As each acknowledgment arrives, the packets are received. As each acknowledgment arrives, the
retransmit timer is generally reset. Thus, the retransmit timer retransmit timer is generally reset. Thus, the retransmit timer
will not expire as long as an acknowledgment arrives at least once will not expire as long as an acknowledgment arrives at least once
a second, given the one-second minimum on the RTO recommended in RFC a second, given the one-second minimum on the RTO recommended in RFC
2988. 2988.
For instance, consider a 9.6 Kbps link. The initial RTT measurement For instance, consider a 9.6 Kbps link. The initial RTT measurement
will be on the order of 67 msec, if we simply consider the will be on the order of 67 msec, if we simply consider the
skipping to change at page 6, line 23 skipping to change at page 6, line 21
seconds to transmit. Clearly the RTO will fire before the ACK for seconds to transmit. Clearly the RTO will fire before the ACK for
the first packet returns, causing a spurious timeout. In this case, the first packet returns, causing a spurious timeout. In this case,
a larger initial window of three or four packets exacerbates the a larger initial window of three or four packets exacerbates the
problems caused by this spurious timeout. problems caused by this spurious timeout.
One way to deal with this problem is to make the RTO algorithm more One way to deal with this problem is to make the RTO algorithm more
conservative. During the initial window of data, for instance, we conservative. During the initial window of data, for instance, we
could update the RTO for each acknowledgment received. In could update the RTO for each acknowledgment received. In
addition, if the retransmit timer expires for some packet lost in addition, if the retransmit timer expires for some packet lost in
the first window of data, we could leave the exponential-backoff of the first window of data, we could leave the exponential-backoff of
the retransmit timer until at least one valid measurement is the retransmit timer engaged until at least one valid RTT measurement is
received of the round-trip time of a data packet. received that involves a data packet.
Another method would be to refrain from taking a RTT sample during Another method would be to refrain from taking a RTT sample during
connection establishment, leaving the default RTO in place until we connection establishment, leaving the default RTO in place until TCP
take a sample from a data segment and the corresponding ACK. While takes a sample from a data segment and the corresponding ACK. While
this method likely helps prevent spurious retransmits it also slows this method likely helps prevent spurious retransmits it also slows
the data transfer down if loss occurs before the RTO is seeded. the data transfer down if loss occurs before the RTO is seeded.
This specification leaves the decision about what to do (if This specification leaves the decision about what to do (if
anything) with regards to the RTO when using a larger initial window anything) with regards to the RTO when using a larger initial window
to the implementer. to the implementer.
7. Typical Levels of Burstiness for TCP Traffic. 7. Typical Levels of Burstiness for TCP Traffic.
Larger TCP initial windows would not dramatically increase the Larger TCP initial windows would not dramatically increase the
skipping to change at page 7, line 12 skipping to change at page 7, line 10
a burst of 4K bytes can represent a small quantity of data. A a burst of 4K bytes can represent a small quantity of data. A
second change, for routers with sufficient buffering, is the second change, for routers with sufficient buffering, is the
deployment of queue management mechanisms such as RED, which is deployment of queue management mechanisms such as RED, which is
designed to be tolerant of transient traffic bursts. designed to be tolerant of transient traffic bursts.
8. Simulations and Experimental Results 8. Simulations and Experimental Results
8.1 Studies of TCP Connections using that Larger Initial Window 8.1 Studies of TCP Connections using that Larger Initial Window
This section surveys simulations and experiments that have been used This section surveys simulations and experiments that have been used
to explore the effect of larger initial windows on the TCP to explore the effect of larger initial windows on TCP
connection using that larger window. The first set of experiments connections. The first set of experiments
explores performance over satellite links. Larger initial windows explores performance over satellite links. Larger initial windows
have been shown to improve performance of TCP connections over have been shown to improve performance of TCP connections over
satellite channels [All97b]. In this study, an initial window of satellite channels [All97b]. In this study, an initial window of
four segments (512 byte MSS) resulted in throughput improvements of four segments (512 byte MSS) resulted in throughput improvements of
up to 30% (depending upon transfer size). [KAGT98] shows that the up to 30% (depending upon transfer size). [KAGT98] shows that the
use of larger initial windows results in a decrease in transfer time use of larger initial windows results in a decrease in transfer time
in HTTP tests over the ACTS satellite system. A study involving in HTTP tests over the ACTS satellite system. A study involving
simulations of a large number of HTTP transactions over hybrid fiber simulations of a large number of HTTP transactions over hybrid fiber
coax (HFC) indicates that the use of larger initial windows coax (HFC) indicates that the use of larger initial windows
decreases the time required to load WWW pages [Nic97]. decreases the time required to load WWW pages [Nic97].
skipping to change at page 8, line 5 skipping to change at page 7, line 57
This section surveys simulations and experiments investigating the This section surveys simulations and experiments investigating the
impact of the larger window on other TCP connections sharing the impact of the larger window on other TCP connections sharing the
path. Experiments in [All97a, AHO98] show that for 16 KB transfers path. Experiments in [All97a, AHO98] show that for 16 KB transfers
to 100 Internet hosts, four-segment initial windows resulted in a to 100 Internet hosts, four-segment initial windows resulted in a
small increase in the drop rate of 0.04 segments/transfer. While small increase in the drop rate of 0.04 segments/transfer. While
the drop rate increased slightly, the transfer time was reduced by the drop rate increased slightly, the transfer time was reduced by
roughly 25% for transfers using the four-segment (512 byte MSS) roughly 25% for transfers using the four-segment (512 byte MSS)
initial window when compared to an initial window of one segment. initial window when compared to an initial window of one segment.
One scenario of concern is heavily loaded links. For instance, a One scenario of concern is heavily loaded links. For instance,
couple of years ago, one of the trans-Atlantic links was so heavily several years ago one of the trans-Atlantic links was so heavily
loaded that the correct congestion window size for a connection was loaded that the correct congestion window size for each connection was
about one segment. In this environment, new connections using about one segment. In this environment, new connections using
larger initial windows would be starting with windows that were four larger initial windows would be starting with windows that were four
times too big. What would the effects be? Do connections thrash? times too big. What would the effects be? Do connections thrash?
A simulation study in [RFC2415] explores the impact of a larger initial A simulation study in [RFC2415] explores the impact of a larger initial
window on competing network traffic. In this investigation, HTTP window on competing network traffic. In this investigation, HTTP
and FTP flows share a single congested gateway (where the number of and FTP flows share a single congested gateway (where the number of
HTTP and FTP flows varies from one simulation set to another). For HTTP and FTP flows varies from one simulation set to another). For
each simulation set, the paper examines aggregate link utilization each simulation set, the paper examines aggregate link utilization
and packet drop rates, median web page delay, and network power for and packet drop rates, median web page delay, and network power for
skipping to change at page 8, line 55 skipping to change at page 8, line 53
timeouts. timeouts.
9. Security Considerations 9. Security Considerations
This document discusses the initial congestion window permitted for This document discusses the initial congestion window permitted for
TCP connections. Changing this value does not raise any known new TCP connections. Changing this value does not raise any known new
security issues with TCP. security issues with TCP.
10. Conclusion 10. Conclusion
This document proposes a small change to TCP that may be beneficial This document specifies a small change to TCP that will likely be beneficial
to short-lived TCP connections and those over links with long RTTs to short-lived TCP connections and those over links with long RTTs
(saving several RTTs during the initial slow-start phase). (saving several RTTs during the initial slow-start phase).
11. Acknowledgments 11. Acknowledgments
We would like to acknowledge Vern Paxson, Tim Shepard, members of We would like to acknowledge Vern Paxson, Tim Shepard, members of
the End-to-End-Interest Mailing List, and members of the IETF TCP the End-to-End-Interest Mailing List, and members of the IETF TCP
Implementation Working Group for continuing discussions of these Implementation Working Group for continuing discussions of these
issues for discussions and feedback on this document. issues for discussions and feedback on this document.
12. References 12. References
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation [AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation
of TCP with Larger Initial Windows, March 1998. Submitted to of TCP with Larger Initial Windows, March 1998. Submitted to
ACM Computer Communication Review. URL: ACM Computer Communication Review. URL:
skipping to change at page 10, line 44 skipping to change at page 10, line 41
Wroclawski, J., and L. Zhang, "Recommendations on Queue Wroclawski, J., and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC 2309, Management and Congestion Avoidance in the Internet", RFC 2309,
April 1998. April 1998.
[RFC2415] Poduri, K., and K. Nichols, "Simulation Studies of [RFC2415] Poduri, K., and K. Nichols, "Simulation Studies of
Increased Initial TCP Window Size", RFC 2415, September 1998. Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2416] Shepard, T., and C. Partridge, "When TCP Starts Up With [RFC2416] Shepard, T., and C. Partridge, "When TCP Starts Up With
Four Packets Into Only Three Buffers", RFC 2416, September 1998. Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2481] Ramakrishnan, K., and S. Floyd, "A Proposal to Add
Explicit Congestion Notification (ECN) to IPv6 and to TCP", RFC
2481, January 1999.
[RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens. TCP [RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens. TCP
Congestion Control, April 1999. RFC 2581. Congestion Control, April 1999. RFC 2581.
[RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission
Timer, November 2000. RFC 2988. Timer, November 2000. RFC 2988.
[RFC3042] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP's
Loss Recovery Using Limited Transmit, RFC 3042, January 2001.
[RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., "The
Addition of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
13. Author's Addresses 13. Author's Addresses
Mark Allman Mark Allman
BBN Technologies/NASA Glenn Research Center BBN Technologies/NASA Glenn Research Center
21000 Brookpark Road 21000 Brookpark Road
MS 54-5 MS 54-5
Cleveland, OH 44135 Cleveland, OH 44135
EMail: mallman@bbn.com EMail: mallman@bbn.com
http://roland.lerc.nasa.gov/~mallman/ http://roland.lerc.nasa.gov/~mallman/
Sally Floyd Sally Floyd
AT&T Center for Internet Research at ICSI (ACIRI) ICSI Center for Internet Research
1947 Center St, Suite 600 1947 Center St, Suite 600
Berkeley, CA 94704 Berkeley, CA 94704
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
EMail: floyd@aciri.org EMail: floyd@icir.org
http://www.aciri.org/floyd/ http://www.icir.org/floyd/
Craig Partridge Craig Partridge
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
EMail: craig@bbn.com EMail: craig@bbn.com
13. Appendix - Duplicate Segments
In the current environment (without Explicit Congestion Notification
[Flo94] [RFC2481]), all TCPs use segment drops as indications from
the network about the limits of available bandwidth. We argue here
that the change to a larger initial window should not result in the
sender retransmitting a large number of duplicate segments that have
already arrived at the receiver.
If 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,
no 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 (unless the
retransmit timer expires prematurely). In addition, a single
segment dropped from an initial window of three segments 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, in the absence of
Limited Transmit [RFC3042]. However, dropping the third segment
will always allow recovery via the fast retransmit algorithm, as
long as no ACKs are lost.
Next we consider scenarios where the 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 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 of three
segments, the sender will only send a duplicate segment if the first
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 four
segments, an examination of the six possible scenarios (which we
don't go through here) shows that, depending on the position of the
dropped packets, in the absence of 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 an initial window of four
segments, then, in the absence of SACK, it is possible that one
duplicate segment will be sent, depending on the position of the
dropped segments.
The summary is that in the absence of SACK, there are some scenarios
with multiple segment drops from the 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 duplicate segments transmitted as a result of
a larger initial window should be small.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/