Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs

    Date:        Wed, 17 Dec 2003 20:54:20 +0200
    From:        Mika Liljeberg <[email protected]>
    Message-ID:  <1071687260.15146.3.camel@hades>

  | You're missing the point.

I don't think so.

  | The spec is telling us to probe the SAME ADDRESS three times.

Yes, that (or twice, at an absolute minimum) is what needs to happen.

  | The retransmissions might make sense if the link
  | has a high loss probability, but address collision probability has
  | nothing to do with it.

Not true.

What matters is the probability of failure to detect a duplicate address
(that could be detected - ones owned by nodes that are disconnected we can
do nothing about).

That is (approximately) the product of the probability of packet loss
(of either the query, or the reply), and the probability that there is
in fact a duplicate to detect.

For v6, the second of those is a much smaller (MUCH smaller) number than
on v4 (v4 is not just "slightly more probable" to have a conflict, it is
in fact likely there, and almost unimaginable on v6).

That number we cannot do anything about, it is controlled by the number of
available addresses from which to make our random choice.

So, if we want to get the overall probability of failure of v4 LL allocation
down somewhere near what it is for v6, the only thing we can alter to achieve
that is to make the probability of packet loss much smaller - that's done
by simply retransmitting, if the probability of the loss of 1 packet is
0.01% (probably a little high for an ethernet, but not too far away I suspect)
then the probability of either of 2 (query&reply) being lost is a bit more
than that (but I think, if I remember that formula, less than 0.02% - or
was it more?  Doesn't matter much)   The probability of all 3 of 3 attempts
suffering a lost packet is then something like 0.0000000008% if I did the
arithmetic right (which I probably didn't, but it is small anyway).

While not getting us to the overall confidence level of v6, this at least
gets us a lot closer.

  | Please read this bit again:

I read it the first time...

  | Here's my proposal (three fold):
  |      1. Let's specify DAD probe in the same way as in IPv6, defaulting
  |         to a single probe packet

No, that's what we cannot do.   The probability of undetected failure then
is too high.

  |      2. In the event of a conflict (slightly more probable with v4LL
  |         compared to IPv6), allow the node to select a new v4LL and retry
  |         up to, e.g., AddrSelectRetries times

That's not any kind of change.  But the "slightly" should be "much".

  |      3. Let's get rid of the text describing shorter timeouts. If we
  |         default to a single probe, DAD only takes 1..2 seconds (with a
  |         high probability). That is good enough from the usability point
  |         of view.

Since (1) is already ruled out, this becomes irrelevant.

This is no longer important, but ages ago I argued that the timer values
make no sense as they are - 1-2 seconds is way too long to wait for a
reply from a local 802.x style network - if a reply doesn't arrive in (well
under really) 100ms, then it isn't coming.   On the other hand, if the
spanning tree algorithm may be running in a connected switch (which is
actually very likely, every time the address assignment algorithm needs
to run, if connected to a switch port that runs spanning tree), then the
timer values are way too short (at least, the first one).   Either way,
the values specified make no real sense (we could have 3 transmits and be
done in 0.5 seconds if we ignore spanning tree delays).

The WG decided to ignore this - partly I believe out of a desire to spread
out probes, if a large net all happens to start at the same time, which is
a valid concern.   They also decided to ignore spanning trees - because
specifying a timer long enough to cope would irritate lots of people, and
specifying an algorithm to dynamically detect whether a long delay is
needed or not seemed too complex (though several reasonable suggestions were
made).

This isn't something important enough to fight over.   A few more years
(one hopes) and v4 will be header for the scrap heap anyway.

kre