Subject: LL31 Probing intervals

From: Stuart Cheshire <[email-masked]>
Date: Mon, 23 Jun 2003 21:02:14 -0700

>>When ready to begin probing, the host should then wait
>>for a random time interval selected uniformly in the range
>>zero to one seconds, and should then send three probe
>>packets, spaced randomly, zero to one seconds apart.
>>
>> This means that, technically, if a device waits zero seconds, sends
>> three ARP Probes spaced zero seconds apart, and then immediately
>> begins using the address, that's legal.
>
>While it is technically legal, there is an effective zero probability
>that four random numbers selected uniformly will all occur at the
>same 'zero' value.

"Design for testability" is an important principle throughout computer 
hardware and software design. If you want to know that something is 
operating properly, then the ability to apply objective tests to 
determine that is a big asset.

Any allowed randomness makes objective testing harder. Anyone who has 
wasted time tracking down a hard-to-reproduce bug caused by an 
uninitialized stack variable will tell you the perils of code where the 
execution is different and essentially random every time it is run.

Therefore, randomness in software and hardware design should only be 
applied where the benefit it brings is sufficient to merit bearing the 
cost of the testing and debugging disadvantages that go with it.

A random interval between packets in the range 0-1000ms has no technical 
merit and is clearly indefensible.

A more plausible proposal -- were there strong credible experimental 
evidence and theoretical analysis to support the position that it is 
worth the additional code and testing difficulty -- would be a random 
interval between packets of 1000-1333ms. This means that every device 
must wait between three and four seconds before completing probing. This 
is verifiable through testing. This means that every device waits at 
least 1000ms between packets, so vendors of future Ethernet switches have 
clear guidance about how quickly they must bring the port on-line if they 
wish to have IPv4LL operate reliably. Predicability and knowing what to 
expect is the point of having a standard. Unpredictability and not having 
any idea precisely what the device is allowed to do is not helpful to the 
vendors making products to work in this area.

Were there strong evidence to support the 1000-1333ms proposal, I could 
live with it. However, I strongly doubt that serious research would 
demonstrate any material benefit gained by having the extra randomness in 
addition to the initial random delay. Furthermore, experience dealing 
with device vendors suggests that no one will actually implement this. I 
would prefer us not to have language in a standard that we know is not 
really necessary, and not really implemented by anyone.

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

---

From: "Chris Herzog" <[email-masked]>
Date: Wed, 25 Jun 2003 09:48:22 -0500

> merit and is clearly indefensible.

I'm in strong agreement with Stuart on this topic.  If there are 
boundary cases that are inappropriate to use, unlikely to occur, may 
cause interoperability problems, be difficult to test and verify, but 
still possible *and* compliant with the specification, it would seem 
that the specification should be tightened to exclude them to not just 
consider it covered because it's very unlikely to happen.

 From an implementation perspective, if I had a nickle for every broken 
homebrew random number generator I've come across, well, I'd have a 
quite a number of nickles.  Also allowing very short delays and probing 
times increases the chances of interoperability problems when a number 
of these products get together on the same network.  I'm imagining a 
network of these devices coming up from a cold start where not only the 
devices themselves but the networking infrastructure like switches, 
hubs, etc. all need to come up at the same time.  Allowing very short 
times puts a very stringent requirement on the other network components 
to have to be ready to operate almost instantaneously upon network restart.

-- 
Chris Herzog                    Software Technologies Group, Inc.
mailto:[email-masked]              http://www.stg.com
(708) 547-0110 x225             FAX (708) 547-0783