Re: [DNA-BOF] DAD Optimization Problem Statement - Simple Solution

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

Hi Daniel,

I think this is worth discussing.

Soohong Daniel Park wrote:
> Hi all
> 
> To increase the efficiency of DAD against current DAD, there
> are lots of proposed drafts in now.
> 
> Unlike these, I would like to propose very simple solution.
> 1. considering current real network (especially wireless lan)
> reasons: good performance, hardly ever duplicated MAC.
> 2. skipping random delay (0 ~ 1000 ms)
> reasons: hardly ever this traffic congestions.
> 3. configuring suitably estimated value for NA response (ab 50 ms)
> reasons: too much time for waiting NA response (1000 ms)
> future work: it will be estimated from the variuos tests
> 4. very easy configuration
> reasons: re-configure above parameters into the current code.
> no additional implementations on the node.
> 
> 
> Through above mentions, I believe we can use a very simple solution
> for optimized DAD. I am trying to enable this solution to be a draft.
> 
> Am I missing something ?


While the number of DAD transmissions defaults to 1,
on a wireless link like you've described, we've
seen packet loss rates of 1 in 100, which is certainly
too high for reliable DAD, so we're looking at a system
which  really needs more than one retransmission.
(does this make it 100ms, 150ms?)

I think that one issue is that there is likely to be
transient conditions leading to packet loss on the link.
One reason why RetransTimer is so long is to avoid these
on particular links.

Additionally, the time taken to wake up a wireless device
in power-saving mode may be such that it cannot respond
in 50ms.  In this case, if a node ever went into such a
mode, it may never defend its address in time.

At the moment, the duration of the RetransTimer is
settable by policy in Router Advertisement.
Since the RA may not have been received before DAD
on the link-local address is undertaken, this information
may be unavailable.

I'm not sure whether we can just configure hosts to have
a RetransTimer which they can use without referring to the
RA on the link, which may have been set by the administrator.
For example, the administrator may know of the presence of
slow-responding nodes, or they may wish to rate-limit
RS sends.

Optimistic DAD doesn't modify these parameters, although it
achieves an equivalent optimization without disrupting
non-optimized devices.

Greg