Subject: Re: Current Movement Detection Process and Time (Re: [mobile-ip]Re: closing issue #297 (erik's and steven's technical comments on base))

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 1 May 2003 13:46:51 +0900

Vijay
 
> I disagree, Jari. I think we should describe how to probe
> the default router in the base spec. just mention one way 
> of doing it. and also say that this is *one* way of doing 

It will be good if we present implementators *one* way of 
probing. But I am afraid it will delay MIPv6 I-D further to 
build consensus on *one* way. 

If we can produce *one* way promptly, it's O.K. for me. 
(I even agree to use NS probing for the *one* way :-)) 
If not, I doubt it's worthwhile the delay.  

> I prefer the NS/NA probe to figure out if the default 
> router is reachable. RS/RA has way too many timers 
> governing when a solicitation or an advertisement can be 
> sent. using RS/RA is a bad idea. ofcourse once we have 
> the fastRA mechanism, it can be used.

I agree that NS is better if the reachability of current AR 
is the only thing MN have to check. 

If MN moves, MN have to discover new Router too, 
hence can't avoid RS/ RA exchange. 

And when MN uses NS probing, how will it determine that 
it has moved? Will it use 3 NS probes which take 3 secs?  

In some scenarios, I think it makes more sense to use RS.   

But these are the details which, I suggest, we'd better deal 
with later.  

Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Tue, 06 May 2003 12:24:18 +1000

Hi Vijay,

JinHyeock isn't the only person who thinks that
NS/NA is slow when we need it.

What I think JinHyeock may be saying is that
we don't want to get involved in elaborating
the alternative ideas in the base draft.

Personally, I think that most people have come to the
conclusion that further updates to MIPv6 should be
as small as possible.  If we need to indicate at least
one mechanism, then it should be  simple NS/NA exchange,
and no more.

Greg

Vijay Devarapalli wrote:
> JinHyeock Choi wrote:
> this is FUD. sending NS and waiting for an NA is a very easy
> mechanism. you are the only one who wants to use an RS. and
> IMO, RS/RA mechanism is a bad idea without fastRA.
> 
> Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 May 2003 10:36:40 -0700

I am totally confused by your mail.

> NS/NA is slow when we need it.

NA/NA is slow? or is NUD slow? RS/RA is definitely
slow without fastRA.

> the alternative ideas in the base draft.

I definitely agree with that.

> one mechanism, then it should be  simple NS/NA exchange,

I was asking for this simple NS/NA exchange. and no more.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Wed, 07 May 2003 12:08:22 +1000

Hi Vijay,

> I am totally confused by your mail.

Sorry about that.  It was very short
(probably lacking appropriate detail).

> NA/NA is slow? or is NUD slow? RS/RA is definitely

NUD is slow, but NS/NA is slow
in the same fashion, if the router is
not there to respond to the query.

How long do we wait for the currently
configured access router to respond when
we have already moved off the network?
NUD defaults to 1 second RetransTimer
(* 3 attempts).

This an essential question if NS/NA is used
for movement detection. Today NS/NA works fine
for no-movement detection, but doesn't provide
a timely indication when movement off-link has
occurred.

> I was asking for this simple NS/NA exchange. and no more.

I think that we have to have at least a rough idea (& agreement)
about what we want to achieve with the NS/NA exchange.

If we want to ensure that the AR is not on link, there's
still the question of how long we wait before
determining movement has occurred. Is that RetransTimer
(Default 1000ms, able to be modified in RA)?

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 May 2003 19:36:26 -0700

> we have already moved off the network?

I thought it was implicit. see the exchange between Ed,
Hesham and myself. if I implemented the simple NS/NA probe,
I dont retransmit. I just send one NS, wait for a reply.
if I dont get a reply, assume I have moved. then I would
send a router solicitation to detect new routers. I would
also simulatanously do NUD for the old router. Ed has
implemnted this scheme where the first simple NS/NA probe
becomes part of the NUD probe. he completes doing NUD and
then sends a router solicitation.

how long do I wait for the simple NS/NA probe to complete?
      maybe twice the round trip to my old access router.

