Subject: [dhcwg] Re: Issue 36 (Problem Statement)

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Oct 2005 14:36:00 -0700 (PDT)

Stuart Cheshire said:

"However, it turns out (I think) that this is not true. Any candidate 
configuration eligible for DNAv4 is also eligible for DHCP INIT-REBOOT, 
and INIT-REBOOT does *not* require that the client perform address 
conflict detection."

[BA] This is accurate. 

Stuart Cheshire said:

"Thus, all that DNAv4 is accelerating is the DHCP 
INIT-REBOOT REQUEST/ACK cycle."

[BA] DNAv4 can still reduce delays due to conflict detection in
situations where the INIT-REBOOT REQUEST/ACK cycle cannot be used.

For example, if a host has moved between networks, a DHCPREQUEST 
will be answered with a DHCP NAK, in which case a DHCPDISCOVER will 
be sent.  Typically implementations will not use the address on the 
new network until conflict detection is completed, because technically 
it is a *new* configuration, not reuse of an existing (valid) 
configuration. 

With DNAv4, if the new network has been previously vsitied and still
has a valid lease, then the configuration will be confirmed without
the additional NAK/DHCPDISCOVER cycle or the need for conflict detection.
So in this case, the optimization is more substantial. 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Oct 2005 16:28:58 -0700 (PDT)

How about incorporating the proposed text into Section 1.l (Applicability) 
as follows:

"1.1.  Applicability

   DHCP is an effective and widely adopted mechanism for a host to
   obtain an IP address for use on a particular network link, or to re-
   validate a previously obtained address via DHCP's INIT-REBOOT
   mechanism [RFC2131].

   In the case of obtaining a new address, DHCP specifies that the
   client SHOULD use ARP to verify that the offered address is not
   already in use.  The process of address conflict detection [ACD] can
   take as much as seven seconds.  In principle this time interval could
   be shortened, with the obvious trade-off: the less time a host spends
   waiting to see if another host is already using its intended address,
   the greater the risk of inadvertent address conflicts.

   In the case of re-validating a previously obtained address using the
   INIT-REBOOT mechanism, the DHCP specification does not require the
   client to perform address conflict detection, so this seven-second
   delay does not apply.  However, the DHCP server may be slow to
   respond, or may be down and not responding at all, so hosts could
   benefit from having an alternative way to quickly determine that a
   previously obtained address is valid for use on this particular link.
   Also, in situations in which a host has changed networks, a DHCP NAK
   may be received in response to a DHCP REQUEST, in which case, address
   conflict detection might be required after all.  In this case, if an
   address previously obtained on the new network is still operable,
   DNAv4 can be used to confirm the new configuration, bypassing
   conflict detection.

   The alternative mechanism specified by this document applies when a
   host has a previously-allocated DHCP address, which was not returned
   to the DHCP server via a DHCP RELEASE message, and which still has
   time remaining on its lease.  In this case, the host may determine
   whether it has re-attached to the logical link where this address is
   valid for use, by sending a unicast ARP Request packet to the default
   router previously known for that link (or in the case of a link with
   more than one router, by sending one or more unicast ARP Request
   packets to one or more of those routers).

   The use of unicast ARP has a number of benefits.  One benefit is that
   unicast packets impose less burden on the network than broadcast
   packets, particularly on 802.11 networks where a link may have to
   slow down to 1Mb/sec to send a broadcast packet.  Another benefit is
   that in the event of the host not being on the link it hoped to find
   itself on, a broadcast ARP Request could pollute the ARP caches of
   peers on that link.  When using private addresses [RFC1918] another
   device could be legitimately using the same address, and a broadcast
   ARP Request could disrupt its communications, causing TCP connections
   to be broken, and similar problems.  By using a unicast ARP packet
   instead, addressed to the MAC address of the router the host is
   expecting to find, if the host is not on the expected link, then
   there will be no device with that MAC address, and the ARP packet
   will harmlessly disappear into the void without doing any damage.

   These issues that define the applicability of DNAv4 lead us to a
   number of conclusions:

      o DNAv4 is a performance optimization. Its purpose is to take
        a process that is already quite fast (DHCP INIT-REBOOT) and
        make it faster; it also may be used to avoid delays
        associated with DHCP NAK/DISCOVER/conflict detection
        sequences.

      o As a performance optimization, it must not sacrifice
        correctness.  In other words, false positives are not
        acceptable.  DNAv4 must not conclude that a host that 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.  For example, if a router ignores
        unicast ARP Requests then DNAv4 will not be able to detect
        that it has returned to the same link in future.  This is
        acceptable because it does affect correctness.  In this
        case the host still operates correctly, as it did before
        without DNAv4, just without the performance benefit.
        Users and network operators who desire the performance
        improvement offered by DNAv4 can upgrade their routers
        to support DNAv4.

      o As a performance optimization, DNAv4 should not have
        an adverse effect compared to today's status quo.  In
        cases where DNAv4 fails to provide a benefit, it should
        add little or no delay compared to today's existing DHCP
        INIT-REBOOT processing.  The practical effect of this
        statement is that DHCP INIT-REBOOT processing needs to
        proceed in parallel with DNAv4 processing.  In particular,
        waiting for DNAv4 to fail before beginning DHCP processing
        can make an operation that is currently very quick into
        an operation that takes dramatically longer, the opposite
        of the desired effect.

      o Trials are inexpensive.  DNAv4 performs its checks using
        small unicast packets.  An IPv4 ARP packet on Ethernet is
        just 42 octets, including the Ethernet header.  This means
        that 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.  The conclusion we draw from this is that
        the best strategy is often to try all available candidate
        configurations, rather than trying to determine which
        candidates, if any, may be correct for this link, based
        on heuristics or hints.  For a heuristic to usefully
        eliminate a configuration from the candidate list, it has
        to (a) be fast and inexpensive to compute, compared to
        sending a 42-octet unicast packet, and (b) have high
        probability of not falsely eliminating a candidate
        configuration that could be found to be the correct
        one.  For example, eliminating a candidate configuration
        because it was obtained on a different physical interface
        would not be safe.  In the case of an Ethernet link and an
        802.11 wireless link bridged together, an IP address and
        default gateway on the Ethernet link may continue to
        represent a valid and usable configuration if the
        host loses its Ethernet connection and switches to
        802.11 wireless.

      o Time is limited.  On most networks we can reasonably
        expect DHCP INIT-REBOOT processing to complete in a
        few hundred milliseconds at worst.  This means that if
        DNAv4 is to provide a performance benefit compared to
        DHCP INIT-REBOOT, it needs to reduce delays below a
        few tens of milliseconds;  any heuristic used to
        eliminate candidate configurations needs to take at
        most a few milliseconds to compute.  This does not
        leave much room for heuristics based on observation
        link layer or Internet layer traffic."