From: Roch Guerin <[email-masked]>
Date: Wed, 02 Oct 1996 17:41:17 -0400

>This is an extended version of my last email containing some additional questio
>ns/scenarios etc. that I forgot to include. Sorry for any unnecessary duplicati
>on.

Since I responded earlier to the abridged version, let me just address
the additional stuff you had in the subsequent note.

>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 fail
>s 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)  th
>at 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?

Yes, this does represent a realistic scenario.  Let me just point out
a couple of (maybe) subtle issues here.

The scenario you describe above assumes that call admission is
performed based on a single quantity, i.e., bandwidth.  This is indeed
the case for schedulers such as WFQ or in general schedulers that
couple delay and rate guarantees, but is not exactly true for
schedulers that decouple rate and delay guarantees, e.g., a scheduler
using a deadline based approach such as Earliest Deadline First.

Assuming a scheduler that couples rate and delay guarantees, then you
can improve things beyond what your example allows.  Specifically, if
you can accept the request at router B by reserving 2kbps and
borrowing from the slack, then this means that it satisfied the
processing rule:
           Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin
specified on p. 11 of the draft.  The processing rule is meant to
ensure that borrowing from the slack to lower the rate does not result
in a violation of the end-to-end delay bound. But in that case, it
also means that the upstream routers don't need to reserve more than
the new value Rout.  In the context of your example this new value
Rout would typically be 2kbps (you can play some tricks here that
would let you put a different -larger- value, so that you need less
slack, but I don't want to go into this here).  That means that the
routers upstream from router B can now simply reserve this new value
of Rout, i.e., 2kbps, without affecting the end-to-end delay bound.
However, note that having the routers downstream from router B
allocate the higher rate of 3.5kbps is still useful as it preserves
slack for B to use (that's because of the term Ctoti in the above
processing rule, that only accounts for stuff upstream from you).

In the context of a router with a scheduler that can separate delay
and rate guarantees, things are actually simpler.  Assume that 
router B can only provide a deadline d to the flow in question, one
which is greater than what the receiver assumed router B would do 
based on the information it advertised in the Ctot and Dtot terms.
Then router B can directly use the slack to compensate for that
increase without affecting the end-to-end delay bound.  Note that this
may indeed translate in something equivalent to a reservation of a
"bandwidth" of only 2kbps instead of 3.5kbps, but this is a function
internal to the call admission component of the router.  A difference
with the previous example is that in this case, router B would now
tupically propagate a value of Rout equal to Rin.

>
>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?

I don't think this is specified anywhere in the draft and actually the
processing rule can be used either way, i.e., decrease or increase the
slack.  However, as a guideline, I think it may not be advisable for a
router to increase the slack if it also means increasing the R term,
as this will impact all upstream routers.  This being said, I'm not
sure this is something we want to forbid, i.e., state in the specs
that a router MUST NOT increase the slack.  Furthermore, note that if
you have a router that has a scheduler that separates delay and rate
guarantee, an increase in slack by that router is a completely local
decision and can only positively impact other router, i.e., they can
only benefit from it.

Well, I hope that this was not more confusing than helpful and that I
did not open too many cans of worms.....

Roch