rfc1363.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                     C. Partridge
Request for Comments: 1363                                         BBN
                                                        September 1992


                     A Proposed Flow Specification

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   A flow specification (or "flow spec") is a data structure used by
   internetwork hosts to request special services of the internetwork,
   often guarantees about how the internetwork will handle some of the
   hosts' traffic.  In the future, hosts are expected to have to request
   such services on behalf of distributed applications such as
   multimedia conferencing.

   The flow specification defined in this memo is intended for
   information and possible experimentation (i.e., experimental use by
   consenting routers and applications only).  This RFC is a product of
   the Internet Research Task Force (IRTF).

Introduction

   The Internet research community is currently studying the problems of
   supporting a new suite of distributed applications over
   internetworks.  These applications, which include multimedia
   conferencing, data fusion, visualization, and virtual reality, have
   the property that they require the distributed system (the collection
   of hosts that support the applications along with the internetwork to
   which they are attached) be able to provide guarantees about the
   quality of communication between applications.  For example, a video
   conference may require a certain minimum bandwidth to be sure that
   the video images are delivered in a timely way to all recipients.

   One way for the distributed system to provide guarantees is for hosts
   to negotiate with the internetwork for rights to use a certain part
   of the internetwork's resources.  (An alternative is to have the
   internetwork infer the hosts' needs from information embedded in the
   data traffic each host injects into the network.  Currently, it is
   not clear how to make this scheme work except for a rather limited
   set of traffic classes.)




Partridge                                                       [Page 1]

RFC 1363             A Proposed Flow Specification        September 1992


   There are a number of ways to effect a negotiation.  For example a
   negotiation can be done in-band or out-of-band.  It can also be done
   in advance of sending data (possibly days in advance), as the first
   part of a connection setup, or concurrently with sending (i.e., a
   host starts sending data and starts a negotiation to try to ensure
   that it will allowed to continue sending).  Insofar as is possible,
   this memo is agnostic with regard to the variety of negotiation that
   is to be done.

   The purpose of this memo is to define a data structure, called a flow
   specification or flow spec, that can be used as part of the
   negotiation to describe the type of service that the hosts need from
   the internetwork.  This memo defines the format of the fields of the
   data structure and their interpretation.  It also briefly describes
   what purpose the different fields fill, and discusses why this set of
   fields is thought to be both necessary and sufficient.

   It is important to note that the goal of this flow spec is to able to
   describe *any* flow requirement, both for guaranteed flows and for
   applications that simply want to give hints to the internetwork about
   their requirements.

Format of the Flow Spec

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Version          |    Maximum Transmission Unit  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Token Bucket Rate        |        Token Bucket Size      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Maximum Transmission Rate    |     Minimum Delay Noticed     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Maximum Delay Variation   |        Loss Sensitivity       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Burst Loss Sensitivity    |          Loss Interval        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Quality of Guarantee       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Discussion of the Flow Spec

   The flow spec indicates service requirements for a single direction.
   Multidirectional flows will need to request services in both
   directions (using two flow specs).

   To characterize a unidirectional flow, the flow spec needs to do four
   things.



Partridge                                                       [Page 2]

RFC 1363             A Proposed Flow Specification        September 1992


   First, it needs to characterize how the flow's traffic will be
   injected into the internetwork.  If the internetwork doesn't know
   what to expect (is it a gigabit-per-second flow or a three kilobit-
   per-second flow?) then it is difficult for the internetwork to make
   guarantees.  (Note the word "difficult" rather than "impossible."  It
   may be possible to statistically manage traffic or over-engineer the
   network so well that the network can accept almost all flows, without
   setup.  But this problem looks far harder than asking the sender to
   approximate its behavior so the network can plan.)  In this flow
   spec, injected traffic is characterized as having a sustainable rate
   (the token bucket rate) a peak rate (the maximum transmission rate),
   and an approximate burst size (the token bucket size).  A more
   precise definition of each of these fields is given below.  The
   characterization is based, in part, on the work done in [1].

   Second, the flow spec needs to characterize sensitivity to delay.
   Some applications are more sensitive than others.  At the same time,
   the internetwork will likely have a choice of routes with various
   delays available from the source to destination.  For example, both
   routes using satellites (which have very long delays) and routes
   using terrestrial lines (which will have shorter delays) may be
   available.  So the sending host needs to indicate the flow's
   sensitivity to delay.  However, this field is only advisory.  It only
   tells the network when to stop trying to reduce the delay - it does
   not specify a maximum acceptable delay.

   There are two problems with allowing applications to specify the
   maximum acceptable delay.

   First, observe that an application would probably be happy with a
   maximum delay of 100 ms between the US and Japan but very unhappy
   with a delay of 100 ms within the same city.  This observation
   suggests that the maximum delay is actually variable, and is a
   function of the delay that is considered achievable.  But the
   achievable delay is largely determined by the geographic distance
   between the two peers, and this sort of geographical information is
   usually not available from a network.  Worse yet, the advent of
   mobile hosts makes such information increasingly hard to provide.  So
   there is reason to believe that applications may have difficulty
   choosing a rational maximum delay.

   The second problem with maximum delays is that they are an attempt to
   quantify what performance is acceptable to users, and an application
   usually does not know what performance will be acceptable its user.
   For example, a common justification for specifying a maximum
   acceptable delay is that human users find it difficult to talk to
   each other over a link with more than about 100 ms of delay.
   Certainly such delays can make the conversation less pleasant, but it



