rfc2211.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,068 行 · 第 1/4 页

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.

   Internally, the controlled-load service is suited to a wide range of
   implementation techniques, including evolving scheduling and
   admission control algorithms that allow implementations to be highly
   efficient in the use of network resources. It is equally amenable to
   extremely simple implementation in circumstances where maximum
   utilization of network resources is not the only concern.

4. Network Element Data Handling Requirements

   Each network element accepting a request for controlled-load service
   must ensure that adequate bandwidth and packet processing resources
   are available to handle the requested level of traffic, as given by
   the requestor's TSpec. This must be accomplished through active
   admission control. All resources important to the operation of the
   network element must be considered when admitting a request. Common
   examples of such resources include link bandwidth, router or switch
   port buffer space, and computational capacity of the packet
   forwarding engine.

   The controlled-load service does not accept or make use of specific
   target values for control parameters such as delay or loss. Instead,
   acceptance of a request for controlled-load service is defined to
   imply a commitment by the network element to provide the requestor
   with service closely equivalent to that provided to uncontrolled
   (best-effort) traffic under lightly loaded conditions.

   The definition of "closely equivalent to unloaded best-effort
   service" is necessarily imprecise. It is easiest to define this
   quality of service by describing the events which are expected to
   *not* occur with any frequency. A flow receiving controlled-load
   service at a network element may expect to experience:









Wroclawski                 Standards Track                      [Page 3]

RFC 2211                Controlled-Load Network           September 1997


     - Little or no average packet queueing delay over all timescales
     significantly larger than the "burst time". The burst time is
     defined as the time required for the flow's maximum size data burst
     to be transmitted at the flow's requested transmission rate, where
     the burst size and rate are given by the flow's TSpec, as described
     below.

     - Little or no congestion loss over all timescales significantly
     larger than the "burst time" defined above.  In this context,
     congestion loss includes packet losses due to shortage of any
     required processing resource, such as buffer space or link
     bandwidth.  Although occasional congestion losses may occur, any
     substantial sustained loss represents a failure of the admission
     control algorithm.

   The basic effect of this language is to establish an expectation on
   the *duration* of a disruption in delivery service. Events of shorter
   duration are viewed as statistical effects which may occur in normal
   operation. Events of longer duration are indicative of failure to
   allocate adequate capacity to the controlled-load flow.

   A network element may employ statistical approaches to decide whether
   adequate capacity is available to accept a service request. For
   example, a network element processing a number of flows with long-
   term characteristics predicted through measurement of past behavior
   may be able to overallocate its resources to some extent without
   reducing the level of service delivered to the flows.

   A network element may employ any appropriate scheduling means to
   ensure that admitted flows receive appropriate service.

      NOTE: The flexibility implied by the above paragraph exists within
      definite limits. Readers should observe that the specification's
      requirement that the delay and loss behavior described above
      imposes concrete requirements on implementations.

      Perhaps the most important requirement is that the implementation
      has to make bandwidth greater than the Tspec token rate available
      to the flow in certain situations. The requirement for the
      availability of extra bandwidth may be derived from the fluid
      model of traffic scheduling (e.g. [7]). If a flow receives exactly
      its promised token rate at all times, queueing caused by an over-
      rate burst arriving at the network element may never clear,
      causing the traffic queueing delay to permanantly increase. This
      will happen if the flow continues to generate traffic at exactly
      the token rate after emitting the burst.





Wroclawski                 Standards Track                      [Page 4]

RFC 2211                Controlled-Load Network           September 1997


      To control the long-term effects of traffic bursts, a Controlled
      Load implementation has several options. At minimum, a mechanism
      must be present to "borrow" bandwidth needed to clear bursts from
      the network. There are a number of ways to implement such a
      mechanism, ranging from explicit borrowing schemes within the
      traffic scheduler to implicit schemes based on statistical
      multiplexing and measurement-based admission control. The
      specification does not prefer any method over any other, but does
      require that some such mechanism must exist.

      Similarly, the requirement for low congestion loss for in-Tspec
      traffic implies that buffer management must have some flexibility.
      Because the controlled-load service does not reshape traffic to
      its token-bucket parameters at every node, traffic flowing through
      the network will be distorted as it traverses queueing points.
      This distortion is particularly likely to occur during traffic
      bursts, precisely when buffering is most heavily used. In these
      circumstances, rigidly restricting the buffering capacity to a
      size equal to the flow's TSpec burst size may lead to congestion
      loss. An implementaton should be prepared to make additional
      buffering available to bursting flows. Again, this may be
      accomplished in a number of ways. One obvious choice is
      statistical multiplexing of a shared buffer pool.

   Links are not permitted to fragment packets which receive the
   controlled-load service. Packets larger than the MTU of the link must
   be treated as nonconformant to the TSpec. This implies that they will
   be forwarded according to the rules described in the Policing section
   below.

   Implementations of controlled-load service are not required to
   provide any control of short-term packet delay jitter beyond that
   described above. However, the use of packet scheduling algorithms
   that provide additional jitter control is not prohibited by this
   specification.

   Packet losses due to non-congestion-related causes, such as link