rfc2414.txt

RFC 的详细文档！

Network Working Group                                          M. Allman
Request for Comments: 2414                  NASA Lewis/Sterling Software
Category: Experimental                                          S. Floyd
                                                                    LBNL
                                                            C. Partridge
                                                        BBN Technologies
                                                          September 1998


                    Increasing TCP's Initial Window

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document specifies an increase in the permitted initial window
   for TCP from one segment to roughly 4K bytes.  This document
   discusses the advantages and disadvantages of such a change,
   outlining experimental results that indicate the costs and benefits
   of such a change to TCP.

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 RFC 2119 [RFC2119].

1.  TCP Modification

   This document specifies an increase in the permitted upper bound for
   TCP's initial window from one segment 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 could be
   significantly larger than 4K bytes).  The upper bound for the initial
   window is given more precisely in (1):

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




Allman, et. al.               Experimental                      [Page 1]

RFC 2414            Increasing TCP's Initial Window       September 1998


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

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

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

   This upper bound for the initial window size represents a change 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 in the
   first round trip time (RTT) of 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.

   TCP implementations use slow start in as many as three different
   ways: (1) to start a new connection (the initial window); (2) to
   restart a transmission after a long idle period (the restart window);
   and (3) to restart after a retransmit timeout (the loss window).  The
   change proposed 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 (to permit the lowest
   possible window size in the case of severe congestion).

2.  Implementation Issues

   When larger initial windows are implemented along with Path MTU
   Discovery [MD90], 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.





Allman, et. al.               Experimental                      [Page 2]

RFC 2414            Increasing TCP's Initial Window       September 1998


   When larger initial windows are implemented along with Path MTU
   Discovery [MD90], 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
   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 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 proposed in this document is not intended
   as an 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, this works
   against TCP's congestion control mechanisms [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 at
       most 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





Allman, et. al.               Experimental                      [Page 3]

RFC 2414            Increasing TCP's Initial Window       September 1998


       would be of particular benefit for high-bandwidth large-
       propagation-delay TCP connections, such as those over 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 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,
   RFC2309]).

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




Allman, et. al.               Experimental                      [Page 4]

RFC 2414            Increasing TCP's Initial Window       September 1998


   Duplicate segments:

       As described in the previous section, the larger initial 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 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