From: [email-masked]
Date: Tue, 01 Oct 96 09:24:23 +0100

Subject: Re: Questions on slack term and guaranteed service

Roch wrote........

>...........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).

>Thanks Roch,

I assume that a typical approach would be for the receiver to initially make a reservation, R1 with the slack term set to zero. Then, if this reservation fails the receiver might make another attempt, this time reserving R2 (R2>R1) with some non-zero slack, S2. If this attempt also fails then the receiver might try reserving R3(R3>R2) with slack, S3 (S3>S2) etc...

Is this how you see it?

Regards,
Paul