Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 10 Sep 2002 10:07:28 -0700

Erik,

> 
> > The NA Override flag, as defined in RFC 2461 4.4, is always cleared 
> > during the tentative phase.  So if we imagine the following 
> situation:
> > 
> > * OriginalNode, running normal DAD, has established an address
> > 	and is corresponding via Router
> > 
> > * OptimisticNode appears on the network, and attempts to
> > 	configure the address already used by OriginalNode
> > 	1. Sends a Neighbour Solicitation
> > 	2. Sends a Neighbour Advertisement with O=0
> > 
> > * Router sees the NA, but because it already has a neighbour
> > 	cache entry for that address it ignores it as
> > 	per RFC 2461.
> > 
> > * OriginalNode sees the NS, and responds with an NA
> > 	with O=1, causing OptimisticNode to reconfigure
> > 	with a new address.
> > 
> > * Any nodes on the local subnet which did not previously
> > 	have a neighbour cache entry for OriginalNode
> > 	and which see both NAs will end up with the
> > 	entry for OriginalNode (since it's O=1)
> 
> When happens when OptimisticNode, before seeing the NA from 
> OriginalNode, decides to communicate with PeerNode and sends 
> a NS to PeerNode? Wouldn't that cause PeerNode to overwrite 
> whatever neighbor cache entry it has for the IP address?
> 
But the NA later sent to the all-nodes multicast address from
the OriginalNode would override the entry in the PeerNode
with the right value.

One possibility is that PeerNode has already processed the
NA from the original Node but the Optimistic Node has not
yet processed yet, sends the NS, updates the entry in the
PeerNode. Is this your case ?

-mohan
 
>   Erik

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 10 Sep 2002 11:25:09 -0700

Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and
802.11".

Abstract:
=========
This document describes a way to perform simultaneous Mobile-IPv4
handoff 
and 802.11 Access Point Association/Reassociation. Mobile-IPv4
Registration
messages are carried as Information Elements in 802.11 frames. This way 
Mobile-IPv4 can perform handoff at the same time as 802.11 handoffs.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Sep 2002 14:26:29 -0500

Hello Subrata,
  I was looking at your draft and noticed that you mentioned Scott as 
the author of RFC 2002, no it is Charlie.

Regards,

>Submitted a new draft titled " Simultaneous Handoff of Mobile-IPv4 and

--behcet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 10 Sep 2002 12:44:05 -0700

Hello Behcet,

My role in the production of RFC 2002 is properly described
as "the editor".  There were many contributors, some of whom
authored substantial portions of the text.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 23:22:00 +0200 (CEST)

> PeerNode. Is this your case ?

I'm also concerned that the loss of a single message that should "correct"
the neighbor cache entry that was erronously modified might be lost (by
all or some receivers). If that happens and it causes
a single TCP packet to be delivered to the wrong node it will result in
the TCP connection being reset, thus the effect of this packet loss
is more significant than packet loss for ND packets in general.

Finding the right level of robustness for this type of scheme is tricky
but I haven't thought through all the cases in detail.

  Erik

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 10 Sep 2002 15:06:38 -0700

An oversight, would be corrected. 

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2002 12:26 PM
To: Subrata Goswami
Cc: [email-masked]
Subject: Re: [mobile-ip] Simultaneous Handoff of Mobile-IPv4 and 802.11

Hello Subrata,

Regards,

--behcet

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 11 Sep 2002 09:45:39 +1000

On Tue, Sep 10, 2002 at 11:22:00PM +0200, Erik Nordmark wrote:
> [Mohan Parthasarathy wrote:]
>
> all or some receivers).

Sadly, the same is true for base-case DAD ... if DupAddrDetectTransmits
is 1 (the default), a single lost NS or NA may cause a collision
to go undetected.  

> but I haven't thought through all the cases in detail.

Absolutely.  Given the tiny probabilities involved, I think
it's important for the collision cases to be 'recoverable',
but that they don't need to be 'perfect'.

My aim with this work is to minimise handover latency while not
significantly increasing the risks compared to the RFC 2461/2462
base case. 

Thanks for your comments ...

-----Nick

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 10 Sep 2002 17:07:17 -0700

> is 1 (the default), a single lost NS or NA may cause a collision

True.. In the case of DAC (duplicate address check), since the host
doesn't rely on the "absence of a response", the solution is resilient
to packet loss. Host doesn't start using the new IP address until
it receives a response from the router(s)...

> Thanks for your comments ...

alper

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 11 Sep 2002 10:37:29 +1000

> it receives a response from the router(s)...

Indeed ... as you've all probably gathered, Greg Daley and I are 
working on the same problem from opposite ends ... I'm
working on ways to make the standard stateless method
faster, and he's working on alternative, stateful 
solutions.

I'd agree that a stateful solution could be made more robust
in the case of packet loss, but I'm not sure, given the N/2**64
odds of collision, that it's necessary to do more than the make
the situation recoverable.

cheers,

-----Nick

---

From: Ignacio Soto Campos <[email-masked]>
Date: Wed, 11 Sep 2002 11:17:06 +0200

Hi Nick,

A comment inline.

> the situation recoverable.

The probability of collision is low, but not so low, see
draft-soto-mobileip-random-iids-00.txt

Anyway, it is low enough that there are other sources of problems in 
communications much more probable than that and, on the other hand, we 
have the optimization in handover times.

Best regards,

Ignacio

---

From: Richard Nelson <[email-masked]>
Date: Sat, 12 Oct 2002 08:49:05 +1000

Ignacio,

I like your comparison with other real world probabilities. 

The birthday paradox applies when all addresses in the pool are selected
randomly with uniform probability so that any pair may be identical.  In
Nick's proposal the addresses undergo the standard DAD check and so are
guaranteed to be unique after the period of tentativeness expires.  The
only possible conflicts are with new addesses being used optimistically
for a short period and so the birthday paradox does not apply.

In the real world I suspect the probability will be limited by the
randomness of any PRNGs.

Richard.

---

From: Ignacio Soto Campos <[email-masked]>
Date: Thu, 12 Sep 2002 19:07:03 +0200

Richard,

> for a short period and so the birthday paradox does not apply.

You are right!

Thanks,

Ignacio