Gateway Congestion Control Survey
RFC 1254
Document | Type |
RFC - Informational
(August 1991; No errata)
Was draft-ietf-pcc-gwcc (pcc WG)
|
|
---|---|---|---|
Authors | |||
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 1254 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group A. Mankin Request for Comments: 1254 MITRE K. Ramakrishnan Digital Equipment Corporation Editors August 1991 Gateway Congestion Control Survey Status of this Memo This memo provides information for the Internet community. It is a survey of some of the major directions and issues. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract The growth of network intensive Internet applications has made gateway congestion control a high priority. The IETF Performance and Congestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches. The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing. The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion. 1. Introduction Internet users regularly encounter congestion, often in mild forms. However, severe congestion episodes have been reported also; and gateway congestion remains an obstacle for Internet applications such as scientific supercomputing data transfer. The need for Internet congestion control originally became apparent during several periods of 1986 and 1987, when the Internet experienced the "congestion collapse" condition predicted by Nagle [Nag84]. A large number of widely dispersed Internet sites experienced simultaneous slowdown or cessation of networking services for prolonged periods. BBN, the firm responsible for maintaining the then backbone of the Internet, the ARPANET, responded to the collapse by adding link capacity [Gar87]. Much of the Internet now uses as a transmission backbone the National Science Foundation Network (NSFNET). Extensive monitoring and capacity planning are being done for the NSFNET backbone; still, as Performance and Congestion Control Working Group [Page 1] RFC 1254 Gateway Congestion Control Survey August 1991 the demand for this capacity grows, and as resource-intensive applications such as wide-area file system management [Sp89] increasingly use the backbone, effective congestion control policies will be a critical requirement. Only a few mechanisms currently exist in Internet hosts and gateways to avoid or control congestion. The mechanisms for handling congestion set forth in the specifications for the DoD Internet protocols are limited to: Window flow control in TCP [Pos81b], intended primarily for controlling the demand on the receiver's capacity, both in terms of processing and buffers. Source quench in ICMP, the message sent by IP to request that a sender throttle back [Pos81a]. One approach to enhancing Internet congestion control has been to overlay the simple existing mechanisms in TCP and ICMP with more powerful ones. Since 1987, the TCP congestion control policy, Slow- start, a collection of several algorithms developed by Van Jacobson and Mike Karels [Jac88], has been widely adopted. Successful Internet experiences with Slow-start led to the Host Requirements RFC [HREQ89] classifying the algorithms as mandatory for TCP. Slow-start modifies the user's demand when congestion reaches such a point that packets are dropped at the gateway. By the time such overflows occur, the gateway is congested. Jacobson writes that the Slow-start policy is intended to function best with a complementary gateway policy [Jac88]. 1.1 Definitions The characteristics of the Internet that we are interested in include that it is, in general, an arbitrary mesh-connected network. The internetwork protocol is connectionless. The number of users that place demands on the network is not limited by any explicit mechanism; no reservation of resources occurs and transport layer set-ups are not disallowed due to lack of resources. A path from a source to destination host may have multiple hops, through several gateways and links. Paths through the Internet may be heterogeneous (though homogeneous paths also exist and experience congestion). That is, links may be of different speeds. Also, the gateways and hosts may be of different speeds or may be providing only a part of their processing power to communication-related activity. The buffers for storing information flowing through Internet gateways areShow full document text