The Congestion Manager
RFC 3124

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                    H. Balakrishnan
Request for Comments: 3124                                       MIT LCS
Category: Standards Track                                      S. Seshan
                                                                     CMU
                                                               June 2001

                         The Congestion Manager

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

Abstract

   This document describes the Congestion Manager (CM), an end-system
   module that:

   (i) Enables an ensemble of multiple concurrent streams from a sender
   destined to the same receiver and sharing the same congestion
   properties to perform proper congestion avoidance and control, and

   (ii) Allows applications to easily adapt to network congestion.

1. Conventions used in this document:

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

   STREAM

      A group of packets that all share the same source and destination
      IP address, IP type-of-service, transport protocol, and source and
      destination transport-layer port numbers.

Balakrishnan, et. al.       Standards Track                     [Page 1]
RFC 3124                 The Congestion Manager                June 2001

   MACROFLOW

      A group of CM-enabled streams that all use the same congestion
      management and scheduling algorithms, and share congestion state
      information.  Currently, streams destined to different receivers
      belong to different macroflows.  Streams destined to the same
      receiver MAY belong to different macroflows.  When the Congestion
      Manager is in use, streams that experience identical congestion
      behavior and use the same congestion control algorithm SHOULD
      belong to the same macroflow.

   APPLICATION

      Any software module that uses the CM.  This includes user-level
      applications such as Web servers or audio/video servers, as well
      as in-kernel protocols such as TCP [Postel81] that use the CM for
      congestion control.

   WELL-BEHAVED APPLICATION

      An application that only transmits when allowed by the CM and
      accurately accounts for all data that it has sent to the receiver
      by informing the CM using the CM API.

   PATH MAXIMUM TRANSMISSION UNIT (PMTU)

      The size of the largest packet that the sender can transmit
      without it being fragmented en route to the receiver.  It includes
      the sizes of all headers and data except the IP header.

   CONGESTION WINDOW (cwnd)

      A CM state variable that modulates the amount of outstanding data
      between sender and receiver.

   OUTSTANDING WINDOW (ownd)

      The number of bytes that has been transmitted by the source, but
      not known to have been either received by the destination or lost
      in the network.

   INITIAL WINDOW (IW)

      The size of the sender's congestion window at the beginning of a
      macroflow.

Balakrishnan, et. al.       Standards Track                     [Page 2]
RFC 3124                 The Congestion Manager                June 2001

   DATA TYPE SYNTAX

      We use "u64" for unsigned 64-bit, "u32" for unsigned 32-bit, "u16"
      for unsigned 16-bit, "u8" for unsigned 8-bit, "i32" for signed
      32-bit, "i16" for signed 16-bit quantities, "float" for IEEE
      floating point values.  The type "void" is used to indicate that
      no return value is expected from a call.  Pointers are referred to
      using "*" syntax, following C language convention.

      We emphasize that all the API functions described in this document
      are "abstract" calls and that conformant CM implementations may
      differ in specific implementation details.

2. Introduction

   The framework described in this document integrates congestion
   management across all applications and transport protocols.  The CM
   maintains congestion parameters (available aggregate and per-stream
   bandwidth, per-receiver round-trip times, etc.) and exports an API
   that enables applications to learn about network characteristics,
   pass information to the CM, share congestion information with each
   other, and schedule data transmissions.  This document focuses on
   applications and transport protocols with their own independent per-
   byte or per-packet sequence number information, and does not require