Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt)

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 27 Oct 2002 23:35:25 -0000

hi jukka,

some background points:

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: 25 October 2002 13:16
> To: [email-masked]
> Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments
> on draft-ietf-nsis-req-04.txt)
> 
> 
> 
> 	(mobility discussions, my favorite! :)

then i am very happy for you, since i am sure there will be lots more...

> 
> 	Hi,
> 
> 	Removing the old reservation is definitely an interesting 
> question, but couldn't you rely on the refresh timers and set 
> them "short 
> enough" for the MN<->AR link? What I am getting at is the following 
> two scenarios:
> 
> a) IF you have a context transfer (CT) mechanism, once the QoS
> requirements at set up on the new AR (& path), the CT mechanisms can
> trigger the NSIS daemon running on the old AR to remove the 
> reservation on
> the old path

during some initial framework discussions and mailing list discussions around the same time (cross posted to seamoby, IIRC) there were considerable objections from some quarters about making the interactions between NSIS and CT too 'intimate'. i think what you are suggesting is respectable, but doesn't necessarily solve the whole problem (see next point).

> 
> b) If you DON'T have CT at hand, you can rely on the soft 
> state mechanism
> to remove the old reservation. How quickly this happens is a 
> question of
> refresh timers and QoS allocation strategies.
> 
> 	I could image having a Tear-message that has a timer associated
> with it: "Remove this reservation when the time comes". Well, to be
> honest, this does sound like a needless hack, so let's stay with the
> "simple" soft state mechanisms... for now...

my initial reaction is: isn't a 'timed Tear' effectively the same as just resetting the refresh timer to the same (small) timer value? but then:
*) i assume the scope of that refresh timer would just be the MN-AR link, you might not be able to control it on interior links where you would typically configure larger values to reduce the refresh load. so you wouldn't be preventing resource wastage on those interior links. or rather...
*) when the state times out at the AR, maybe it would decide to send a Tear-like message into the network anyway. But in that case, what prevents it running wild and tearing the whole e2e path (most of which you want to keep)?

it's identifying and doing the processing at the crossover router (for both traffic directions) which is the hard thing. maybe my throwaway comment about hard handovers should be thrown away.

cheers,

robert

> 	Regards,
> 	Jukka
[old stuff snipped]
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 28 Oct 2002 09:55:53 +0200 (EET)

(some snipping done...:)
(warning: this is getting solution-oriented...)

On Sun, 27 Oct 2002, Hancock, Robert wrote:

> > question, but couldn't you rely on the refresh timers and set them
> > "short enough" for the MN<->AR link? What I am getting at is the
> > following two scenarios:
> > 
> > b) If you DON'T have CT at hand, you can rely on the soft state
> > mechanism to remove the old reservation. How quickly this happens is a
> > question of refresh timers and QoS allocation strategies.
> > 
> my initial reaction is: isn't a 'timed Tear' effectively the same as
> just resetting the refresh timer to the same (small) timer value? but
> then:

> *) i assume the scope of that refresh timer would just be the MN-AR
> link, you might not be able to control it on interior links where you
> would typically configure larger values to reduce the refresh load. so
> you wouldn't be preventing resource wastage on those interior links. or
> rather...

> *) when the state times out at the AR, maybe it would decide to send a
> Tear-like message into the network anyway. But in that case, what
> prevents it running wild and tearing the whole e2e path (most of which
> you want to keep)?
> 
> it's identifying and doing the processing at the crossover router (for
> both traffic directions) which is the hard thing. maybe my throwaway
> comment about hard handovers should be thrown away.
> 

Unfortunately, I am not familiar enough with RSVP to know the following
thing for sure, but would suspect something along: if one host of a
multicast group wants to stop receiving a flow, the application closes the
rapi session which causes a Resv Tear to be sent, right? Now, if there are
other receivers in the multicast tree and the tear arrives at a cross-over
router, it should not send the tear further to the sender but rather stop
it there, since there are other flows still wanting to receive the flow.

So, in the mobility scenario, once the MN has changed ARs, it re-reserves
the resources, which should create a cross-over router somewhere. A
timeout at the old AR could create a tear-event. The new cross-over router
eventually, hopefully soon, gets a tear from the old path, but since there
is reservation active on the new path, it will not forward the tear
further on, thus keeping the reservation intact.

Wouldn't this work for both upstream and downstream flows? A timeout 
creates a Tear-event, which would remove the reservation up to a 
cross-over NSIS-router?

A second point to consider is, whether actual data could be used as an
indication of a refresh: If the reservation has not been explicitly
removed and there is data coming, keep the reservation active. To allow
for different strategies in refreshes, allowing data to be used as refresh
could be indicated to the previous hop on a hop by hop basis - some hops
want to have explicit indications of refresh, some (especially on the
wireless link) can do with actual data. A node not receiving data for a
period of time but still wanting to keep the reservation could use
explicit refresh messages for that. (well, this is an early monday morning
idea, and may need some deeper thinking first, but still...?)

(Isn't the PDP context in GPRS/3GPP nets removed if there is no data
flowing for some time?)

Regards,

Jukka