rfc1363.txt

RFC 的详细文档！


RFC 1363             A Proposed Flow Specification        September 1992


      guarantee that the Ethernet will not saturate at some time during
      a flow's lifetime.  Thus it must be possible to distinguish
      between flows which cannot tolerate the small possibility of a
      failure (and thus must guaranteed at every hop in the path) and
      those that can tolerate islands of uncertainty.

      Second, there is some preliminary work (see [2]) that suggests
      that some applications will be able to adapt to modest variations
      in internetwork performance and that network designers can exploit
      this flexibility to allow better network utilization.  In this
      model, the internetwork would be allowed to deviate slightly from
      the promised flow parameters during periods of load.  This class
      of service is called predicted service (to distinguish it from
      guaranteed service).

      The difference between predicted service and service which cannot
      be perfectly guaranteed (e.g., the Ethernet example mentioned
      above) is that the imperfect guarantee makes no statistical
      promises about how it might mis-behave.  In the worst case, the
      imperfect guarantee will not work at all, whereas predicted
      service will give slightly degraded service.  Note too that
      predicted service assumes that the routers and links in a path all
      cooperate (to some degree) whereas an imperfect guarantee states
      that some routers or links will not cooperate.

      The field is a 16-bit field in Internet byte order.  There are six
      legal values:

         0 - no guarantee is required (the host is simply expressing
             desired performance for the flow)

         100 (hex) - an imperfect guarantee is requested.

         200 (hex) - predicted service is requested and if unavailable,
                     then no flow should be established.

         201 (hex) - predicted service is requested but an imperfect
                     guarantee is acceptable.

         300 (hex) - guaranteed service is requested and if a firm
                     guarantee cannot be given, then no flow should be
                     established.

         301 (hex) - guaranteed service is request and but an imperfect
                     guarantee is acceptable.

      It is expected that asking for predicted service or permitting an
      imperfect guarantee will substantially increase the chance that a



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


      flow request will be accepted.

