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

[Bernard Aboba <bernard_aboba@hotmail.com>]

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.

      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.

      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.

      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.

      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.

Today, I do not believe that either the "simple solution" or the "advanced 
solution" meet these requirements.

>   Thanks for the comments. I agree with you as well. I will be submitting 
>a new version of the simple DNA that addresses few of the concerns raised 
>with version -00.