Subject: Effects of Mobility

From: [email-masked] (Michael Bradley)
Date: Tue, 25 Jan 94 16:06:46 PST

In response to my question on work pertaing
to accomodating both mobility and resource
reservation Bob Braden writes:

>If you are willing to tolerate occasional Admission Control failures,
>then the soft-state setup mechanism of RSVP should just handle mobility
>without change (after you have solved the mobile routing problem, which
>you must do anyway)  [Don't tell me that users won't tolerate
>occasional Admission Control failures... have you tried to telephone LA
>this week??]  Since the bandwidth requirements of mobile systems tend
>to be relatively modest, this might be a feasible approach.
>

 I will admit to not having mastered the RSVP spec yet. However as
I understand it, Admission Control is done when I make an initial
request. If I subsequently move to another router that cannot support 
the request, we apparently have an error condition. Mobility managment
could insure that the resource requirements are available to the
new router, but they may be of no use if insufficient resources
are available.  I suppose there are a variety of ways of handling 
this ranging from best effort to renogiation. However all this
is undefined.  I realize these effort are  just beginning and that
I have an obvious wireless centric perspective, but I would urge 
attention to these issues up front and not later as an add on.

 Michael Bradley

---

From: "Amit Gupta" <[email-masked]>
Date: Tue, 25 Jan 1994 16:51:17 PST

[This is w.r.t. Michael's discussion with Bob about mobility and 
resource reservation, and the suitability of RSVP soft-state mechanism
for handling the mobile computer hand-offs]. 

 My understanding is that in the phone network, once you are in (i.e. the
call is accepted), the phone company will kick you out rather rarely (as 
opposed to occasionally). In the cellular phone network, it is possible 
(I dont know precisely whether this is rare or occasional) that you be 
kicked out because you moved to a new cell. Again, the service provider 
would rather keep you out (before your call is accepted) than kick you out 
(in the middle of the conversation). The cellular service does so by 
reserving some fraction for resources for calls handed in from other cells, 
so during high load, it will not permit you to start a new conversation, 
even if some capacity is available.

 My feeling is that we will have to do something similiar in the computer
networks as well, otherwise there is not much point in doing the work for
provding predictable performance. RSVP soft-state may not be adequate,
IMHO (just the gut feeling; no hard numbers to back this up), because the
refreshes will perforce be slow (and if refreshes are trigerred by hand-offs
then we are not really using soft-state for mobility, IMHO). The solution 
requires two components: one, to "reserve" capacity in the wired  network 
which is "close to" the wireless network for serving the hand-offs; two, to
provide a quick handoff rerouting and resource reservation mechanism. 

 thanks

 -amit
 Amit Gupta
 [email-masked] 

ps: I had done some investigation into this problem (for a class project) but
I do not yet have the simulation results to make a case for the techniques
that I proposed.

pps: I apologize if this discussion is "not appropriate" for this forum.

---

From: herzog
Date: Fri, 28 Jan 1994 18:05:59 -0800

> provide a quick handoff rerouting and resource reservation mechanism. 

I believe the soft state is no so relevant to the speed of adaptation.

From the moment an even is known to the system (an RSVP router) RSVP 
reacts very fast: updates are being sent instantly and do
not encounter extra delay due to soft state. Soft state only maintains
EXISTING, NON CHANGED state.

There are two other issues:

1. Teardown of old state, to release resources.
   A teardown scheme has been drafted and should cause instant teardown.

2. Detection of a route change.
   This is more of a routing protocol issue, if/when RSVP knows about
   a route change, it reacts instantly.

Shai