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

Subject: EXTENDED Questions on slack term and guaranteed service

This is an extended version of my last email containing some additional questions/scenarios etc. that I forgot to include. Sorry for any unnecessary duplication.

On September 26th 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...

e.g. 

              5Kb/s       2Kb/s          4Kb/s        4kb/s
sender -----router A-----router B-------router C-----router D------receiver

In this example the figures above each router show the spare bandwidth in each router. Suppose initially the receiver calculates(from OPWA info in ADSPEC)  that it can achieve it's desired quality of service by reserving R=3Kb/s, slack(S)=0. Admission control at router B will reject the  reservation. Consequently, the receiver might retry the reservation with say R=3.5kb/s, S=x (S>0). Both C and D accept the reservation and reserve 3.5Kb/s. Router B makes use of some of the available slack to enable it to reduce it's reservation to 2kb/s. Router A reserves 3.5kb/s and the Resv message reaches the receiver.

Is this how you see it?

Also please confirm the following.......
My understanding is 
1) Only the receiver can create slack
2) Intermediate routers can use up slack, but can never create it

Is this correct?

Regards,
Paul