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, I'm not sure we're talking about the same thing.

The following text has been in the draft for a long time, and is not in 
dispute:

   When ready to begin probing, the host should then wait for a
   random time interval selected uniformly in the range zero to two
   seconds, and should then send four probe packets, spaced two
   seconds apart. This initial random delay helps ensure that a
   large number of hosts powered on at the same time do not all send
   their initial probe packets simultaneously.

The issue I'm raising is that in draft-08 we replaced that paragraph with 
the one below, which I do not view as an improvement:

   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.

One material result of this change is as follows:

With draft-07, if an Ethernet switch vendor built a product where the 
time from link-up to active forwarding was no more than five seconds, 
then they would be sure to see at least the last of the four probe 
packets. As long as they successfully forward that packet without 
dropping it, then the host has a fair chance of getting reliable conflict 
detection. Accordingly, the switch vendor could truthfully describe such 
a product as being "Zeroconf compatible" or "Zeroconf friendly" (or some 
such wording, which we will let the marketing department worry about).

With draft-08, there is no defined lower bound. The time from link up to 
sending the last probe should average 1.5 seconds, but sometimes it could 
be less than one second. Sometimes it could be less than half a second. 
It could be much less, near-zero on occasion. No matter how fast the 
switch vendor can make their product bring up the port, it can never be 
fast enough to guarantee to see at least one of the probe packets. I fail 
to see how this change improves the standard.

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