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

As I understand this thread, the latency comes from waiting for a 
spanning tree routine to run which to me implies a wan, no?  So a bit 
off kilter here, what is the likelihood that the llv4 situation occurs 
in such a congested, logically disparate locations?  Is it likely that 
linklocal will show up in such an environment?  Given all the discussion 
surrounding moving off of the llv4 address as quickly as possible, even 
in a congested environment what is the likelihood that the number of 
llv4 devices will exist on the network at the same time isd 2 or more?

So in summary I'm wondering what the mean lifetime of a llv4 address is, 
what the probability of two llv4 users occurring at the same time is, 
and the likelihood they'll pick the same address.  The number of probes 
required to uniqueify a llv4 address is in here somewhere I just am 
beginning to doubt the likelihood of a collision.

Bill Rees

Erik Guttman wrote:

> The fundamental assumption which leads us to long time outs is the
> required support for link-layer technologies which "have a round-trip
> latency of at most one second."
>
>
> Mika Liljeberg wrote:
>
>> 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.
>>
>> 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
>>>
>>
>
>