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

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."

If this latency were redefined as 375 ms (just to make up a value),
then three retries would take 1.875-3 seconds.  The questions (for
you experts out there) are

  - why are we required to support link-layer technologies with a
    latency of at most one second instead of a lower value?

  - what is the lowest value we could choose and still support most
    (if not all) link-layer technologies?  Which technologies can
    expose hosts to several hundred millisecond latencies?

  - are there other considerations (such as set up time for network
    infrastructure) before ARP requests and replies would propogate to
    hosts?  (Does 5-8 seconds of start up work better for these than
    would, say, 1.875-3 seconds would?)

Thanks,

Erik

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.
> 
> 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
>>
> 


-- 
  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Erik Guttman   -   N1 Manageability   -   Sun Microsystems
       cell: +49 172 865 5497   -   time zone: CET (GMT+1)