Subject: Questions on slack term and guaranteed service

From: Paul White <[email-masked]>
Date: Thu, 26 Sep 1996 14:51:00 +0100

Hello everyone,

Having  once more read the internet drafts "Specification of Guaranteed
Quality of Service" and "The Use of RSVP with IETF Integrated Services"
I am still a little confused as to the correct use of the slack term, S 
in the flowspec of the Resv message.

In the guaranteed service spec it gives the following example of the use
of the slack term:

   "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 obtained by setting R=r in
   the fluid delay formula (for stability, R>=r must be true), 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 elements to adjust their
   local reservations, so that they can admit flows that would otherwise
   have been rejected. A network element at an intermediate network
   element that can internally differentiate between delay and rate

Shenker/Partridge/Guerin    Expires 2/13/97                    [Page 16]

INTERNET-DRAFT  draft-ietf-intserv-guaranteed-svc-06.txt  13 August 1996

   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
   reservation level will not increase the overall end-to-end delay."

QUESTIONS
 --------------------
1. The above example is the only scenario in which I can envisage the
slack term being non-zero. In what other circumstances would we have a
non-zero slack term?

2. For this example, isn't the last paragraph of the above quoted text
invalid since it implies reducing the reservation below r?

Regards,

Paul

---

From: Roch Guerin <[email-masked]>
Date: Thu, 26 Sep 1996 12:16:48 -0400

Paul, 

Let me try to respond to your questions and clarify things wrt the use
of the slack, whose description I agree may be a little confusing.

> ................  deleted excerpt from GS doc  ...................
>
>
>QUESTIONS
>--------------------

The scenario where setting R=r still gives you a better delay than you
need may be the more common one, but it is not necessarily the only one.
In general, the coupling between rate and delay as in the model for
the GS bounds, means that you require that ALL network elements on the
path be able to allocate the specified rate.  While this homogeneity
in requirements has the benefit of simplicity, it also means that you 
cannot take advantage of different loading at different network
elements to improve the likelihood of your reservation request to be
accepted. 

For example, consider the case where one element on the path is highly
congested, while all the others are very lightly loaded.  In such a
scenario, any reservation with a rate higher than what remains
available at the congested network element, will be rejected.  On the
other hand, if you could allow the congested network element to
allocate the minimum possible amount it can afford, and then make up
for it by allocating more resources as the other network elements
while still satisfying the desired end-to-end delay bound, then you'd
be able to improve your likelihood of acceptance.  The slack term
provides a simple mechanism that lets you do that to a limited extent,
i.e., allow for some heterogeneity in the resources allocated to a
given flow at each network element.

The use of the slack term works best for network elements that have
schedulers that decouple delay and rate guarantees, e.g., deadline
based, but can also be used, although to a lesser extent, by
rate-based schedulers such as WFQ by following the rules in the
section on "Ordering and Merging."  Now, you may ask how that
translates into scenarios where you would have a non-zero slack term,
besides the R=r case,  To illustrate that, let me use a short example
using deadline based schedulers at the network elements.  

In that example, I will also assume that the C term advertised by
each network element is the maximum packet size M, and for simplicity
will take the D terms to be all zero.  Now, what this means for a
deadline-based scheduler, is that the deadline it needs to assigns to
the packets of a flow for which the receiver is requesting a rate of
R, is equal to M/R.  Consider now the case where one network element
is unable to guarantee such a deadline and could only guarantee M/R+x.
Then, if the slack term is non-zero and larger than x, the network
element can decrease the slack by x and increase the local deadline
to M/R+x, so that it can now accept the reservation requests without
violating the desired end-to-end deadline.  

What this means is that a receiver may, therefore, want to specify a
higher rate than needed, i.e., one that corresponds to a better
end-to-end delay bound, and put the difference in the slack term.
This will then provide some flexibility in providing different
guarantees (allocating different amount of resources) at different
network elements.  Hence improving the likelihood that the request
will be accepted.  This works best for deadline based scheduler as
they can directly take from the slack without affecting any of the
other network elements.  However, as mentioned before, you can also
use such an approach with rate-based schedulers such as WFQ, although
it is not as effective (more on this below).

>invalid since it implies reducing the reservation below r?

You are absolutely correct that with a WFQ scheduler you cannot take
advantage of the slack term when you are already at R=r.  The text
is probably confusing here as the example (R=r) is there just as an
illustration, and then the rest of the text from
 
   The slack term may be used by the network elements to adjust their
   local reservations, so that they can admit flows that would otherwise
   have been rejected.............

and on, is talking about the generic use of the slack term, i.e., not
only restricted to the R=r case.  The rules specified in the "Ordering
and Merging" section still apply, so that you indeed could not lower
the rate R below r.  Note that this is one of the limitations of
rate-based schedulers in using the slack, and that schedulers which
decouple delay and rate guarantee are not subject to that constraint.

Hope the above helped.

Roch