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 | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) 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 requireShow full document text