LL31 Probing intervals

>>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 protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org