Guaranteed Service[#!guaranteed!#] provides an assured level of bandwidth, with a firm end-to-end delay bound and no queuing loss for conforming packets of a data flow. It is intended for applications with stringent real-time delivery requirements such as certain audio and video applications that have fixed “play-out” buffers and are intolerant of any datagram arriving after their playback time. Guaranteed Service really addresses the support of ``legacy'' applications that expect a delivery model similar to traditional telecommunications circuits.
Each router characterises the Guaranteed Service for a specific flow by allocating a bandwidth, R and buffer space, B that the flow may consume. This is done by approximating the ``fluid model'' of service[#!gps1!#][#!gps2!#] so that the flow effectively sees a dedicated wire of bandwidth, R between source and receiver.
In a perfect fluid model a flow conforming to a token bucket of rate, r and depth, b will have it's delay bounded by b/R provided R >= r. To allow for deviations from this perfect fluid model in the router's approximation , two error terms, C and D are introduced. Among other things the router's approximation must take account of the medium-dependent behaviour of the link layer of the data forwarding path. These errors arise from the finite packet sizes that are being dealt with. For example, any packet may experience an excess delay as it is forwarded due to the size of the packets in the same queue, and due to inaccuracies in scheduling from packets (of a possibly different size) in other queues bound for the output link. These terms are derived for Weighted Fair Queuing schedulers in Parekh's seminal work [#!gps1!#][#!gps2!#].
Consequently the delay bound now becomes b/R + C/R + D. However with Guaranteed Service a limit is imposed on the peak rate, p of the flow which results in a reduction of the delay bound.
In addition, the packetisation effect of the flow needs to be taken into account by considering the maximum packet size, M.
While the Internet Protocol permits, in principle, a wide range of packet size s, in practice, the range supported makes stating this upper limit practical and realistic. These additional factors result in a more precise bound on the end to end queuing delay as follows:
(case p > R >= r) |
(1) |
(case R >= p >= r) |
(2) |
The composed terms, Ctot and Dtot represent the summation of the C and D error terms respectively for each router along the end-to-end data path. In (1), there are three delay terms, made from the contributions of the burst of packets, b, (the bucket depth) sent at the peak rate p, and serviced at the output link rate R, plus the sum over all hops, of errors introduced at each hop due to a packet size worth of fluid flow approximation, plus a third term, made up of cross traffic scheduling approximation contributions. In (2), the first term is absent, since the link rate is greater than the peak, so there are no packets queued from this flow itself. In order for a router to invoke Guaranteed Service for a specific data flow it needs to be informed of the traffic characteristics of the flow, Tspec, along with the reservation characteristics, Rspec. These are detailed below in table 2.6.
Furthermore to enable the router to calculate sufficient local resources to guarantee a lossless service it requires the terms Csum and Dsum which represent the summation of the C and D error terms respectively for each router along the path since the last re-shaping point.
|
Guaranteed Service traffic must be policed at the network access points to ensure conformance to the Tspec, so that traffic does not interfere with other flows and cause them to miss their contract. We discuss this further below.
In addition to policing of data flows at the edge of the network, Guaranteed Service also requires reshaping of traffic to the token bucket of the reserved Tspec at certain points on the distribution tree. Any packets failing the reshaping are treated as best- effort and marked accordingly if such a facility is available. Reshaping must be applied at any points where it is possible for a data flow to exceed the reserved Tspec even when all senders associated with the data flow conform to their individual Tspecs.
Traffic conforming to a leaky bucket specification has still some degrees of freedom to take different shapes within the envelope. Shaping can improve the way such traffic mixes and improve its buffering requirements. Such an occurrence is possible in the following two multicast cases (readers may care to re-read this section after reading chapter three).
This reshaping will necessarily incur an additional delay (essentially, to smooth a collection of peaks over some troughs of traffic flow must entail slowing down early packets, since one obviously cannot speed up later packets).
When merging heterogeneous reservation requests from receivers onto the tree flowing from the same source, there is an additional problem known as the ``Killer Reservation'' problem, which manifests itself in two ways: Firstly, a large reservation made subsequent to an existing smaller reservation may fail. If this is the case, a naive implementation will cause the entire reservation to fail. The solution to this is to introduce extra states into the reservation protocol such that subsequent failures to not break existing reservations. Secondly, a receiver may continually attempt to make a large reservation, retrying quickly after every failure. This may continually block a smaller reservation request that might otherwise succeed. Again, a merge point might keep state concerning recent failed reservations and favour new ones that are more likely to succeed over retries for ones that have recently failed.
There are a number of applications in the military and commercial worlds which have hard delay bound requirements. For example, the Distributed Interactive Simulation program has a scenario with 100,000 participants in an online war game simulation, where the applications send messages to each other that represent events between objects in the real world. Participants should see progress (missiles hitting tanks) in an ordered, and timely fashion. A somewhat difference scenario, but with remarkable similar network guarantee requirements, is that of share dealer networks. Here, share price advertisements are multicast to the dealer terminals, with hard delay bounds on delivery delays (and rates), and delay bounds on the response times, since the price in the real world is varying, possibly very rapidly, and the requirement is that a bid to buy at a price does not encounter an offer to sell that is significantly out of date.
| RSVP use with Integrated Services Status: IETF Proposed Standard RFC 2210 |
| Controlled Load Status: IETF Proposed Standard RFC 2211 |
| Guaranteed Service Status: IETF Proposed Standard RFC 2212 |