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

I see what you and kre are saying, but I don't buy the number game. The
fact remains that three is a wholly arbitrary number and likely to be
wrong for most environments. Who is to say one probe is not enough? It
all depends on the link error rate and the number of nodes supported by
the link.

For instance, a Bluetooth PAN piconet (radio range 10 meters) supports a
maximum of 7 nodes and the link layer is reliable. Three probes is
completely unnecessary and at the same time constitute a usability
problem, since many of the use cases involve quick ad-hoc interactions. 

My objection to three probes is as I have stated before: 5..8 seconds is
too long from the usability point of view. The feedback gathered from
users of data services in GSM/GPRS networks is overwhelming on this. A
user expects to see results within a few seconds of the first button
press. Address configuration is just one of the initial steps that needs
to take place in a typical use case.

I think we can pretty well start out with the assumption that v4LL
address collisions will sometimes happen. What could be spelled out is,
what is an acceptable probability for failing to detect one? Knowing
that, the number of probe retransmissions can be adjusted accordingly
for a particular environment. IPv6 allows adjusting the number of probes
transmitted. Why should v4LL be any different?

As for it being too late, the last time I raised this point no-one
seemed inclined to discuss it. I must say two responses are a distinct
improvement.

	MikaL

On Wed, 2003-12-17 at 23:04, Philip Nye wrote:
> > From: "Robert Elz" <[email protected]>
> > 
> >   | Instead of trying to figure out how long it takes to send three probes,
> >   | I would like to step back a little and ask the question WHY exactly do
> >   | we have to send THREE PROBES? What exactly in v4LL necessitates sending
> >   | three DAD probes when IPv6 can get away with only one?
> > 
> > v6 has 64 bits of address space, it is incredibly unlikely that something
> > doing random address assignment (which is what is relevant here) is ever
> > going to clash with something else - so one check, no reply, and all is OK.
> > 
> > v4LL has only 16 bits to play in (slightly less because of the exclusions of
> > the first and last /24's from contention) - the birthday paradox tells us
> > that with perfect random assignments we're going to get a clash as soon as
> > the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which
> > is a very rough approximation of the point where probability goes > 50%).
> > 
> > 256 hosts is not at all implausible on a link (2^32 is), so v4LL has to
> > actually expect to get duplicates, where in v6 they are only likely to occur
> > due to human stupidity.   v4LL simply has to try harder to detect those
> > duplicates.
> 
> In addition to this, it is probably the case that IPv4 systems do not cope so well as IPv6 with clashes and changing addresses, so having a higher confidence level that the address you have picked is unique on the link is probably going to make life that bit easier for the user.
> 
> The final and probably strongest argument against Mika's suggestion is that it is way too late in the process to be re-opening this algorithm at this point. Unless you can show that three probes will break where one won't (which I doubt) then we should tidy up the arithmetic so at least we get the answer to 2+2 right, and get it out of the door.
> 
> Philip
>