<pre>Network Working Group                                          M. Allman
Request for Comments: 3390                                  BBN/NASA GRC
Obsoletes: <a href="./rfc2414">2414</a>                                                 S. Floyd
Updates: <a href="./rfc2581">2581</a>                                                       ICIR
Category: Standards Track                                   C. Partridge
                                                        BBN Technologies
                                                            October 2002


                    <span class="h1">Increasing TCP's Initial Window</span>

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document specifies an optional standard for TCP to increase the
   permitted initial window from one or two segment(s) to roughly 4K
   bytes, replacing <a href="./rfc2414">RFC 2414</a>.  It discusses the advantages and
   disadvantages of the higher initial window, and includes discussion
   of experiments and simulations showing that the higher initial window
   does not lead to congestion collapse.  Finally, this document
   provides guidance on implementation issues.

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  TCP Modification</span>

   This document obsoletes [<a href="./rfc2414" title="&quot;Increasing TCP's Initial Window&quot;">RFC2414</a>] and updates [<a href="./rfc2581" title="&quot;TCP Congestion Control&quot;">RFC2581</a>] and specifies
   an increase in the permitted upper bound for TCP's initial window
   from one or two segment(s) to between two and four segments.  In most
   cases, this 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 may be significantly larger than 4K
   bytes).



<span class="grey">Allman, et. al.             Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   The upper bound for the initial window is given more precisely in
   (1):

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

   Note: Sending a 1500 byte packet indicates a maximum segment size
   (MSS) of 1460 bytes (assuming no IP or TCP options).  Therefore,
   limiting the initial window's MSS to 4380 bytes allows the sender to
   transmit three segments initially in the common case when using 1500
   byte packets.

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

       If (MSS &lt;= 1095 bytes)
           then win &lt;= 4 * MSS;
       If (1095 bytes &lt; MSS &lt; 2190 bytes)
           then win &lt;= 4380;
       If (2190 bytes &lt;= MSS)
           then win &lt;= 2 * MSS;

   This increased initial window is optional: a TCP MAY start with a
   larger initial window.  However, we expect that most general-purpose
   TCP implementations would choose to use the larger initial congestion
   window given in equation (1) above.

   This upper bound for the initial window size represents a change from
   <a href="./rfc2581">RFC 2581</a> [<a href="./rfc2581" title="&quot;TCP Congestion Control&quot;">RFC2581</a>], which specified that the congestion window be
   initialized to one or two segments.

   This change applies to the initial window of the connection in the
   first round trip time (RTT) of data transmission following the TCP
   three-way handshake.  Neither the SYN/ACK nor its acknowledgment
   (ACK) in the three-way handshake should increase the initial window
   size 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 SYN MUST be one segment consisting of MSS bytes.

   TCP implementations use slow start in as many as three different
   ways: (1) to start a new connection (the initial window); (2) to
   restart transmission after a long idle period (the restart window);
   and (3) to restart transmission after a retransmit timeout (the loss
   window).  The change specified in this document affects the value of
   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
   value of cwnd (in other words, using a larger value for the restart
   window should never increase the size of cwnd).  These changes do NOT
   change the loss window, which must remain 1 segment of MSS bytes (to



<span class="grey">Allman, et. al.             Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   permit the lowest possible window size in the case of severe
   congestion).

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Implementation Issues</span>

   When larger initial windows are implemented along with Path MTU
   Discovery [<a href="./rfc1191" title="&quot;Path MTU Discovery&quot;">RFC1191</a>], and the MSS being used is found to be too large,
   the congestion window `cwnd' SHOULD be reduced to prevent large
   bursts of smaller segments.  Specifically, `cwnd' SHOULD be reduced
   by the ratio of the old segment size to the new segment size.

   When larger initial windows are implemented along with Path MTU
   Discovery [<a href="./rfc1191" title="&quot;Path MTU Discovery&quot;">RFC1191</a>], alternatives are to set the "Don't Fragment"
   (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 as
   to which of these two alternatives is best; we would hope that
   implementation experiences will shed light on this question.  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 when the initial segment size is found to be too
   large, because it minimizes the chances of 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 specified in this document is not intended
   as encouragement for web browsers to open multiple simultaneous TCP
   connections, all with large initial windows.  When web browsers open
   simultaneous TCP connections to the same destination, they are
   working against TCP's congestion control mechanisms [<a href="#ref-FF99" title="&quot;http://www.icir.org/floyd/end2end-paper.html&quot;">FF99</a>],
   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.  We suggest the use of HTTP/1.1
   [<a href="./rfc2068" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2068</a>] (persistent TCP connections and pipelining) as a way to
   achieve better performance of web transfers.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Advantages of Larger Initial Windows</span>

   1.  When the initial window is one segment, a receiver employing
       delayed ACKs [<a href="./rfc1122" title="&quot;Requirements for Internet Hosts -- Communication Layers&quot;">RFC1122</a>] 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, and possibly up to 500 msec [<a href="./rfc1122" title="&quot;Requirements for Internet Hosts -- Communication Layers&quot;">RFC1122</a>]).



