rfc1363.txt

RFC 的详细文档！

RFC 1363             A Proposed Flow Specification        September 1992


   delay sensitive, the routing system must seek out the most direct
   route for the flow.  But if the routing system is told that the flow
   is sensitive only to delays over 100 milliseconds, there may be a
   number of routes other than the most direct route which can satisfy
   this delay, thus leaving the most direct route available for a later
   flow which needs a far lower delay.

   In fairness, it should be noted that a danger of a parametric model
   is that it is very easy to have too many parameters.  The yearn to
   optimize can be overdone.  The goal of this flow spec is to enumerate
   just enough parameters that it appears that essential needs can be
   expressed, and the internetwork has some information it can use to
   try to manage the flows.  Features that would simply be nice or
   useful to have (but not essential) are left out to keep the parameter
   space small.

An Implication of the Flow Spec

   It is important to observe that the there are fields in the flow spec
   that are based on information from the sender (such as rate
   information) and fields in the flow spec that are based on
   information from the receiver (such as delay variation).  There are
   also fields that may sender and receiver to negotiate in advance.
   For example, the acceptable loss rate may depend on whether the
   sender and receiver both support the same type of forward error
   correction.  The delay sensitivity for a voice connection may depend,
   in part, on whether both sender and receiver support echo cancelling.

   The implication is that the internetwork must permit the sender and
   receiver to communicate in advance of setting up a flow, because a
   flow spec can only be defined once both sender and receiver have had
   their say.  In other words, a reserved flow should not be the only
   form of communication.   There must be some mechanism to perform a
   short exchange of messages in preparation for setting up a flow.

   (Another aside: it has been suggested that perhaps the solution to
   this problem is to have the sender establish a flow with an
   incomplete flow spec, and when the receiver gets the flow spec, have
   the receiver send the completed flow spec back along the flow, so the
   internetwork can "revise" the flow spec according to the receiver's
   desires.  I have two problems with this approach.  First, it is
   entirely possible that the receiver's information may lead the
   internetwork to conclude that the flow established by the sender is
   no good.  For example, the receiver may indicate it has a smaller
   tolerance for delay variation than expected and force the flow to be
   rerouted over a completely different path.  Second, if we try to
   avoid having the receiver's information cause the flow to fail, then
   we have to over-allocate the flow's during the preliminary setup.



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


   But over allocating the resources requested may lead us to choose
   better quality paths than we need for this flow.  In other words, our
   attempts to optimize use of the network will fail.)

Advance Reservations and Flow Duration

   The primary purpose of a flow specification is to provide information
   to the internetwork so the internetwork can properly manage the
   proposed flow's traffic in the context of other traffic in the
   internetwork.  One question is whether the flow should give the
   network information about when the flow is expected to start and how
   long the flow is expected to last.

   Announcing when a flow will start is generally of interest for
   advance reservations.  (If the flow is not be reserved substantially
   in advance, the presentation of the flow spec to the internetwork can
   be taken as an implicit request for a flow, now.)  It is my view that
   advance reservation is a distinct problem from the describing the
   properties of a flow.  Advanced reservations will require some
   mechanism to maintain information in the network about flows which
   are not currently active but are expected to be activated at some
   time in the future.  I anticipate this will require some sort of
   distributed database to ensure that information about advanced
   reservations is not accidentally lost if parts of the internetwork
   crash.  In other words, advance reservations will require
   considerable additional supporting baggage that it would probably be
   better to keep out of the average flow spec.

   Deciding whether a flow spec should contain information about how
   long the flow is expected to run is a harder decision to make.
   Clearly if we anticipate that the internetwork will support advance
   reservations, it will be necessary for elements of the internetwork
   to predict their traffic load, so they can ensure that advance
   reservations are not compromised by new flow requests.  However,
   there is a school of thought that believes that estimating future
   load from current behavior of existing flows is more accurate than
   anything the flows may have declared in their flow specs.  For this
   reason, I've left a duration field out of the flow spec.

