Subject: Soft State

From: Maria Elena Villapol <[email-masked]>
Date: Tue, 30 Nov 1999 15:43:15 +1030

Hi everyone,

I am modeling RSVP. My model is based on RFC 2205. I found a possible
problem of soft state approach in RSVP.
Given the following scenario:

one sender, one router and one receiver.

The sender sends a path message. Once the receiver gets it, it  sends a
Resv msg. Because the receiver fails to receive several consecutive path
messages, the path and correspondent reservation are released at the
receiver. After that, a path msg finally arrives to the receiver and the
path state is reestablished in there. The application has not sent any
other Resv request because it is happy with the current reservation. So,
how may the reservation be reestablished if the application does not
start to send Resv requests again?

I'm not considering tear down messages for the current version of my
model.

Thank in advance.

Maria

--
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: [email-masked]
       [email-masked]

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm

---

From: Andreas Terzis <[email-masked]>
Date: Mon, 29 Nov 1999 22:40:38 -0800 (PST)

> I'm not considering tear down messages for the current version of my
Hi Maria,

I would say that this is an issue regarding the RSVP's API to 
applications rather than the protocol itself. In any case, in the
scenario you described the API could report the loss of reservation
to the application when the Path state expires in the first place 
and would later report the re-establishment of Path state so if
the application is still interest it could once again reserve 
resources.
You might want to take a look to SCRAPI or the Winsock2 API to
RSVP for more information

regards,

andreas

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andreas A. Terzis,                  | UCLA Computer Science Department
[email-masked]                  | Internet Research Lab 
http://irl.cs.ucla.edu/~terzis      |
PGP Signature available at http://www.cs.ucla.edu/~terzis/pub_key.asc

---

From: Ashok Narayanan <[email-masked]>
Date: Tue, 30 Nov 1999 03:16:11 -0500 (EST)

> > Given the following scenario:

<snip> 

 > the application is still interest it could once again reserve 

The other way in which an implementation could handle this is to have
RSVP state for all locally requested paths/reservations. If an
application requests a reservation from the RSVP API, this can be
stored in the RSVP daemon/process/whatever for future processing. When 
the path in question comes in, this can trigger the waiting
reservation which can then be installed and forwarded. This way, the
client API is simplified and (more importantly) the headache of
synchronization is hidden in the API and is not exposed to the client.

-Ashok

-- 
--- Asok the Intern ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387

---

From: David Charlap <[email-masked]>
Date: Tue, 30 Nov 1999 11:14:34 -0500

Maria Elena Villapol wrote:
> 
> The sender sends a path message. Once the receiver gets it, it  sends
> a Resv msg. Because the receiver fails to receive several consecutive
> path messages, the path and correspondent reservation are released at
> the receiver. After that, a path msg finally arrives to the receiver
> and the path state is reestablished in there. The application has not
> sent any other Resv request because it is happy with the current
> reservation. So, how may the reservation be reestablished if the
> application does not start to send Resv requests again?

First off, it is important to keep in mind that path refresh messages
are generated by the routers along the path.  They are not propagated
from sender to receiver.  So we're only concerned about refreshes sent
from the host to the first router.  Until the first router times out,
it, and the other routers, will continue sending refresh messages
according to their configuration.

Nevertheless, the sender must periodically send new path messages.  It
could, I suppose, send one where the Time-Values object indicates a huge
period (say, several days), which would prevent expiration on the first
router.  That would be bad, however, since a crash on the sender would
leave the path (and any associated reservations) in place for an
inordinately long period of time.

A better implementation would be for the sender host to generate the
refreshes from its network stack - so the app doesn't have to get
involved.  The stack can detect the socket-close operation and send the
tear (and stop refreshing, of course) if the app fails to request this
on its own.

At the receiver's end, we won't get a timeout (unless the last-hop
router fails.)  If the first-hop router times out, it will generate a
path-tear.  (At least I think that's the proper behavior).  The receiver
won't know if the app meant to close the connection or if it was due to
a failure - it will just get a tear.  A subsequent path will be treated
as a new path and not as a refresh - forcing the generation of a new
resv.

If the last-hop router should fail, then the receiver may time-out the
path.  In that case, I would expect it to tear down the reservation as
well, possibly sending a resv-tear to the sender.  (Of course, if the
last-hop router has failed, chances are that the resv-tear won't get
anywhere, so you'd actually see that tear initiated by the next-to-last-
hop router when it fails to receive a refresh for that resv.)

Keep in mind also that the receiver must be sending periodic resv
refresh messages to the sender, just like the sender must be sending
periodic path refresh messages.  (This is probably best handled in the
network stack, and not by the host application.)  If, for some strange
reason, the path state should expire without removing the resv state,
those resv refreshes would still be sent (although they'd cause resv-
error messages to be sent back if the corresponding path no longer
exists.)  Upon the arrival of a new path (assuming that that path
doesn't destroy this lingering resv state), the next resv refresh to be
sent would be taken as a new resv by the network, and it would be
propagated to the sender.

I hope this helps somewhat.

-- David