Re: LL31 Probing Interval
Robert Elz <[email protected]>
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
Date: Wed, 4 Jun 2003 18:55:11 -0700
From: Stuart Cheshire <[email protected]>
Message-ID: <[email protected]>
| This is, I believe, a misapplication of a common design principle. The
| common design principle that's being misapplied is that in a continuing
| ongoing periodic process on multiple machines, you should take care to
| avoid synchronization.
I actually doubt that that one was in anyone's mind here - as you
say, for this, you need a continual stream of packets over time,
and that doesn't exist here.
Rather, I suspect the intent was to avoid having situations arise
where (by whatever chance) several hosts all probe at the same time,
and then continue to all retry at identical times because the
specification allows no method of escape.
The problem is that there can be sudden packet bursts, which can
overwhelm receivers (too many too quickly to receive) - so some
receivers never see some of the probes, and because after the
first attempt, everything repeats identically for each new attempt,
the same nodes keep on not seeing the same probes on every attempt.
That means that the probing isn't really being done at all.
Randomising the retry prevents this kind of synhcronisation from
happening, and makes it very likely that every node will have a
chance to see every other nodes probes, at least for some of the
attempts.
You're correct that as written, the text allows for a host waiting
for 0 time - but if it was observed doing that, I think one could
conclude with a high degree of certainty, that it was in fact broken.
The chances of any random number generator over the interval [0,1]
always generating 0 (or generating continuous 0's over any sample
more than a few) are so small that if that is observed, you can
reasonably claim something is broken (either no random numbers are
being used at all, or the random number generator is defective).
I wouldn't object to fixing the text, but I'd do so by requiring
a wait for a reasonable time for a reply, before probing again.
So, rather than "then send three probe packets, spaced randomly,
zero to one seconds apart" perhaps "then send three probe packets,
spaced randomly 0.1 to one seconds apart".
kre