Increasing TCP's Initial Window
RFC 2414

Document Type RFC - Experimental (September 1998; No errata)
Obsoleted by RFC 3390
Authors Craig Partridge  , Sally Floyd  , Mark Allman 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2414 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          M. Allman
Request for Comments: 2414                  NASA Lewis/Sterling Software
Category: Experimental                                          S. Floyd
                                                            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.


   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.


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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
Show full document text