Re: my response to the proposed changes

>WATCH_WAIT is used in section 2.5 for holding onto one's address after
>defending it against a potential conflict. This seems OK set at 10 seconds
>for 802 links.  (I support Philip Nye's suggested modification to 2.5 and
>WATCH_WAIT's definition in section 9.)

There is no "holding onto one's address".

Section 2.5 is about sending retaliatory (defensive) ARPs to reclaim your 
address when someone else appears to be trying to use it, with the added 
caveat that there's a very conservative rate limit on these defensive 
ARPs to prevent horrible network storms.

Early in the days of OS 9 (before we even had link-local) I saw a bug 
introduced by an inexperienced programmer where two machines manually 
assigned the same address would annihilate the network fighting over the 
address. They'd send 100,000 ARP broadcasts per second, which was a lot 
in those days. The requirement to defend once, then give up, came out of 
that experience.

"WATCH_WAIT" was a brand new concept, just introduced in draft-15, and 
that's exactly the brand new concept I'm opposing here. Section 2.5 
saying NOTHING about watching and waiting.

This is the time line:

Wait (random amount, to decorrelate initial probes)
Probe, wait reasonable time for response
Probe, wait reasonable time for response
Probe, wait reasonable time for response
Announce (to update ARP caches)
** Now you can start using the address **
Wait
Announce (again, in case the first was lost)
...
...
Much later:
See a conflicting ARP from someone else
Fight back
Other guy backs off
All is well
...
...
Much later (more than ten seconds):
See a conflicting ARP from someone else
Fight back
Other guy won't back down, and repeats his conflicting ARP again
Gracefully defer -- getting into a 100,000 packet-per-second fight
   over this won't help anyone.

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org