Increasing TCP's Initial Window
RFC 3390

Document Type RFC - Proposed Standard (November 2002; Errata)
Obsoletes RFC 2414
Updates RFC 2581
Authors Craig Partridge  , Mark Allman  , Sally Floyd 
Last updated 2020-01-21
Stream IETF
Formats plain text html pdf htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3390 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note Published as RFC 3390 [Note from Allison]
Send notices to <>, <>
Network Working Group                                          M. Allman
Request for Comments: 3390                                  BBN/NASA GRC
Obsoletes: 2414                                                 S. Floyd
Updates: 2581                                                       ICIR
Category: Standards Track                                   C. Partridge
                                                        BBN Technologies
                                                            October 2002

                    Increasing TCP's Initial Window

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.


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


   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 obsoletes [RFC2414] and updates [RFC2581] 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

Allman, et. al.             Standards Track                     [Page 1]
RFC 3390            Increasing TCP's Initial Window         October 2002

   The upper bound for the initial window is given more precisely in

         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 <= 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: 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
   RFC 2581 [RFC2581], 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

Allman, et. al.             Standards Track                     [Page 2]
RFC 3390            Increasing TCP's Initial Window         October 2002

   permit the lowest possible window size in the case of severe

2.  Implementation Issues

   When larger initial windows are implemented along with Path MTU
Show full document text