Specification of the Controlled-Load Network Element Service
RFC 2211
|
Document |
Type |
|
RFC - Proposed Standard
(September 1997; No errata)
|
|
Author |
|
John Wroclawski
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Internent 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 2211 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group J. Wroclawski
Request For Comments: 2211 MIT LCS
Category: Standards Track September 1997
Specification of the Controlled-Load Network Element Service
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.
Abstract
This memo specifies the network element behavior required to deliver
Controlled-Load service in the Internet. Controlled-load service
provides the client data flow with a quality of service closely
approximating the QoS that same flow would receive from an unloaded
network element, but uses capacity (admission) control to assure that
this service is received even when the network element is overloaded.
1. Introduction
This document defines the requirements for network elements that
support the Controlled-Load service. This memo is one of a series of
documents that specify the network element behavior required to
support various qualities of service in IP internetworks. Services
described in these documents are useful both in the global Internet
and private IP networks.
This document is based on the service specification template given in
[1]. Please refer to that document for definitions and additional
information about the specification of qualities of service within
the IP protocol family.
Wroclawski Standards Track [Page 1]
RFC 2211 Controlled-Load Network September 1997
2. End-to-End Behavior
The end-to-end behavior provided to an application by a series of
network elements providing controlled-load service tightly
approximates the behavior visible to applications receiving best-
effort service *under unloaded conditions* from the same series of
network elements. Assuming the network is functioning correctly,
these applications may assume that:
- A very high percentage of transmitted packets will be
successfully delivered by the network to the receiving end-nodes.
(The percentage of packets not successfully delivered must closely
approximate the basic packet error rate of the transmission
medium).
- The transit delay experienced by a very high percentage of the
delivered packets will not greatly exceed the minimum transmit
delay experienced by any successfully delivered packet. (This
minimum transit delay includes speed-of-light delay plus the fixed
processing time in routers and other communications devices along
the path.)
To ensure that these conditions are met, clients requesting
controlled-load service provide the intermediate network elements
with a estimation of the data traffic they will generate; the TSpec.
In return, the service ensures that network element resources
adequate to process traffic falling within this descriptive envelope
will be available to the client. Should the client's traffic
generation properties fall outside of the region described by the
TSpec parameters, the QoS provided to the client may exhibit
characteristics indicative of overload, including large numbers of
delayed or dropped packets. The service definition does not require
that the precise characteristics of this overload behavior match
those which would be received by a best-effort data flow traversing
the same path under overloaded conditions.
NOTE: In this memo, the term "unloaded" is used in the sense of
"not heavily loaded or congested" rather than in the sense of "no
other network traffic whatsoever".
3. Motivation
The controlled load service is intended to support a broad class of
applications which have been developed for use in today's Internet,
but are highly sensitive to overloaded conditions. Important members
of this class are the "adaptive real-time applications" currently
Wroclawski Standards Track [Page 2]
RFC 2211 Controlled-Load Network September 1997
offered by a number of vendors and researchers. These applications
have been shown to work well on unloaded nets, but to degrade quickly
under overloaded conditions. A service which mimics unloaded nets
serves these applications well.
The controlled-load service is intentionally minimal, in that there
are no optional functions or capabilities in the specification. The
service offers only a single function, and system and application
designers can assume that all implementations will be identical in
this respect.
Show full document text