Re: [DNA] Couple of points on draft-jinchoi-dna-soln-frame-00.txt

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Erik, 

----- Original Message -----
From: Erik Nordmark <Erik.Nordmark@sun.com>
Date: Sunday, August 1, 2004 3:42 pm
Subject: Re: [DNA] Couple of points on draft-jinchoi-dna-soln-frame-00.txt

> 
> > >> - that the router lifetime should be honored
> > >> - that the prefix lifetimes should be honored
> > >> - that NUD would probably happen since the NCE is probably stale
> > >> - it may or may not be important to redo DAD
> > > 
> > > 
> > > I think we should try to be more concrete on the last item. 
> 
> Yes, we need to think about this more, but I think there are
> some tricky issues.

Indeed.
 
> > In section 7.1 of draft-narayanan-dna-bcp-00.txt I wrote:
> > 
> > "...In the case that the host arrives back on the same link in 
> time less
> >     than the DAD completion time (minus a packet transmission and
> >     propagation time), the host MAY reclaim the address by sending
> >     Neighbor Advertisement messages as if another host had 
> attempted DAD
> >     while the host was away.  This will prevent DAD completion by 
> another>     node upon NA reception.
> > 
> >     If a host has not been present on a link to defend its 
> address, and
> >     has been absent for a full DAD delay (minus transmission 
> time) the
> >     host MUST undertake the full DAD procedure for each address 
> from that
> >     link it wishes to configure [3]."
> 
> This assumes that the host knows exactly when it stopped receiving 
> packetfrom the link.  Even if we assume a link-down indication from 
> the device
> driver, I doubt that such indications arrive immediately - wouldn't 
> the device
> driver and NIC wait until it stops hearing from the access 
> point/base station
> that is, there would be a timeout of some sort before a 'link-down' 
> wouldbe indicated?

Yes it does assume some idea of when the 
link was previously left.

It's definitely before we received an L2 UP trigger
on the new access router (or an RA),
and extends back to 

In some WLAN devices, there is loss of
synchronization, or explicit (SNR policy 
for example) choice as to when to leave
a network.

So in many cases there's a lag or no explicit
indication.
In devices using upper layer confirmations of
traffic, the NC entry for the router before
router discovery will have been updated before
the nominal link-down time.

If we were receiving traffic that is...

If we're looking at longer scale timers then 
the information is there, if not the granularity
or accuracy.

We may still have a 'insignificant chance' case
as you mentioned below.  If we return while our
chances are very low, then the timers can be made
from an overestimation such of the time, 
so long as the estimate is also in the
'insignificant chance' period.

 
> Tiggering DAD when the host have been disconnected for 1 second
> might be overkill from a probabilistic perspective. Recall that DAD 
> doesn'ttry to catch all cases of duplicate addresses by design 
> (hence it doesn't
> worry about partitioned links healing, and has a limited number of
> transmissions).

DAD may be overkill from a probabilistic view...

I think you mentioned this yesterday to me:

If we return within timeout for routers'
NCE's on the current link, the NS/NA state of
routers will be updated by an unsolicited NA
on DAD success (while we were absent).

In that case, ND/RD messages sent to the routers
will have a different node's link-layer address.




If people ignore our NUD probes or RS's (without
SLLAO) then we may guess that there's a problem...
 
> If you assume a given arrival rate of new hosts onto a link (which can
> potentially have duplicate addresses with the existing hosts) then 
> you can
> calculate the probability that a duplicate is missed should one of
> the existing hosts be disconnected from the link for N seconds.
> It might very well that N can be several minutes without any
> significant probability of making DAD detect less duplicates than it
> does today (taking packet loss into account).

OK.

I think one is a special case of the other, since
the MN going away is the same as packet loss.

I agree though that we're not talking big numbers.
If nodes arrive in the interval, then they'll all
configure non conflicting addresses, and the MN can
collide with any one of them.

Assuming random address distributions we're 
talking about n/2^62.  When we have devices
which both move to the network and then move
away, we have slightly higher probabilities 
(more like birthday problem), but I think 
there would have to be a lot of this going on
to matter.

Even with 128 mn/ second arrival, and 128 seconds,
we're only talking 1 in 2^48 probability for such 
collisions on any single MN.
 
> > Of course, I was writing for current practice, and wasn't relying on
> > Optimistic DAD.  For the solution framework, I'd suggest doing 
> Opti-DAD.
> 
> Yes, but we still need to decide when to trigger opti-DAD.
> For opti-DAD it might be less expensive to tigger than with DAD, so
> perhaps we can trigger it more often.

That's fair enough.

We still have a link seizure though.

Since we can already delay DAD NS for O-1000 ms,
we may avoid doing opti-DAD signalling at all if
we can convince our current router to send an RA
to us at our 'optimistic' address.

If we've got that existing NCE on the router,
we may receive the RA before the NS is sent.

Greg