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

Mika,

Please see http://www.drizzle.com/~aboba/ZEROCONF/ll31.html
This issue was accepted.  It argues that 3 tries are needed
for reliability guarantees.  It states that IPv6 uses 1 second
timeouts and suggests we do the same without motivating that
choice.  Retries are needed for robustness, he asserts, because
there is a real, though small collision chance on 802 technologies.

If there are certain technologies without collisions or with a lower
maximum latency, why not create an additional document entitled
"Timer settings for IPv4 Link Local Autoconfiguration on Foo"?
As discussed previously in this WG there are problems with this
approach.

1 Foo may be bridged to a slower, collision-prone link-layer.  We
   cannot assume interoperation will succeed between the two links
   using values appropriate to Foo but inappropriate to 802.
2 IETF standards have not specified different timer settings for
   different link-layers to my knowledge.
3 Until your specific example of bluetooth, no one had submitted
   specific examples of link-layer technology which would require
   special treatment.

I still think the best way forward is to have knowledgeable folks
inform us as to the maximum latency expectations for link-layers
we are concerned about.  I will contact folks involved with PILC
for their input.

Regards,

Erik


Mika Liljeberg wrote:
> On Wed, 2003-12-17 at 12:07, Robert Elz wrote:
> 
>>  | 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?
> 
> 
>>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%).
> 
> 
> You're missing the point. The spec is telling us to probe the SAME
> ADDRESS three times. The retransmissions might make sense if the link
> has a high loss probability, but address collision probability has
> nothing to do with it.
> 
> Please read this bit again:
> 
> 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
>      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
>      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.
> 
> Regards,
> 
> 	MikaL