Re: [DNA] Re: Reclassification of DNA Protocol and new Simple DNAprotocol

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

Hi Bernard,
   Thanks for the comments. Please see my responses inline for simple dna.

Bernard Aboba wrote:
> With respect to the simple solution, I think there are some basic 
> requirements that it needs to meet.  These are summarized in RFC 4436 
> Section 1.1 (paraphrased to fit DNAv6):
> 
>      o  DNAv6 is a performance optimization.  Its purpose is to speed
>         up a process that may require as much as a few hundred
>         milliseconds (DHCPv6), as well as to reduce multi-
>         second conflict detection delays when a host changes networks.

I agree.

> 
>      o  As a performance optimization, it must not sacrifice
>         correctness.  In other words, false positives are not
>         acceptable.  DNAv6 must not conclude that a host has returned
>         to a previously visited link where it has an operable IP
>         address if this is not in fact the case.

Simple DNA will not produce false positives unless two routers on two 
different links happen to have the same link local address and MAC 
address. Is this a likely scenario that needs to be addressed?

> 
>      o  As a performance optimization, false negatives are acceptable.
>         It is not an absolute requirement that this optimization
>         correctly recognize a previously visited link in all possible
>         cases.  This is acceptable as long as the
>         host still operates correctly as it did without DNAv6, just
>         without the performance benefit.

I think Simple DNA works as quick as RFC4861 in the worst case (false 
negative) scenarios.

> 
>      o  As a performance optimization, where DNAv6 fails to provide a
>         benefit, it should add little or no delay compared to today's
>         RS/RA and DHCPv6 processing.  In practice, this implies that this
>         processing needs to proceed in parallel.  Waiting for DNAv6 to
>         fail before beginning RS/RA and DHCPv6 processing can greatly 
> increase
>         total processing time, the opposite of the desired effect.

This is why we send the RS and the NSs in parallel as you suggested. 
This ensures that the simple DNA procedure does not run slower than just 
using RSs.

> 
>      o  Trials are inexpensive.  Assuming that DNAv6 performs its
>         checks using small unicast packets (NS/ND), the
>          cost of an unsuccessful attempt is small, whereas the cost of a
>         missed opportunity (having the right address available as a
>         candidate and choosing not to try it for some reason) is large.
>         As a result, the best strategy is often to try all available
>         candidate configurations, rather than try to determine which
>         candidates, if any, may be correct for this link, based on
>         heuristics or hints.  For a heuristic to offer the prospect of
>         being a potentially useful way to eliminate inappropriate
>         configurations from the candidate list, that heuristic has to
>         (a) be fast and inexpensive to compute, as compared to sending
>         a small unicast packet, and (b) have high probability of not
>         falsely eliminating a candidate configuration that could be
>         found to be the correct one.

The heuristic in use for simple dna is to store and use the previous 'n' 
link configurations. Thus it satisfies (a). It we use a sufficiently 
large value of 'n' we can ensure that (b) is met. We recommend n to be 2 
but if you think that the number is too low we can increase it.

Thanks
Suresh