Browse Prior Art Database

The Congestion Manager (RFC3124) Disclosure Number: IPCOM000005310D
Original Publication Date: 2001-Jun-01
Included in the Prior Art Database: 2001-Aug-21
Document File: 23 page(s) / 54K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H. Balakrishnan: AUTHOR [+1]


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

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 6% of the total text.

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.


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


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


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.


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.


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.


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.


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


The number of bytes that has been transmitted by the source, but not known t...