<span class="grey">Allman, et. al.             Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   2.  For connections transmitting only a small amount of data, a
       larger initial window reduces the transmission time (assuming at
       most moderate segment drop rates).  For many email (SMTP [<a href="#ref-Pos82" title="&quot;Simple Mail Transfer Protocol&quot;">Pos82</a>])
       and web page (HTTP [RFC1945, <a href="./rfc2068">RFC2068</a>]) 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
       will be of particular benefit for high-bandwidth large-
       propagation-delay TCP connections, such as those over satellite
       links.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Disadvantages of Larger Initial Windows for the Individual</span>
<span class="h2">    Connection</span>

   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 are
   unlikely to occur in uncongested networks with sufficient buffering
   or in moderately-congested networks where the congested router uses
   active queue management (such as Random Early Detection [FJ93,
   <a href="./rfc2309">RFC2309</a>]).

   Some TCP connections will receive better performance with the larger
   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Disadvantages of Larger Initial Windows for the Network</span>

   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



<span class="grey">Allman, et. al.             Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   were duplicate 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.

   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, <a href="#appendix-A">Appendix A</a> shows that even in this case, the larger
       initial window would not result in the transmission of a large
       number of 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.







<span class="grey">Allman, et. al.             Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   An increased packet drop rate:

       For a network with a high segment drop rate, increasing the TCP
       initial window could increase the segment drop rate even further.
       This is in part because routers with Drop Tail queue management
       have difficulties with bursty traffic in times of congestion.
       However, given uncorrelated arrivals for TCP connections, the
       larger TCP initial window should not significantly increase the
       segment drop rate.  Simulation-based explorations of these issues
       are discussed in <a href="#section-7.2">Section 7.2</a>.

   These potential dangers for the network are explored in simulations
   and experiments described in the section below.  Our judgment is that
   while there are dangers of congestion collapse in the current
   Internet (see [<a href="#ref-FF99" title="&quot;http://www.icir.org/floyd/end2end-paper.html&quot;">FF99</a>] for a discussion of the dangers of congestion
   collapse from an increased deployment of UDP connections without
   end-to-end congestion control), there is no such danger to the
   network from increasing the TCP initial window to 4K bytes.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Interactions with the Retransmission Timer</span>

   Using a larger initial burst of data can exacerbate existing problems
   with spurious retransmit timeouts on low-bandwidth paths, assuming
   the standard algorithm for determining the TCP retransmission timeout
   (RTO) [<a href="./rfc2988" title="&quot;Computing TCP's Retransmission Timer&quot;">RFC2988</a>].  The problem is that across low-bandwidth network
   paths on which the transmission time of a packet is a large portion
   of the round-trip time, the small packets 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 retransmit
   timer could expire before the acknowledgments for those packets are
   received.  As each acknowledgment arrives, the retransmit timer is
   generally reset.  Thus, the retransmit timer will not expire as long
   as an acknowledgment arrives at least once a second, given the one-
   second minimum on the RTO recommended in <a href="./rfc2988">RFC 2988</a>.

   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
   transmission time of 2 packets (the SYN and SYN-ACK), each consisting
   of 40 bytes.  Using the RTO estimator given in [<a href="./rfc2988" title="&quot;Computing TCP's Retransmission Timer&quot;">RFC2988</a>], this yields
   an initial RTO of 201 msec (67 + 4*(67/2)).  However, we round the
   RTO to 1 second as specified in <a href="./rfc2988">RFC 2988</a>.  Then assume we send an
   initial window of one or more 1500-byte packets (1460 data bytes plus
   overhead).  Each packet will take on the order of 1.25 seconds to
   transmit.  Therefore, the RTO will fire before the ACK for the first
   packet returns, causing a spurious timeout.  In this case, a larger
   initial window of three or four packets exacerbates the problems
   caused by this spurious timeout.




