rfc3124.txt

RFC 的详细文档！

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
   modifications to the receiver protocol stack.  However, the receiving
   application must provide feedback to the sending application about
   received packets and losses, and the latter is expected to use the CM
   API to update CM state.  This document does not address networks with
   reservations or service differentiation.

   The CM is an end-system module that enables an ensemble of multiple
   concurrent streams to perform stable congestion avoidance and
   control, and allows applications to easily adapt their transmissions
   to prevailing network conditions.  It integrates congestion
   management across all applications and transport protocols.  It
   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.  When the CM is used, all
   data transmissions subject to the CM must be done with the explicit
   consent of the CM via this API to ensure proper congestion behavior.

   Systems MAY choose to use CM, and if so they MUST follow this
   specification.

   This document focuses on applications and networks where the
   following conditions hold:



Balakrishnan, et. al.       Standards Track                     [Page 3]

RFC 3124                 The Congestion Manager                June 2001


   1. Applications are well-behaved with their own independent
      per-byte or per-packet sequence number information, and use the
      CM API to update internal state in the CM.

   2. Networks are best-effort without service discrimination or
      reservations.  In particular, it does not address situations
      where different streams between the same pair of hosts traverse
      paths with differing characteristics.

   The Congestion Manager framework can be extended to support
   applications that do not provide their own feedback and to
   differentially-served networks.  These extensions will be addressed
   in later documents.

   The CM is motivated by two main goals:

   (i) Enable efficient multiplexing.  Increasingly, the trend on the
   Internet is for unicast data senders (e.g., Web servers) to transmit
   heterogeneous types of data to receivers, ranging from unreliable
   real-time streaming content to reliable Web pages and applets.  As a
   result, many logically different streams share the same path between
   sender and receiver.  For the Internet to remain stable, each of
   these streams must incorporate control protocols that safely probe
   for spare bandwidth and react to congestion.  Unfortunately, these
   concurrent streams typically compete with each other for network
   resources, rather than share them effectively.  Furthermore, they do
   not learn from each other about the state of the network.  Even if
   they each independently implement congestion control (e.g., a group
   of TCP connections each implementing the algorithms in [Jacobson88,
   Allman99]), the ensemble of streams tends to be more aggressive in
   the face of congestion than a single TCP connection implementing
   standard TCP congestion control and avoidance [Balakrishnan98].

   (ii) Enable application adaptation to congestion.  Increasingly,
   popular real-time streaming applications run over UDP using their own
   user-level transport protocols for good application performance, but
   in most cases today do not adapt or react properly to network
   congestion.  By implementing a stable control algorithm and exposing
   an adaptation API, the CM enables easy application adaptation to
   congestion.  Applications adapt the data they transmit to the current
   network conditions.

   The CM framework builds on recent work on TCP control block sharing
   [Touch97], integrated TCP congestion control (TCP-Int)
   [Balakrishnan98] and TCP sessions [Padmanabhan98].  [Touch97]
   advocates the sharing of some of the state in the TCP control block
   to improve transient transport performance and describes sharing
   across an ensemble of TCP connections.  [Balakrishnan98],



Balakrishnan, et. al.       Standards Track                     [Page 4]

RFC 3124                 The Congestion Manager                June 2001


   [Padmanabhan98], and [Eggert00] describe several experiments that
   quantify the benefits of sharing congestion state, including improved
   stability in the face of congestion and better loss recovery.
   Integrating loss recovery across concurrent connections significantly
   improves performance because losses on one connection can be detected
   by noticing that later data sent on another connection has been
   received and acknowledged.  The CM framework extends these ideas in
   two significant ways: (i) it extends congestion management to non-TCP
   streams, which are becoming increasingly common and often do not
   implement proper congestion management, and (ii) it provides an API
   for applications to adapt their transmissions to current network
   conditions.  For an extended discussion of the motivation for the CM,
   its architecture, API, and algorithms, see [Balakrishnan99]; for a
   description of an implementation and performance results, see
   [Andersen00].

   The resulting end-host protocol architecture at the sender is shown
   in Figure 1.  The CM helps achieve network stability by implementing
   stable congestion avoidance and control algorithms that are "TCP-
   friendly" [Mahdavi98] based on algorithms described in [Allman99].
   However, it does not attempt to enforce proper congestion behavior
   for all applications (but it does not preclude a policer on the host
   that performs this task).  Note that while the policer at the end-
   host can use CM, the network has to be protected against compromises
   to the CM and the policer at the end hosts, a task that requires
   router machinery [Floyd99a].  We do not address this issue further in
   this document.
























Balakrishnan, et. al.       Standards Track                     [Page 5]

RFC 3124                 The Congestion Manager                June 2001


   |--------| |--------| |--------| |--------|       |--------------|
   |  HTTP  | |  FTP   | |  RTP 1 | |  RTP 2 |       |              |
   |--------| |--------| |--------| |--------|       |              |
       |          |         |  ^       |  ^          |              |
       |          |         |  |       |  |          |   Scheduler  |
       |          |         |  |       |  |  |---|   |              |
       |          |         |  |-------|--+->|   |   |              |
       |          |         |          |     |   |<--|              |
       v          v         v          v     |   |   |--------------|
   |--------| |--------|  |-------------|    |   |           ^
   |  TCP 1 | |  TCP 2 |  |    UDP 1    |    | A |           |
   |--------| |--------|  |-------------|    |   |           |
      ^   |      ^   |              |        |   |   |--------------|
      |   |      |   |              |        | P |-->|              |
      |   |      |   |              |        |   |   |              |
      |---|------+---|--------------|------->|   |   |  Congestion  |
          |          |              |        | I |   |              |
          v          v              v        |   |   |  Controller  |
     |-----------------------------------|   |   |   |              |
     |               IP                  |-->|   |   |              |
     |-----------------------------------|   |   |   |--------------|
                                             |---|