| Description | If a network element uses a certain amount of
slack, Si, to reduce the amount of resources
that it has reserved for a particular flow, i,
the value Si should be stored at the network
element. Subsequently, if reservation re-
freshes are received for flow i, the network
element must use the same slack Si without any
further computation. This guarantees consisten-
cy in the reservation process.
As an example for the use of the slack term,
consider the case where the required end-to-end
delay, Dreq, is larger than the maximum delay
of the fluid flow system. The latter is ob-
tained by setting R=r in the fluid delay formu-
la, and is given by
b/r + Ctot/r + Dtot.
In this case the slack term is
S = Dreq - (b/r + Ctot/r + Dtot).
The slack term may be used by the network ele-
ments to adjust their local reservations, so
that they can admit flows that would otherwise
have been rejected. A service element at an in-
termediate network element that can internally
differentiate between delay and rate guarantees
can now take advantage of this information to
lower the amount of resources allocated to this
flow. For example, by taking an amount of slack
s <= S, an RCSD scheduler [5] can increase the
local delay bound, d, assigned to the flow, to
d+s. Given an RSpec, (Rin, Sin), it would do so
by setting Rout = Rin and Sout = Sin - s.
Similarly, a network element using a WFQ
scheduler can decrease its local reservation
from Rin to Rout by using some of the slack in
the RSpec. This can be accomplished by using
the transformation rules given in the previous
section, that ensure that the reduced reserva-
tion level will not increase the overall end-
to-end delay. |