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:48:37 +0900

Jack

> That is why I said it was not clear to me. On the one hand, use of NUD
> as specified in RFC 2461 will likely not be better, due to the
> problems Erik outlined. On the other, as Vijay has mentioned, RSs have
> lots of timers, so without a simplified RS algorithm it may make
> implementations substantially more complex. Maybe a simple probe would
> work, but after having studied the issue of movement detection and
> handover now for a while, I've learned that algorithms which look
> quite straightforward after some amount of design discussion in
> mailing list traffic and Internet draft text often turn out to have
> hidden complexities that make them poor choices after they are
> implemented and tested. This is why I would prefer to err on the side
> of caution, and only specify what we know works ("running code" and
> further: "tested running code").

Yes. We also encountered similar hidden complexities ourselves. 
We'd better be cautious.

> I'm comfortable with guidelines, what I'd advise against is saying
> "here's a protocol for probing". Jari's proposed solution, with Erik's
> modification, sounded fine.

Yes, I agree with Jack that it's better to use more general terms. Just 
the statement like below is O.K. for me. 

"A node (should) use probing to figure out if the default router is reachable. 
A node (should) minimize traffic involved in MD probing."  
 
Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 May 2003 10:38:29 -0700

> A node (should) minimize traffic involved in MD probing."

you didnt get my point. the problem with this kind of
text is some implementors will just use NUD to do the 
probing. whenever they get a "hint" of movement detection
they would start NUD. this is something we should avoid.
it is good to suggest one mechanism to probe the default
router.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 1 May 2003 11:42:14 -0700

Vijay -

> they would start NUD. this is something we should avoid.

Why is this something we should avoid? Perhaps I miunderstand something
here. My current MN implementation does the following when it receives a
"hint" that a L2 move occurred:

1) immediately send a unicast Neighbor Solicitation probe to the current
default router (same type of probe that NUD uses), and transition the NUD
state of the Neighbor Cache entry for the current default router to PROBE
(skipping the DELAY_1ST_PROBE state).
2) continue probing the current default router per NUD.

This will now cause me to use standard NUD behavior to determine whether or
not the current default router is still reachable. If it is, and my link
connectivity is good quality (note: with wireless, packets will be dropped
in many cases because of general link quality of service issues), then this
optimized NUD procedure completes very quickly (since it is essentially just
unicast NS/NA) to confirm that I actually haven't moved or perhaps I have
moved to a different access point but my current default router hasn't
changed. Otherwise, it takes 3 seconds (per standard NUD behavior, once in
the PROBE state) to determine that the current default router is
unreachable.

Perhaps you mean to say we should avoid this because in a L3 move situation
where my current default router is truly no longer reachable, this takes 3
seconds to complete detection of unreachability which is too slow for the
kind of fast handovers that voice-over-IP needs? If so, then I'd generally
agree, but then not every Mobile IPv6 application requires the same kind of
fast handovers as voice-over-IP (periodic 4-5 second handover latency for
standard web browsing types of applications is probably pretty acceptable,
especially over wireless with typically marginal QoS to begin with and
especially when combined with other wireless TCP optimizations such as fast
retransmits). Also, IMO this type of optimized NUD is a perfectly good
mechanism to use with wireless if you have no better means to detect L3
movement. Remember that with wireless you will have packet loss, so the fact
that it takes 3 NUD probes to finally detect permanent unreachability of
your current default router is a good thing (IMO) because we need some
degree of hysteresis to make the MN prefer to continue using its current
default router rather than switching to a new default router, since the
overhead involved in forming a new CoA and registering a new mobility
binding with both the home agent and with CNs is also fairly distruptive w/
regards to network latency and also should be avoided. With some wireless
networks, it is possible for the MN to be in simultaneous coverage of two
different wireless links, each with their own access router (and different
on-link prefixes) - you don't want the MN to be switching back and forth
between these two links if it really isn't necessary.

FYI, when I get a "hint" of a L3 move, I solicit with a RS, then when I
receive the first RA (after sending the RS) containing a global prefix from
a new current default router, I remove all dynamically discovered entries
associated with the old link including prefix information that isn't
contained in this new RA, and then complete standard MIPv6 L3 move
processing including forming and registering a new primary CoA if the prefix
that my old primary CoA uses is not advertised in this new RA. With FastRA,
I agree this will be pretty fast, and better performing than NUD probing. I
leave it up to the user application whether or not they give me L2 move or
L3 move "hints" (via a public API).

Thanks.
- Ed

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 May 2003 13:24:16 -0700

Ed,

here is Jari's mail.

> So here's my suggestion: 1) keep the current scheme of L2 and
> L3 hints. Then allow the mobile node to probe the router
> if and only if it has taken all L3 hints (no recent RAs,
> no packets from router, nothing on promiscuous mode) and
> still thinks it doesn't hear the router. This would avoid
> bad implementations that probe the router just in case,
> and cause unnecessary traffic on the link.
> 
> 2) Make it very clear that whatever probing is going on,
> we do not call it NUD, nor do we mandate it modifies NUD
> state machine. (Note: looking at the wire, I'm pretty sure
> I can't tell whether Ed's implementation is a part of the
> NUD state machine or an independent process.)
> 
> 3) Leave it open what messages are actually being used
> for the probing. This would allow both RS/RA or NS/NA.
> 
> 4) Further optimizations are in the scope of the future MIP
> WGs.

I was talking about using NS/ND for (3). leaving it open
can make people default to NUD always.

I have no issues with the mechanism you use. it appears
to be very similar to NUD but not exactly NUD.

Vijay