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:06:04 +0900

Patil 

> I think RS should not be the preferred method for probing anyway. NS
> is preferred.

In some scenario, it may be better to use RS probing. But this is the detail 
which, I suggest, is to be investigated separately later. 

> So would it be sufficient to have text that highlights the problem of
> probing based on RS/NS and recommend the use of L2/L3 indications
> while leaving any details of these out. 
>
> >We may state that
> >1) For movement detection, MN may use either RS/ RA or NS/ NA 
> >    in a manner suitable for the situation. 
> >2) But this probing should not overflow the network.   
> 
> How does the MN really know if he is causing trouble? Hence it is

IMHO, if MN is in doubt that it is causing trouble, it keeps from 
probing (even though it can't be absolutely sure). 

Thanks 

JinHyeock

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 1 May 2003 13:33:36 -0700

Hesham -

OK, I think I agree with you now that handover latency of 4-5 seconds is
generally unacceptable. So then optimized NUD probing isn't really a good
solution. But, in some cases NUD may be the only mechanism available, in
addition to listening for RAs. Note that w/ regards to the RA Advertisement
Interval and RA beacons, if I fail to receive the expected N (i.e. 3) number
of beacons in the expected period, I treat this as a L3 move indication, in
which case I'll solicit w/ RS and skip the NUD probes.

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Hesham Soliman
> Sent: Thursday, May 01, 2003 12:02 PM
> To: 'Ed Remmell'; Vijay Devarapalli; JinHyeock Choi
> Cc: James Kempf; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Current Movement Detection Process and Time (Re:
> [mobile-ip] Re: closing issue #297 (erik's and steven's technical
> comments on base))
>
>
>
>  >
>  > 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,
>
> => I can't think of any application using TCP that
> would find a 3-4 seconds acceptable, unless you're
> assuming that the connection has been terminated and
> the user won't reconnect for another 3-4 seconds. If so
> then you don't have an ongoing connection. We can't design
> MIPv6 for web and email only.
>
> Hesham
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 1 May 2003 17:16:20 -0400

> > => Well, I must admit I haven't read all emails on the topic
 > > but I want to stress one important point: This section is 
 > _educational_.
 > > I.e. it does not and could not mandate anything.
 > > Having said that, you don't need to use the "NUD procedure"
 > > with all its timeouts ...etc. You can simply use an NS/NA
 > > exchange. These messages are always available. In the
 > > presence of fasr RA, I would prefer that to NS/NA, but
 > > for now, why not use NS/NA without having to follow NUD.
 > > And BTW, we don't have to call this use of NS/NA, NUD.
 > 
 > Agreed. But, be careful. Wireless is a lossy technology, in 
 > general. It is
 > likely that a single NS probe is lost, and/or that the 
 > answering solicited
 > NA is lost. So, just sending a single NS probe to verify reachability
 > probably won't work too reliably over wireless.

=> Sure, provided that the link layer does not provide
retransmissions for these messages. I'd be happy with 
something educational like that in the spec and leave
the rest to implementers.

Hesham