what if the NS is lost?
      I am not too concerned. most L2 wireless links do
      retransmission.

this is not a fail proof mechanism.
      okay. I assumed I moved and do both NUD for the old
      router and also send a router solicitation to the
      all routers multicast address.

Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 7 May 2003 12:38:26 +0900

Vijay

Kindly find my in line comments.

> also simulatanously do NUD for the old router. 

I think this is reasonable. But I don't think there is consensus 
in WG. For example Ed's implementation uses 3 NS probes 
instead of timer. 

What I want to say is not that the above is bad but that there 
still remain details to be polished and consensus to be achieved, 
which, I believe, we'd better do separately later. 

> Ed has

What do you mean by 'Ed has implemented this scheme'? 
Correct me if wrong, but in his mail, Ed didn't mention time out 
at all and said it would take 3 probes (3 secs) to detect 
movement. 
 
> JinHyeock, the NS/NA probe was to used when there is no 
> mechanism available for detecting movement and the MN hasnt
> heard from its default router in a long time. it shouldnt 
> be the default mechanism.
 
As you wrote below, if MN changes IP subnet, RS/ RA exchange 
follows after NS/ NA exchange. What I wonder is that we may
do with just one RS/ RA exchange instead of two NS/ NA and 
RS/ RA exchange.'

Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Wed, 07 May 2003 13:38:35 +1000

Hi Vijay,

It's good to have this input.
I'm interested in your opinion on some of the following
items:

>      maybe twice the round trip to my old access router.

I think this has to be considered carefully.

Without link trigger information, the reasons you would
suspect movement are :
loss of RA packets
reception of RA from a new (unseen) router.

In these cases, all nodes may be synchronized on either
the last reception of the old RA, or on the new RA reception.
The RTT could blow out as solicitations are processed, and
also packet losses may be increased on some MACs, if all
nodes solicit immediately.
Obviously nodes which don't require quick movement detection
(no upper layer sessions), could delay before transmission.

Of course, if you are using the new router information as a
movement indication, some sort of active router cache has to be
maintained on the host, so that two routers on the same
network don't cause duelling NS's.  Even in this case,
reception of the RA from the second router to advertise on
a network will cause NS to the first router, by all nodes which
have not seen the router before.

If we have a normal case RTT of approximately 10ms (which seems
typical in our testbed, with 802.11b and pentium 166's as routers),
the mentioned heuristic indicates a wait of 20ms for the NA.
In the case of MAC contention, the time to transmit the packets
could more than double, though.

My guess is that it will vary for each MAC, and may get complicated.

Do you agree that we should avoid specifying timer names and defaults
in the base draft?

This would allow us the opportunity to investigate the issue further.

>      I am not too concerned. most L2 wireless links do

Indeed, although this retransmission should be factored into
the timer for the NS/NA. I'm not too concerned, if the effect
is limited when the NA is not received quickly (see above).

Do you think that the loss of NA means the MN should adopt
the next received RA (in the case where no further
confirmation of reachability is received from the old AR)?

>      all routers multicast address.

This may not be too bad though. In the case where L2 triggers
are in use, the RS may already have been sent, if we
don't serialize these (NS/NA and RS/RA) operations.

In the case where no L2 trigger has been received (either there
was a missed RA or an RA from a new router was received),
I would suggest following the RFC2461 RS delays to prevent
multicast RS bombing, due to the absence of link information.
(this is implicit in MIPv6 anyway).

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 May 2003 10:18:23 -0700

> do with just one RS/ RA exchange instead of two NS/ NA and

but you might be on the same IP subnet still.. I think it
is good to simultaneously probe the old router and discover
new router information through router discovery.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 May 2003 18:51:23 -0700

> Do you agree that we should avoid specifying timer names and defaults

okay.

> confirmation of reachability is received from the old AR)?

if the NS/NA probe fails, the MN should first check if the
old AR is still reachable. just a reminder for others, we are
talking about a weak hint here.

> (this is implicit in MIPv6 anyway).

okay, for now. might change, when I get time to think more about
movement detection.

Vijay