RFC 2212 (rfc2212) - Page 2 of 20
Specification of Guaranteed Quality of Service
Alternative Format: Original Text Document
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