RFC 2212 (rfc2212) - Page 2 of 20

Specification of Guaranteed Quality of Service

RFC 2212             Guaranteed Quality of Service        September 1997


   In brief, the concept behind this memo is that a flow is described
   using a token bucket and given this description of a flow, a service
   element (a router, a subnet, etc) computes various parameters
   describing how the service element will handle the flow's data.  By
   combining the parameters from the various service elements in a path,
   it is possible to compute the maximum delay a piece of data will
   experience when transmitted via that path.

   It is important to note three characteristics of this memo and the
   service it specifies:

      1. While the requirements a setup mechanism must follow to achieve
      a guaranteed reservation are carefully specified, neither the
      setup mechanism itself nor the method for identifying flows is
      specified.  One can create a guaranteed reservation using a
      protocol like RSVP, manual configuration of relevant routers or a
      network management protocol like SNMP.  This specification is
      intentionally independent of setup mechanism.

      2. To achieve a bounded delay requires that every service element
      in the path supports guaranteed service or adequately mimics
      guaranteed service.  However this requirement does not imply that
      guaranteed service must be deployed throughout the Internet to be
      useful.  Guaranteed service can have clear benefits even when
      partially deployed.  If fully deployed in an intranet, that
      intranet can support guaranteed service internally.  And an ISP
      can put guaranteed service in its backbone and provide guaranteed
      service between customers (or between POPs).

      3. Because service elements produce a delay bound as a result
      rather than take a delay bound as an input to be achieved, it is
      sometimes assumed that applications cannot control the delay.  In
      reality, guaranteed service gives applications considerable
      control over their delay.

      In brief, delay has two parts: a fixed delay (transmission delays,
      etc) and a queueing delay.  The fixed delay is a property of the
      chosen path, which is determined not by guaranteed service but by
      the setup mechanism.  Only queueing delay is determined by
      guaranteed service.  And (as the equations later in this memo
      show) the queueing delay is primarily a function of two
      parameters: the token bucket (in particular, the bucket size b)









Shenker, et. al.            Standards Track