TCP Congestion Window Validation
RFC 2861

Document Type RFC - Historic (June 2000; Errata)
Obsoleted by RFC 7661
Authors Jitendra Padhye  , Sally Floyd , Mark Handley 
Last updated 2020-01-21
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2861 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Handley
Request for Comments: 2861                                     J. Padhye
Category: Experimental                                          S. Floyd
                                                               June 2000

                    TCP Congestion Window Validation

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 (2000).  All Rights Reserved.


   TCP's congestion window controls the number of packets a TCP flow may
   have in the network at any time.  However, long periods when the
   sender is idle or application-limited can lead to the invalidation of
   the congestion window, in that the congestion window no longer
   reflects current information about the state of the network.  This
   document describes a simple modification to TCP's congestion control
   algorithms to decay the congestion window cwnd after the transition
   from a sufficiently-long application-limited period, while using the
   slow-start threshold ssthresh to save information about the previous
   value of the congestion window.

   An invalid congestion window also results when the congestion window
   is increased (i.e., in TCP's slow-start or congestion avoidance
   phases) during application-limited periods, when the previous value
   of the congestion window might never have been fully utilized.  We
   propose that the TCP sender should not increase the congestion window
   when the TCP sender has been application-limited (and therefore has
   not fully used the current congestion window).  We have explored
   these algorithms both with simulations and with experiments from an
   implementation in FreeBSD.

1.  Conventions and Acronyms

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [B97].

Handley, et al.               Experimental                      [Page 1]
RFC 2861            TCP Congestion Window Validation           June 2000

2. Introduction

   TCP's congestion window controls the number of packets a TCP flow may
   have in the network at any time.  The congestion window is set using
   an Additive-Increase, Multiplicative-Decrease (AIMD) mechanism that
   probes for available bandwidth, dynamically adapting to changing
   network conditions.  This AIMD mechanism works well when the sender
   continually has data to send, as is typically the case for TCP used
   for bulk-data transfer.  In contrast, for TCP used with telnet
   applications, the data sender often has little or no data to send,
   and the sending rate is often determined by the rate at which data is
   generated by the user.  With the advent of the web, including
   developments such as TCP senders with dynamically-created data and
   HTTP 1.1 with persistent-connection TCP, the interaction between
   application-limited periods (when the sender sends less than is
   allowed by the congestion or receiver windows) and network-limited
   periods (when the sender is limited by the TCP window) becomes
   increasingly important.  More precisely, we define a network-limited
   period as any period when the sender is sending a full window of

   Long periods when the sender is application-limited can lead to the
   invalidation of the congestion window.  During periods when the TCP
   sender is network-limited, the value of the congestion window is
   repeatedly "revalidated" by the successful transmission of a window
   of data without loss.  When the TCP sender is network-limited, there
   is an incoming stream of acknowledgements that "clocks out" new data,
   giving concrete evidence of recent available bandwidth in the
   network.  In contrast, during periods when the TCP sender is
   application-limited, the estimate of available capacity represented
   by the congestion window may become steadily less accurate over time.
   In particular, capacity that had once been used by the network-
   limited connection might now be used by other traffic.

   Current TCP implementations have a range of behaviors for starting up
   after an idle period.  Some current TCP implementations slow-start
   after an idle period longer than the RTO estimate, as suggested in
   [RFC2581] and in the appendix of [VJ88], while other implementations
   don't reduce their congestion window after an idle period.  RFC 2581
   [RFC2581] recommends the following: "a TCP SHOULD set cwnd to no more
   than RW [the initial window] before beginning transmission if the TCP
   has not sent data in an interval exceeding the retransmission
Show full document text