Re: int-serv over e.g. ATM

[John Krawczyk <[e-mail]>]

   In your example the router with 500 hosts would no longer be able to
   support additional VCs or provide the QoS or media capacity to the
   router may saturate.  If the host did not have apriori knowledge that
   the QoS could not be granted, it would try to use RSVP.  In RSVP the
   repient initiates reservation.  When RESV is sent, either a PATH or
   PERR is returned.  If PERR is returned, a direct connection can be set
   up.  If the host (or a router acting on the behelf of a host not
   directly connected to the NBMA) did know apriori that a shared VC or a
   hop by hop path cannot accomodate a certain QoS, the step of probing
   the lower cost path with RESV can be skipped and a VC set up
   immediately, and then a RESV sent to confirm (in case the other end is
   off NBMA and still cannot be reached with the requested QoS).
   
Hi Curtis,

Just a slight correction on the protocol activity.  The session
senders will send out PATH messages first.  When the receiver sends
out a RESV, it may get a RESV ERR, indicating that the reservation was
not granted at some node in the network.  On Friday, we discussed an
additional "soft ACK" that would be returned when a RESV hit the
sender or a reservation merge point, whichever comes first (monitor
the rsvp list for more details).

   I think that just came up on the RSVP list.  RSVP can be forwarded to
   non-RSVP portions of the topology that are believed (by the local
   administrators) to be mostly uncongested and capable of supporting a
   given QoS.  The argument was made that end systems need to know that
   this decision was made.  IMO this should never occur (forwarding RSVP
   through a non-RSVP portion of topology) if the Rspec was for any form
   of guarenteed service (unless it was certain that the reservation
   could be met, due to something like gross overprovisioning).  If the
   Rspec was for a predictive service, then it is really a judgement
   call, prefereably made based on very reliable basis.  But I'm speaking
   here about something that shouldn't be since I'm only a lurker on RSVP.

This was also discussed on Friday.  This would be contained in the
ADSPEC object of the PATH message (probably).  It might just be a bit
that says "this PATH went through some best-effort hops" or one may
actually be able to tell how many best-effort hops there were (it's
not clear that this is a measure of goodness/badness, since you only
need one congested best-effort link to make things unbearable).  This
way, the receiving application/user can decide if they want to gamble.
As you say, if the receiver really needs guaranteed service, it should
not try to establish a reservation in this case.

-jj