rfc1363.txt

RFC 的详细文档！

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


      revisions of this flow specification.

      This field does not use the general field format.

   Maximum Transmission Unit (MTU)

      A 16-bit integer in Internet byte order which is the maximum
      number of bytes in the largest possible packet to be transmitted
      over this flow.

      This field does not use the general field format.

      The field serves two purposes.

      It is a convenient unit for expressing loss properties.  Using the
      default MTU of the internetwork is inappropriate since the
      internetwork have very large MTU, such the 64Kbytes of IP, but
      applications and hosts may be sensitive to losses of far less than
      an MTU's amount of data -- for example, a voice application would
      be sensitive to a loss of several consecutive small packets.

      The MTU also bounds the amount of time that a flow can transmit,
      uninterrupted, on a shared media.

      Similarly, the loss rates of links that suffer bit errors will
      vary dramatically based on the MTU size.

   Token Bucket Rate

      The token bucket rate is one of three fields used to define how
      traffic will be injected into the internetwork by the sending
      application.  (The other two fields are the token bucket size and
      the maximum transmission rate.)

      The token rate is the rate at which tokens (credits) are placed
      into an imaginary token bucket.  For each flow, a separate bucket
      is maintained.  To send a packet over the flow, a host must remove
      a number of credits equal to the size of the packet from the token
      bucket.  If there are not enough credits, the host must wait until
      enough credits accumulate in the bucket.

      Note that the fact that the rate is expressed in terms of a token
      bucket rate does not mean that hosts must implement token buckets.
      Any traffic management scheme that yields equivalent behavior is
      permitted.

      The field is in the general field format and counts the number of
      byte credits (i.e., right to send a byte) per second which are



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


      deposited into the token bucket.  The value must be a number (not
      a well-known constant).

      The value zero is slightly special.  It is used to indicate that
      the application is not making a request for bandwidth guarantees.
      If this field is zero, then the Token Bucket Size must also be
      zero, and the type of guarantee requested may be no higher than
      predicted service.

   Token Bucket Size

      The token bucket size controls the maximum amount of data that the
      flow can send at the peak rate.  More formally, if the token
      bucket size is B, and the token bucket rate is R, over any
      arbitrarily chosen interval T in the life of the flow, the amount
      of data that the flow sends cannot have exceeded B + (R * T)
      bytes.

      The token bucket is filled at the token bucket rate.  The bucket
      size limits how many credits the flow may store.  When the bucket
      is full, new credits are discarded.

      The field is in the general field format and indicates the size of
      the bucket in bytes.  The value must be a number.

      Note that the bucket size must be greater than or equal to the MTU
      size.

      Zero is a legal value for the field and indicates that no credits
      are saved.

   Maximum Transmission Rate

      The maximum transmission rate limits how fast packets may be sent
      back to back from the host.  Consider that if the token bucket is
      full, it is possible for the flow to send a series of back-to-back
      packets equal to the size of the token bucket.  If the token
      bucket size is large, this back-to-back run may be long enough to
      significantly inhibit multiplexing.

      To limit this effect, the maximum transmission rate bounds how
      fast successive packets may be placed on the network.

      One can think of the maximum transmission rate control as being a
      form of a leaky bucket.  When a packet is sent, a number of
      credits equal to the size of the packet is placed into an empty
      bucket, which drains credits at the maximum transmission rate.  No
      more packets may be sent until the bucket has emptied again.



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


      The maximum transmission rate is the rate at which the bucket is
      emptied.  The field is in the general field format and indicates
      the size of the bucket in bytes.  The value must be a number and
      must be greater than or equal to the token bucket rate.

      Note that the MTU size can be used in conjunction with the maximum
      transmission rate to bound how long an individual packet blocks
      other transmissions.  The MTU specifies the maximum time an
      individual packet may take.  The Maximum Transmission Rate, limits
      the frequency with which packets may be placed on the network.

   Minimum Delay Noticed

      The minimum delay noticed field tells the internetwork that the
      host and application are effectively insensitive to improvements
      in end-to-end delay below this value.  The network is encouraged
      to drive the delay down to this value but need not try to improve
      the delay further.

      The field is in the general field format.

      If expressed as a number it is the number of microseconds of delay
      below which the host and application do not care about
      improvements.  Human users only care about delays in the
      millisecond range but some applications will be computer to
      computer and computers now have clock times measured in a handful
      of nanoseconds.  For such computers, microseconds are an
      appreciable time.  For this reason, this field measures in
      microseconds, even though that may seem small.

      If expressed as a well-known constant (first bit set), two field
      values are accepted:

         0 - the application is not sensitive to delay

         1 - the application is moderately delay sensitive
             e.g., avoid satellite links where possible).

   Maximum Delay Variation

      If a receiving application requires data to be delivered in the
      same pattern that the data was transmitted, it may be necessary
      for the receiving host to briefly buffer data as it is received so
      that the receiver can restore the old transmission pattern.  (An
      easy example of this is a case where an application wishes to send
      and transmit data such as voice samples, which are generated and
      played at regular intervals.  The regular intervals may be
      distorted by queueing effects in the network and the receiver may



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


      have to restore the regular spacing.)

      The amount of buffer space that the receiving host is willing to
      provide determines the amount of variation in delay permitted for
      individual packets within a given flow.  The maximum delay
      variation field makes it possible to tell the network how much
      variation is permitted.  (Implementors should note that the
      restrictions on the maximum transmission rate may cause data
      traffic patterns to be distorted before they are placed on the
      network, and that this distortion must be accounted for in
      determining the receiver buffer size.)

      The field is in the general field format and must be a number.  It
      is the difference, in microseconds, between the maximum and
      minimum possible delay that a packet will experience.  (There is
      some question about whether microsecond units are too large.  At a
      terabit per second, one microsecond is a megabit.  Presumably if a
      host is willing to receive data at terabit speeds it is willing to
      provide megabits of buffer space.)

      The value of 0, meaning the receiving host will not buffer out
      delays, is acceptable but the receiving host must still have
      enough buffer space to receive a maximum transmission unit sized
      packet from the sending host.  Note that it is expected that a
      value of 0 will make it unlikely that a flow can be established.

   Loss Sensitivity

      This field indicates how sensitive the flow's traffic is to
      losses.  Loss sensitivity can be expressed in one of two ways:
      either as a number of losses of MTU-sized packets in an interval,
      or simply as a value indicating a level of sensitivity.

      The field is in the general field format.

      If the value is a number, then the value is the number of MTU-
      sized packets that may be lost out of the number of MTU-sized
      packets listed in the Loss Interval field.

      If the value is a well-known constant, then one of two values is
      permitted:

         0 - the flow is insensitive to loss

         1 - the flow is sensitive to loss (where possible
             choose the path with the lowest loss rate).





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


   Burst Loss Sensitivity

      This field states how sensitive the flow is to losses of
      consecutive packets.  The field enumerates the maximum number of
      consecutive MTU-sized packets that may be lost.

      The field is in the general field format.

      If the value is a number, then the value is the number of
      consecutive MTU-sized packets that may be lost.

      If the value is a well-known constant, then the value 0 indicates
      that the flow is insensitive to burst loss.

      Note that it is permissible to set the loss sensitivity field to
      simply indicate sensitivity to loss, and set a numerical limit on
      the number of consecutive packets that can be lost.

   Loss Interval

      This field determines the period over which the maximum number of
      losses per interval are measured.  In other words, given any
      arbitrarily chosen interval of this length, the number of losses
      may not exceed the number in the Loss Sensitivity field.

      The field is in the general field format.

      If the Loss Sensitivity field is a number, then this field must
      also be a number and must indicate the number of MTU-sized packets
      which constitutes a loss interval.

      If the Loss Sensitivity field is not a number (i.e., is a well-
      known constant) then this field must use the well-known constant
      of 0 (i.e., first bit set, all other bits 0) indicating that no
      loss interval is defined.

   Quality of Guarantee

      It is expected that the internetwork will likely have to offer
      more than one type of guarantee.

      There are two unrelated issues related to guarantees.

      First, it may not be possible for the internetwork to make a firm
      guarantee.  Consider a path through an internetwork in which the
      last hop is an Ethernet.  Experience has shown (e.g., some of the
      IETF conferencing experiments) that an Ethernet can often give
      acceptable performance, but clearly the internetwork cannot



Partridge                                                      [Page 10]