<span class="grey">Allman, et. al.             Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   One way to deal with this problem is to make the RTO algorithm more
   conservative.  During the initial window of data, for instance, the
   RTO could be updated for each acknowledgment received.  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
   retransmit timer engaged until at least one valid RTT measurement,
   that involves a data packet, is received.

   Another method would be to refrain from taking an RTT sample during
   connection establishment, leaving the default RTO in place until TCP
   takes a sample from a data segment and the corresponding ACK.  While
   this method likely helps prevent spurious retransmits, it also may
   slow the data transfer down if loss occurs before the RTO is seeded.
   The use of limited transmit [<a href="./rfc3042" title="&quot;Enhancing TCP's Loss Recovery Using Limited Transmit&quot;">RFC3042</a>] to aid a TCP connection in
   recovering from loss using fast retransmit rather than the RTO timer
   mitigates the performance degradation caused by using the high
   default RTO during the initial window of data transmission.

   This specification leaves the decision about what to do (if anything)
   with regards to the RTO, when using a larger initial window, to the
   implementer.  However, the RECOMMENDED approach is to refrain from
   sampling the RTT during the three-way handshake, keeping the default
   RTO in place until an RTT sample involving a data packet is taken.
   In addition, it is RECOMMENDED that TCPs use limited transmit
   [<a href="./rfc3042" title="&quot;Enhancing TCP's Loss Recovery Using Limited Transmit&quot;">RFC3042</a>].

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Typical Levels of Burstiness for TCP Traffic.</span>

   Larger TCP initial windows would not dramatically increase the
   burstiness of TCP traffic in the Internet today, because such traffic
   is already fairly bursty.  Bursts of two and three segments are
   already typical of TCP [<a href="#ref-Flo97" title="&quot;ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps&quot;">Flo97</a>]; a delayed ACK (covering two
   previously unacknowledged segments) received during congestion
   avoidance causes the congestion window to slide and two segments to
   be sent.  The same delayed ACK received during slow start causes the
   window to slide by two segments and then be incremented by one
   segment, resulting in a 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 four previously unacknowledged segments.  During congestion
   avoidance this leads to a four-segment burst, and during slow start a
   five-segment burst is generated.

   There are also changes in progress that reduce the performance
   problems posed by moderate traffic bursts.  One such change is the
   deployment of higher-speed links in some parts of the network, where
   a burst of 4K bytes can represent a small quantity of data.  A second
   change, for routers with sufficient buffering, is the deployment of



<span class="grey">Allman, et. al.             Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


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

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Simulations and Experimental Results</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a> Studies of TCP Connections using that Larger Initial Window</span>

   This section surveys simulations and experiments that explore the
   effect of larger initial windows on TCP connections.  The first set
   of experiments explores performance over satellite links.  Larger
   initial windows have been shown to improve the performance of TCP
   connections over satellite channels [<a href="#ref-All97b" title="Ohio University">All97b</a>].  In this study, an
   initial window of four segments (512 byte MSS) resulted in throughput
   improvements of up to 30% (depending upon transfer size).  [<a href="#ref-KAGT98" title="&quot;http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps&quot;">KAGT98</a>]
   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 [<a href="#ref-Nic98" title="&quot;http://www.computer.org/proceedings/lcn/8810/8810toc.htm&quot;">Nic98</a>].

   A second set of experiments explored TCP performance over dialup
   modem links.  In experiments over a 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 the drop
   rate.  A simulation study [<a href="./rfc2416" title="&quot;When TCP Starts Up With Four Packets Into Only Three Buffers&quot;">RFC2416</a>] 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.  The study concluded that for the
   scenario investigated, the use of larger initial windows was not
   harmful to TCP performance.

   Finally, [<a href="#ref-All00" title="30(5)">All00</a>] illustrates that the percentage of connections at a
   particular web server that experience loss in the initial window of
   data transmission increases with the size of the initial congestion
   window.  However, the increase is in line with what would be expected
   from sending a larger burst into the network.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a> Studies of Networks using Larger Initial Windows</span>

   This section surveys simulations and experiments investigating the
   impact of the larger window on other TCP connections sharing the
   path.  Experiments in [<a href="#ref-All97a" title="1997. Washington">All97a</a>, <a href="#ref-AHO98" title="&quot;http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps&quot;">AHO98</a>] 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.





