The Congestion Manager
RFC 3124
| Document | Type |
RFC - Proposed Standard
(June 2001; No errata)
Was draft-ietf-ecm-cm (ecm WG)
|
|
|---|---|---|---|
| Authors | Hari Balakrishnan , Srinivasan Seshan | ||
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3124 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
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
Show full document text