Subject: RE: Soft State

From: Bob Braden <[email-masked]>
Date: Tue, 30 Nov 1999 11:05:06 -0800 (PST)

*> 
  *> In Winsock implementation the receiver state is kept in the RSVP service
  *> (daemon). As long as there is a matching PATH state RSVP service on the
  *> receiver system will send out a RESV message with no further action from the
  *> receiving application. So if the PATH state times out on receiving machine
  *> RSVP service tears down the PATH state and sends a notification to the
  *> receiving application that there are no senders in the session. 
  *> 
  *> But when the PATH message is received again by the receiver, RSVP service
  *> will send out a RESV message at once. Also RSVP service notifies the
  *> receiving application that there is a sender.
  *> 
  *> I am quite sure the ISI implementation has done the above all along.
  *> 

Yes.

Note that the end-to-end effect you want (immediate reaction to the
arrival of a new Path message) can be achieved in several ways.
The ISI and Microsoft implementations have the end-system RSVP
daemon maintain the state that says a user is trying to make a
RESV but no matching path state is available; when a Path msg does
arrive, these implementations send an immediate RESV, as Ramesh
says.  However, it could be done differently; eg the state could
be moved up into the application.  Then the arriving Path message
would trigger an upcall to the app, which could then be responsible
for re-initiating the Resv call.

An aside: one aspect of the RSVP protocol that may not be well enough
defined in RFC 2205 are the "liveness" conditions.  It is clearly the
intent of the RSVP protocol that any change of state should be
propagated immediately and that a reaction to a change of state should
be similarly propagated.  However, we never wrote down the specific
rules for these objectives imply.  RFC2209, the closest we came in
defining the algorithms, specifically leaves out the API.

Bob Braden

 *> Ramesh