<span class="grey">Allman, et. al.             Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   A simulation study in [<a href="./rfc2415" title="&quot;Simulation Studies of Increased Initial TCP Window Size&quot;">RFC2415</a>] explores the impact of a larger
   initial window on competing network traffic.  In this investigation,
   HTTP and FTP flows share a single congested gateway (where the number
   of HTTP and FTP flows varies from one simulation set to another).
   For each simulation set, the paper examines aggregate link
   utilization and packet drop rates, median web page delay, and network
   power for the FTP transfers.  The larger initial window generally
   resulted in increased throughput, slightly-increased packet drop
   rates, and an increase in overall network power.  With the exception
   of one scenario, the larger initial window resulted in an increase in
   the drop rate of less than 1% above the loss rate experienced when
   using 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 to three packets (or 4380 bytes)
   helps to improve perceived performance.

   Morris [<a href="#ref-Mor97">Mor97</a>] investigated larger initial windows in a highly
   congested network with transfers of 20K in size.  The loss rate in
   networks where all TCP connections use an initial window of four
   segments is shown to be 1-2% greater than in a network where all
   connections use an initial window of 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 four segments, TCP connections
   spent more time waiting for the retransmit timer (RTO) to expire to
   resend a segment than was spent using an initial window of one
   segment.  The time spent waiting for the RTO timer to expire
   represents idle time when no useful work was being 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 one segment, using a larger initial window can
   cause a perceptible increase in both loss rates and retransmit
   timeouts.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

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

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Conclusion</span>

   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 (saving several RTTs during the initial slow-start phase).





<span class="grey">Allman, et. al.             Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgments</span>

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

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>

   [<a id="ref-AHO98">AHO98</a>]   Mark Allman, Chris Hayes, and Shawn Ostermann, An
             Evaluation of TCP with Larger Initial Windows, March 1998.
             ACM Computer Communication Review, 28(3), July 1998.  URL
             "<a href="http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps">http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps</a>".

   [<a id="ref-All97a">All97a</a>]  Mark Allman.  An Evaluation of TCP with Larger Initial
             Windows.  40th IETF Meeting -- TCP Implementations WG.
             December, 1997.  Washington, DC.

   [<a id="ref-All97b">All97b</a>]  Mark Allman.  Improving TCP Performance Over Satellite
             Channels.  Master's thesis, Ohio University, June 1997.

   [<a id="ref-All00">All00</a>]   Mark Allman. A Web Server's View of the Transport Layer.
             ACM Computer Communication Review, 30(5), October 2000.

   [<a id="ref-FF96">FF96</a>]    Fall, K., and Floyd, S., Simulation-based Comparisons of
             Tahoe, Reno, and SACK TCP.  Computer Communication Review,
             26(3), July 1996.

   [<a id="ref-FF99">FF99</a>]    Sally Floyd, Kevin Fall.  Promoting the Use of End-to-End
             Congestion Control in the Internet.  IEEE/ACM Transactions
             on Networking, August 1999.  URL
             "<a href="http://www.icir.org/floyd/end2end-paper.html">http://www.icir.org/floyd/end2end-paper.html</a>".

   [<a id="ref-FJ93">FJ93</a>]    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.

   [<a id="ref-Flo94">Flo94</a>]   Floyd, S., TCP and Explicit Congestion Notification.
             Computer Communication Review, 24(5):10-23, October 1994.

   [<a id="ref-Flo96">Flo96</a>]   Floyd, S., Issues of TCP with SACK. Technical report,
             January 1996.  Available from <a href="http://www-nrg.ee.lbl.gov/floyd/">http://www-</a>
             <a href="http://www-nrg.ee.lbl.gov/floyd/">nrg.ee.lbl.gov/floyd/</a>.

   [<a id="ref-Flo97">Flo97</a>]   Floyd, S., Increasing TCP's Initial Window.  Viewgraphs,
             40th IETF Meeting - TCP Implementations WG. December, 1997.
             URL "<a href="ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps">ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps</a>".




