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

Paul,

>
>   ...... Deleted insert ...........
>
>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...
>
>Is this how you see it?

This is indeed a very (probably the most) plausible scenario.  
Another possible case is for receivers that "know" their path crosses
an ATM network over which the reservation needs to be extended by
mapping it on a QoS ATM VC.  In that case, because of constraints on
the services the ATM network can provide, the segment of the path
crossing the ATM network will be treated as a delay only network
element.  In other words, during the advertising phase, the ATM
network will have updated the D term in the ADSPEC to reflect its
(potential) contribution to the end-to-end delay.  This means that at
the time the RESV arrives, an ATM VC with an end-to-end delay (across
the ATM network) less than or equal to the value d_ATM that was used
when updating the D term, needs to be established.  The presence of a
slack term may help improve the likelihood of successfully setting up
the VC, as provides flexibiliy in the delay value you request from the
ATM network. 

This issue and related ones were discussed at the ISSLL interim
meeting that was held yesterday and the day before in Boston.  You can
find related information in two drafts:
 - draft-ietf-issll-atm-support-01.(ps,txt)
 - draft-issll-intserv-atm-mapping-01.txt
The next version of draft-issll-intserv-atm-mapping-01.txt should
contain additional information along the lines of what I outlined
above on extending guarantees service across ATM nets and the possible
use of the slack term.

Roch