Re: LL31 Probing intervals

Stuart Cheshire wrote:

>>>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.

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 protected]              http://www.stg.com
(708) 547-0110 x225             FAX (708) 547-0783