TCP Congestion Control
RFC 2581

Document Type RFC - Proposed Standard (April 1999; Errata)
Obsoleted by RFC 5681
Updated by RFC 3390
Obsoletes RFC 2001
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2581 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          M. Allman
Request for Comments: 2581                  NASA Glenn/Sterling Software
Obsoletes: 2001                                                V. Paxson
Category: Standards Track                                   ACIRI / ICSI
                                                              W. Stevens
                                                              Consultant
                                                              April 1999

                         TCP Congestion Control

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

Abstract

   This document defines TCP's four intertwined congestion control
   algorithms: slow start, congestion avoidance, fast retransmit, and
   fast recovery.  In addition, the document specifies how TCP should
   begin transmission after a relatively long idle period, as well as
   discussing various acknowledgment generation methods.

1. Introduction

   This document specifies four TCP [Pos81] congestion control
   algorithms: slow start, congestion avoidance, fast retransmit and
   fast recovery.  These algorithms were devised in [Jac88] and [Jac90].
   Their use with TCP is standardized in [Bra89].

   This document is an update of [Ste97].  In addition to specifying the
   congestion control algorithms, this document specifies what TCP
   connections should do after a relatively long idle period, as well as
   specifying and clarifying some of the issues pertaining to TCP ACK
   generation.

   Note that [Ste94] provides examples of these algorithms in action and
   [WS95] provides an explanation of the source code for the BSD
   implementation of these algorithms.

Allman, et. al.             Standards Track                     [Page 1]
RFC 2581                 TCP Congestion Control               April 1999

   This document is organized as follows.  Section 2 provides various
   definitions which will be used throughout the document.  Section 3
   provides a specification of the congestion control algorithms.
   Section 4 outlines concerns related to the congestion control
   algorithms and finally, section 5 outlines security considerations.

   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 [Bra97].

2. Definitions

   This section provides the definition of several terms that will be
   used throughout the remainder of this document.

   SEGMENT:
      A segment is ANY TCP/IP data or acknowledgment packet (or both).

   SENDER MAXIMUM SEGMENT SIZE (SMSS):  The SMSS is the size of the
      largest segment that the sender can transmit.  This value can be
      based on the maximum transmission unit of the network, the path
      MTU discovery [MD90] algorithm, RMSS (see next item), or other
      factors.  The size does not include the TCP/IP headers and
      options.

   RECEIVER MAXIMUM SEGMENT SIZE (RMSS):  The RMSS is the size of the
      largest segment the receiver is willing to accept.  This is the
      value specified in the MSS option sent by the receiver during
      connection startup.  Or, if the MSS option is not used, 536 bytes
      [Bra89].  The size does not include the TCP/IP headers and
      options.

   FULL-SIZED SEGMENT: A segment that contains the maximum number of
      data bytes permitted (i.e., a segment containing SMSS bytes of
      data).

   RECEIVER WINDOW (rwnd) The most recently advertised receiver window.

   CONGESTION WINDOW (cwnd):  A TCP state variable that limits the
      amount of data a TCP can send.  At any given time, a TCP MUST NOT
      send data with a sequence number higher than the sum of the
      highest acknowledged sequence number and the minimum of cwnd and
      rwnd.

   INITIAL WINDOW (IW):  The initial window is the size of the sender's
      congestion window after the three-way handshake is completed.

Allman, et. al.             Standards Track                     [Page 2]
RFC 2581                 TCP Congestion Control               April 1999

   LOSS WINDOW (LW):  The loss window is the size of the congestion
      window after a TCP sender detects loss using its retransmission
      timer.

   RESTART WINDOW (RW):  The restart window is the size of the
      congestion window after a TCP restarts transmission after an idle
      period (if the slow start algorithm is used; see section 4.1 for
      more discussion).

   FLIGHT SIZE:  The amount of data that has been sent but not yet
Show full document text