Partridge                                                       [Page 3]

RFC 1363             A Proposed Flow Specification        September 1992


   is still possible to converse when delays are several seconds long,
   and given a choice between no connection and a long delay, many users
   will pick the delay.  (The phone call may involve an important matter
   that must be resolved.)

   As part of specifying a flow's delay sensitivity, the flow spec must
   also characterize how sensitive the flow is to the distortion of its
   data stream.

   Packets injected into a network according to some pattern will not
   normally come out of the network still conforming to the pattern.
   Instead, the pattern will have been distorted by queueing effects in
   the network.  Since there is reason to believe that it may make
   network design easier to continue to allow the networks slightly
   distort traffic patterns, it is expected that those applications
   which are sensitive to distortion will require their hosts to use
   some amount of buffering to reshape the flow back into its original
   form.  It seems reasonable to assume that buffer space is not
   infinite and that a receiving system will wish to limit the amount of
   buffering that a single flow can use.

   The amount of buffer space required for removing distortion at the
   receiving system is determined by the variation in end-to-end
   transmission delays for data sent over the flow.  If the transmission
   delay is a mean delay, D, plus or minus a variance, V, the receiving
   system needs buffer space equivalent to 2 * V * the transmission
   rate.  To see why this is so, consider two packets, A and B, sent T
   time units apart which must be delivered to the receiving application
   T time units apart.  In the worst case, A arrives after a delay of
   D-V time units (the minimum delay) and B arrives after a delay of D+V
   time units (the maximum delay).  The receiver cannot deliver B until
   it arrives, which is T + 2 * V time units after A.  To ensure that A
   is delivered T time units before B, A must be buffered for 2 * V time
   units.  The delay variance field is the value of 2 * V, and allows
   the receiver to indicate how much buffering it is willing to provide.

   A third function of the flow spec is to signal sensitivity to loss of
   data.  Some applications are more sensitive to the loss of their data
   than other applications.  Some real-time applications are both
   sensitive to loss and unable to wait for retransmissions of data.
   For these particularly sensitive applications, hosts may implement
   forward error correction on a flow to try to absolutely minimize
   loss.  The loss fields allow hosts to request loss properties
   appropriate for the application's requirements.

   Finally, it is expected that the internetwork may be able to provide
   a range of service guarantees.  At the best, the internetwork may be
   asked to guarantee (with tight probability bounds) the quality of



Partridge                                                       [Page 4]

RFC 1363             A Proposed Flow Specification        September 1992


   service it will provide.  Or the internetwork may simply be asked to
   ensure that packets sent over the flow take a terrestrial path.  The
   quality of guarantee field indicates what type of service guarantee
   the application desires.

Definition of Individual Fields

General Format of Fields

   With a few exceptions, fields of the flow spec are expressed using a
   common 16-bit format.  This format has two forms.  The first form is
   shown below.

               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |0|  Exponent   |     Value     |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this format, the first bit is 0, followed by 7 bits of an exponent
   (E), and an 8-bit value (V).  This format encodes a number, of the
   form V * (2**E).  This representation was chosen to allow easy
   representation of a wide range of values, while avoiding over-precise
   representations.

   In some case, systems will not wish to request a precise value but
   rather simply indicate some sensitivity.  For example, a virtual
   terminal application like Telnet will likely want to indicate that it
   is sensitive to delay, but it may not be worth expressing particular
   delay values for the network to try to achieve.  For these cases,
   instead of a number, the field in the flow spec will take the
   following form:

               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |1|   Well-defined Constant     |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first bit of the field is one, and is followed by a 15-bit
   constant.  The values of the constants for given fields are defined
   below.  Any additional values can be requested from the Internet
   Assigned Numbers Authority (IANA).

   Version Field

      This field is a 16-bit integer in Internet byte order.  It is the
      version number of the flow specification.  The version number of
      the flow specification defined in this document is 1.  The IANA is
      responsible for assigning future version numbers for any proposed