Examples

   To illustrate how the flow spec values might be used, this section
   presents three example flow specs.

   Telnet

      For the first example, consider using the flow spec to request
      service for an existing application: Telnet.  Telnet is a virtual



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


      terminal protocol, and one can think of it as stringing a virtual
      wire across the network between the user's terminal and a remote
      host.

      Telnet has proved a very successful application without a need to
      reserve bandwidth: the amount of data sent over any Telnet
      connection tends to be quite small.  However, Telnet users are
      often quite sensitive to delay, because delay can affect the time
      it takes to echo characters.  This suggests that a Telnet
      connection might benefit from asking the internetwork to avoid
      long delay paths.  It could so so using the following flow spec
      (for both directions):

      Version=1
      MTU=80 [40 bytes of overhead + 40 bytes user data]
      Token Bucket Rate=0/0/0 [don't want a guarantee]
      Token Bucket Size=0/0/0
      Maximum Transmission Rate=0/0/0
      Maximum Delay Noticed=1/1 [constant = delay sensitive]
      Maximum Delay Variation=0/0/0 [not a concern]
      Loss Sensitivity=1/0 [don't worry about loss]
      Burst Loss Sensitivity=1/0
      Loss Interval=1/0
      Quality of Guarantee=1/0 [just asking]

      It is worth noting that Telnet's flow spec is likely to be the
      same for all instantiations of a Telnet connection.  As a result,
      there may be some optimizations possible (such as just tagging
      Telnet packets as being subject to the well-known Telnet flow
      spec).

   A Voice Flow

      Now consider transmitting voice over the Internet.  Currently,
      good quality voice can be delivered at rates of 32Kbit/s or
      16Kbit/s.  Assuming the rate is 32Kbit/s and voice samples are 16
      bit samples packaged into UDP datagrams (for a data rate of about
      60 Kbyte/s), a flow spec might be:

      Version=1
      MTU=30 [2 byte sample in UDP datagram]
      Token Bucket Rate=0/10/59 [60.4 Kbytes/s]
      Token Bucket Size=0/0/30 [save enough to send immediately
                                after pauses]
      Maximum Transmission Rate=0/10/59 [peak same as mean]
      Maximum Delay Noticed=0/10/100 [100 ms]
      Maximum Delay Variation=0/10/10 [keep variation low]
      Loss Sensitivity=1/1 [loss sensitive]



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


      Burst Loss Sensitivity=0/0/5 [keep bursts small]
      Loss Interval=1/0
      Quality of Guarantee=1/201 [predicted service and I'll accept
                                  worse]

   A Variable Bit-Rate Video Flow

      Variable bit-rate video transmissions vary the rate at which they
      send data according to the amount of the video image that has
      changed between frames.  In this example, we consider a one-way
      broadcast of a picture.  If we assume 30 frames a second and that
      a full frame is about 1 megabit of data, and that on average about
      10% of the frame changes, but in the worst case the entire frame
      changes, the flow spec might be:

      Version=1
      MTU=4096 [big so we can put lots of bits in each packet]
      Token Bucket Rate=0/20/1 [8 Mbits/s]
      Token Bucket Size=0/17/2 [2 Mbits/s]
      Maximum Transmission Rate=0/20/30 [30 Mbits/s]
      Maximum Delay Noticed=1/1 [somewhat delay sensitive]
      Maximum Delay Variation=0/10/1 [no more than one second of
                                      buffering]
      Loss Sensitivity=0/0/1 [worst case, one loss per frame]
      Burst Loss Sensitivity=0/0/1 [no burst errors please]
      Loss Interval=0/0/33 [one frame in MTU sized packets]
      Quality of Guarantee=1/300 [guaranteed service only]

      The token bucket is sized to be two frames of data, and the bucket
      rate will fill the bucket every 250 ms.  The expectation is that
      full scene changes will be rare and that a fast rate with a large
      bucket size should accommodate even a series of scene changes.

   Disclaimer

      In all cases, these examples are simply to sketch the use of the
      flow spec.  The author makes no claims that the actual values used
      are the correct ones for a particular application.

Security Considerations

   Security considerations definitely exist.  For example, one might
   assume that users are charged for guaranteed flows.  In that case,
   some mechanism must exist to ensure that a flow request (including
   flow spec) is authenticated.  However I believe that such issues have
   to be dealt with as part of designing a negotiation protocol, and are
   not part of designing the flow spec data structure.




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


Acknowledgements

   I'd like to acknowledge the tremendous assistance of Steve Deering,
   Scott Shenker and Lixia Zhang of XEROX PARC in writing this RFC.
   Much of this flow spec was sketched out in two long meetings with
   them at PARC.  Others who have offered notable advice and comments
   include Isidro Castineyra, Deborah Estrin, and members of the End-
   to-End Research Group chaired by Bob Braden.  All ideas that prove
   misbegotten are the sole responsibility of the author.  This work was
   funded under DARPA Contract No. MDA903-91-D-0019.  The views
   expressed in this document are not necessarily those of the Defense
   Advanced Research Projects Agency.

References

   1. Parekh, A., "A Generalized Processor Sharing Approach
      to Flow Control in Integrated Services Networks",
      MIT Laboratory for Information and Decision Systems,
      Report No. LIDS-TH-2089.

   2. Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
      Applications in an Integrated Services Packet Network:
      Architecture and Mechanism", Proceedings of ACM SIGCOMM '92,
      August 1992.

Author's Address

   Craig Partridge
   BBN
   824 Kipling St
   Palo Alto, CA  94301

   Phone: [phone]

   EMail: [e-mail]
















Partridge                                                      [Page 20]