RE: LL31 Probing intervals

The randomization is necessary to avoid synchronized transmission (broadcast storms) if the reconnection is triggered by a synchronized event, e.g. a power failure or the on-off cycling of a wireless access point.
 
Testing a randomized timer is arguably harder than testing a fixed value, but it is not rocket science. Just simulate the link connect/disconnect event, measure the "time to first packet" and observe that the intervals are indeed reasonably random. Then, repeat after simulating collisions, and observes that the unit under test does indeed back-off.
 
And yes, there are implementers who can get their random generators right, even if many platforms do in fact come with a strong random number generator. But even so, we would not be worse off than if they had used fixed timers.
 
-- Christian Huitema

________________________________

From: [email protected] on behalf of Stuart Cheshire
Sent: Mon 6/23/2003 9:02 PM
To: [email protected]
Subject: 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