Possible Limitations in the Proposed Flow Spec

   There are at least three places where the flow spec is arguably
   imperfect, based on what we currently know about flow reservation.
   In addition, since this is a first attempt at a flow spec, readers
   should expect modifications as we learn more.

   First, the loss model is not perfect.  Simply stating that an
   application is sensitive to loss and to burst loss is a rather crude
   indication of sensitivity.  However, explicitly enumerating loss
   requirements within a cycle is also an imperfect mechanism.  The key
   problem with the explicit values is that not all packets sent over a
   flow will be a full MTU in size.  Expressed another way, the current
   flow spec expects that an MTU-sized packet will be the unit of error
   recovery.  If flows send packets in a range of sizes, then the loss
   bounds may not be very useful.  However, the thought of allowing a
   flow to request a set of loss models (one per packet size) is
   sufficiently painful that I've limited the flow to one loss profile.
   Further study of loss models is clearly needed.

   Second, the minimum delay sensitivity field limits a flow to stating
   that there is one point on a performance sensitivity curve below
   which the flow is no longer interested in improved performance.  It
   may be that a single point is insufficient to fully express a flow's
   sensitivity.  For example, consider a flow for supporting part of a
   two-way voice conversation.  Human users will notice improvements in
   delay down to a few 10s of milliseconds.  However, the key point of
   sensitivity is the delay at which normal conversation begins to
   become awkward (about 100 milliseconds).  By allowing only one
   sensitivity point, the flow spec forces the flow designer to either
   ask for the best possible delay (e.g, a few 10's of ms) to try to get
   maximum performance from the network, or state a sensitivity of about
   95 ms, and accept the possibility that the internetwork will not try
   to improve delay below that value, even if it could (and even though
   the user would notice the improvement).  My expectation is that a
   simple point is likely to be easier to deal with than attempting to
   enumerate two (or three or four) points in the sensitivity curve.

   Third, the models for service guarantees is still evolving and it is
   by no means clear that the service choices provided are the correct
   set.








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


How an Internetwork is Expected to Handle a Flow Spec

   There are at least two parts to the issue of how an internetwork is
   expected to handle a flow spec.  The first part deals with how the
   flow spec is interpreted so that the internetwork can find a route
   which will allow the internetwork to match the flow's requirements.
   The second part deals with how the network replies to the host's
   request.

   The precise mechanism for setting up a flow, given a flow spec, is a
   large topic and beyond the scope of this memo.  The purpose of the
   next few paragraphs is simply to sketch an argument that this flow
   spec is sufficient to the requirements of the setup mechanisms known
   to the author.

   The key problem in setting up a flow is determining if there exist
   one or more routes from the source to the destination(s) which might
   be able to support the quality of service requested.  Once one has a
   route (or set of candidate routes) one can take whatever actions may
   be appropriate to confirm that the route is actually viable and to
   cause the flow's data to follow that route.

   There are a number of ways to find a route.  One might try to build a
   route on the fly by establishing the flow hop-by-hop (as ST-II does)
   or one might consult a route server which provides a set of candidate
   source routes derived from a routing database.  However, whatever
   system is used, some basic information about the flow needs to be
   provided to the routing system.  This information is:

      * How much bandwidth the flow may require.  There's no point
        in routing a flow that expects to send at over 10 megabits per
        second via a T1 (1.5 megabit per second) link.

      * How delay sensitive the application is.  One does not wish
        to route a delay-sensitive application over a satellite link,
        unless the satellite link is the only possible route from here
        to there.

      * How much error can be tolerated.  Can we send this flow over
        our microwave channel on a rainy day or is a more reliable link
        required?

      * How firm the guarantees need to be.  Can we put an Ethernet
        in as one of the hops?

      * How much delay variation is tolerated.  Again, can an Ethernet
        be included in the path?  Does the routing system need to worry
        if the addition of this flow will cause a few routers to run



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


        at close to capacity?  (A side note: we assume that the routers
        are running with priority queueing systems, so running the router
        close to capacity doesn't mean that all flows get long and
        variable delays.  Rather, running close to capacity means that
        high priority flows will be unaffected, and low priority flows
        will get hit with a lot of delay and variation.)

   The flow spec provides all of this information.  So it seems
   plausible to assume it provides enough information to make routing
   decisions at setup time.

   The flow spec was designed with the expectation that the network
   would give a yes or no reply to a request for a guaranteed flow.

   Some researchers have suggested that the negotiation to set up a flow
   might be an extended negotiation, in which the requesting host
   initially requests the best possible flow it could desire and then
   haggles with the network until they agree on a flow with properties
   that the network can actually provide and the application still finds
   useful.  This notion bothers me for at least two reasons.  First, it
   means setting up a flow is a potentially long process.  Second, the
   general problem of finding all possible routes with a given set of
   properties is a version of the traveling salesman problem, and I
   don't want to embed traveling salesman algorithms into a network's
   routing system.

   The model used in designing this flow spec was that a system would
   ask for the minimum level of service that was deemed acceptable and
   the network would try to find a route that met that level of service.
   If the network is unable to achieve the desired level of service, it
   refuses the flow, otherwise it accepts the flow.

The Flow Spec as a Return Value

   This memo does not specify the data structures that the network uses
   to accept or reject a flow.  However, the flow spec has been designed
   so that it can be used to return the type of service being
   guaranteed.

   If the request is being accepted, the minimum delay field could be
   set to the guaranteed or predicted delay, and the quality of
   guarantee field could be set to no guarantee (0), imperfect guarantee
   (100 hex), predicted service (200 hex), or guaranteed service (300
   hex).

   If the request is being rejected, the flow spec could be modified to
   indicate what type of flow the network believes it could accept e.g.,
   the traffic shape or delay characteristics could be adjusted or the



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


   type of guarantee lowered).  Note that this returned flow spec would
   likely be a hint, not a promised offer of service.

Why Type of Service is not Good Enough

   The flow spec proposed in this memo takes the form of a set of
   parameters describing the properties and requirements of the flow.
   An alternative approach which is sometimes mentioned (and which is
   currently incorporated into IP) is to use a Type of Service (TOS)
   value.

   The TOS value is an integer (or bit pattern) whose values have been
   predefined to represent requested quality of services.  Thus, a TOS
   of 47 might request service for a flow using up to 1 gigabit per
   second of bandwidth with a minimum delay sensitivity of 100
   milliseconds.

   TOS schemes work well if the different quality of services that may
   be requested are both enumerable and reasonably small.
   Unfortunately, these conditions do not appear to apply to future
   internetworks.  The range of possible bandwidth requests alone is
   huge.  Combine this range with several gradations of delay
   requirements, and widely different sensitivities to errors and the
   set of TOS values required becomes extremely large.  (At least one
   person has suggested to the author that perhaps a TOS field combined
   with a bandwidth parameter might be appropriate.  In other words, a
   two parameter model.  That's a tempting idea but my gut feeling is
   that it is not quite sufficient so I'm proposing a more complete
   parametric model.)

   Another reason to prefer parametric service is optimization issues.
   A key issue in flow setup is trying to design the the routing system
   to optimize its management of flows.  One can optimize on a number of
   criteria.  A good example of an optimization problem is the following
   question (expressed by Isidro Castineyra of BBN):

     "Given a request to establish a flow, how can the internetwork
     accept that request in such a way as to maximize the chance that
     the internetwork will also be able to accept the next flow
     request?"

   The optimization goal here is call-completion - maximizing the chance
   that requests to establish flows will succeed.  One might
   alternatively try to maximize revenue (if one is charging for flows).

   The internetwork is presumably in a better position to do
   optimizations if it has more information about the flow's expected
   behavior.  For example, if a TOS system says only that a flow is



Partridge                                                      [Page 15]