<span class="grey">Allman, et. al.             Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   [<a id="ref-KAGT98">KAGT98</a>]  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.  URL
             "<a href="http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps">http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps</a>".

   [<a id="ref-Mor97">Mor97</a>]   Robert Morris.  Private communication, 1997.  Cited for
             acknowledgement purposes only.

   [<a id="ref-Nic98">Nic98</a>]   Kathleen Nichols. Improving Network Simulation With
             Feedback, Proceedings of LCN 98, October 1998. URL
             "<a href="http://www.computer.org/proceedings/lcn/8810/8810toc.htm">http://www.computer.org/proceedings/lcn/8810/8810toc.htm</a>".

   [<a id="ref-Pos82">Pos82</a>]   Postel, J., "Simple Mail Transfer Protocol", STD 10, <a href="./rfc821">RFC</a>
             <a href="./rfc821">821</a>, August 1982.

   [<a id="ref-RFC1122">RFC1122</a>] Braden, R., "Requirements for Internet Hosts --
             Communication Layers", STD 3, <a href="./rfc1122">RFC 1122</a>, October 1989.

   [<a id="ref-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU Discovery", <a href="./rfc1191">RFC 1191</a>,
             November 1990.

   [<a id="ref-RFC1945">RFC1945</a>] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
             Transfer Protocol -- HTTP/1.0", <a href="./rfc1945">RFC 1945</a>, May 1996.

   [<a id="ref-RFC2068">RFC2068</a>] Fielding, R., Mogul, J., Gettys, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC</a>
             <a href="./rfc2616">2616</a>, January 1997.

   [<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2309">RFC2309</a>] 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 on Queue
             Management and Congestion Avoidance in the Internet", <a href="./rfc2309">RFC</a>
             <a href="./rfc2309">2309</a>, April 1998.

   [<a id="ref-RFC2414">RFC2414</a>] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
             Initial Window", <a href="./rfc2414">RFC 2414</a>, September 1998.

   [<a id="ref-RFC2415">RFC2415</a>] Poduri, K. and K. Nichols, "Simulation Studies of Increased
             Initial TCP Window Size", <a href="./rfc2415">RFC 2415</a>, September 1998.

   [<a id="ref-RFC2416">RFC2416</a>] Shepard, T. and C. Partridge, "When TCP Starts Up With Four
             Packets Into Only Three Buffers", <a href="./rfc2416">RFC 2416</a>, September 1998.




<span class="grey">Allman, et. al.             Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   [<a id="ref-RFC2581">RFC2581</a>] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
             Control", <a href="./rfc2581">RFC 2581</a>, April 1999.

   [<a id="ref-RFC2821">RFC2821</a>] Klensin, J., "Simple Mail Transfer Protocol", <a href="./rfc2821">RFC 2821</a>,
             April 2001.

   [<a id="ref-RFC2988">RFC2988</a>] Paxson, V. and M. Allman, "Computing TCP's Retransmission
             Timer", <a href="./rfc2988">RFC 2988</a>, November 2000.

   [<a id="ref-RFC3042">RFC3042</a>] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's
             Loss Recovery Using Limited Transmit", <a href="./rfc3042">RFC 3042</a>, January
             2001.

   [<a id="ref-RFC3168">RFC3168</a>] Ramakrishnan, K.K., Floyd, S. and D. Black, "The Addition
             of Explicit Congestion Notification (ECN) to IP", <a href="./rfc3168">RFC 3168</a>,
             September 2001.



































<span class="grey">Allman, et. al.             Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


Appendix A - Duplicate Segments

   In the current environment (without Explicit Congestion Notification
   [<a href="#ref-Flo94" title="S.">Flo94</a>] [<a href="./rfc2481">RFC2481</a>]), 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 by 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 [<a href="./rfc3042" title="&quot;Enhancing TCP's Loss Recovery Using Limited Transmit&quot;">RFC3042</a>].  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 <a href="#section-5">Section 5</a>.)

   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



<span class="grey">Allman, et. al.             Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


   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 in
   which more than one duplicate segment will be transmitted.  Our
   conclusion is than the number of duplicate segments transmitted as a
   result of a larger initial window should be small.

Author's Addresses

   Mark Allman
   BBN Technologies/NASA Glenn Research Center
   21000 Brookpark Rd
   MS 54-5
   Cleveland, OH 44135
   EMail: mallman@bbn.com
   <a href="http://roland.lerc.nasa.gov/~mallman/">http://roland.lerc.nasa.gov/~mallman/</a>

   Sally Floyd
   ICSI Center for Internet Research
   1947 Center St, Suite 600
   Berkeley, CA 94704
   Phone: +1 (510) 666-2989
   EMail: floyd@icir.org
   <a href="http://www.icir.org/floyd/">http://www.icir.org/floyd/</a>

   Craig Partridge
   BBN Technologies
   10 Moulton St
   Cambridge, MA 02138
   EMail: craig@bbn.com












<span class="grey">Allman, et. al.             Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3390">RFC 3390</a>            Increasing TCP's Initial Window         October 2002</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Allman, et. al.             Standards Track                    [Page 15]
</pre>