Subject: REJECT [LL12][LL20] - Resolution is to open [LL31]

From: Erik Guttman <[email-masked]>
Date: Mon, 5 May 2003 11:07:03 +0200 (MEST)

It appears we accept Christian's suggestion below. It seems reasonable
and there was no additional comment.  

Unless there are any serious objections - this is the outcome of the
discussion:

[LL12] Reject
[LL20] Reject

I will open a new issue [LL31].

Erik

---------------------------------------------------------------------

On Fri, 11 Apr 2003, Christian Huitema wrote:

> Date: Fri, 11 Apr 2003 09:49:40 -0700
> From: Christian Huitema <[email-masked]>
> To: Erik Guttman <[email-masked]>, [email-masked]
> Subject: RE: [LL12] [LL20] discussion not yet conclusive - continue till 17 Apr 03
> 
> Perfection is not achievable: we can always envisage that two
> auto-configured networks are suddenly merged, e.g. by someone plugging a
> wire in a hub. The number of repetitions and the timers are thus a
> compromise between the desired reliability and the time it takes to
> achieve it.
> 
> There is already an equivalent proposed standard, the duplicate address
> detection procedure used during auto-configuration of IPv6 addresses.
> The text says (RFC 2462, page 14):
> 
>    To check an address, a node sends DupAddrDetectTransmits Neighbor
>    Solicitations, each separated by RetransTimer milliseconds. The
>    solicitation's Target Address is set to the address being checked,
>    the IP source is set to the unspecified address and the IP
>    destination is set to the solicited-node multicast address of the
>    target address.
> 
> The retransmission timer can be configured by the routers (through the
> router advertisements), and the default value is set to 1000
> milliseconds (RFC 2641). The default value for DupAddrDetectTransmits in
> RFC 2462 is 1.
> 
> The important value is the residual collision rate after a cycle of
> retransmissions. This probability is a function of the number of hosts,
> the size of the number space, and the probability that a single
> transmission fails. I would contend that the "spanning tree black-out"
> is a rare event that can be incorporated in the transmission failure
> probability; that this transmission failure should generally be under a
> few % for TCP to operate correctly; and that it is safe to assume that
> the probability of a request/response transaction failing is under 5%.
> 
> Under these circumstances, we can compute the residual probability for a
> network of 1300 hosts, a 62 bit number space (RFC 2462), and a
> population of 1300 hosts: it is about 1.4E-17. To achieve the same
> reliability with a 16 bit number space would require 12 repetitions. To
> achieve "five nines" (i.e. a failure rate lower than 10-5) requires 3
> repetitions.
> 
> Setting the timer to 1 second is consistent with RFC 2462. Setting the
> repetition number to 3 achieves a better than 5 nines reliability in
> most networks. 
> 
> I propose to resolve LL12 and LL20 by proposing the following
> replacement text. In section 2.2, replace:
> 
>    When ready to begin probing, the host should then wait for a
>    random time interval selected uniformly in the range zero to two
>    seconds, and should then send four probe packets, spaced two
>    seconds apart. This initial random delay helps ensure that a
>    large number of hosts powered on at the same time do not all send
>    their initial probe packets simultaneously.
> 
> By:
> 
>    Probing is performed in two phases: a random initial interval, 
>    followed by repeated probes. The purpose of the initial interval is 
>    to ensure that a large number of hosts powered on at the same time do
> 
>    not all send their initial probe packets simultaneously. 
> 
>    When ready to begin probing, the host SHOULD then wait for a
>    random time interval selected uniformly in the range zero to 
>    200 milliseconds. During that period, the host should 
>    listen for probes sent by other nodes on the link. If the host
>    receives more than 50 probes during the interval, it SHOULD 
>    restart the timer to a new value, chosen again between 0 and 200
>    milliseconds.
> 
>    Listening during the probing interval introduces an automatic 
>    back-off procedure. It allows the use of a short interval while 
>    ensuring that the number of probes on the network will be at most 
>    a few hundred per second. Hosts that cannot implement the listen 
>    and back-off algorithm described in the previous paragraph MAY simply
>    wait for random spreading interval selected uniformly in the range
> zero 
>    to two seconds.
> 
>    After the random spreading interval, the host SHOULD send 3
>    probe packets, spaced 1 second apart. 
> 
> In fact, we may debate the spacing requirement. A random spacing would
> be better, as it would avoid synchronization effects. And there is no
> real justification for the 1 second interval. A random interval should
> be just as good.
> 
> -- Christian Huitema
> 
> > -----Original Message-----
> > From: Erik Guttman [mailto:[email-masked]]
> > Sent: Friday, April 11, 2003 5:54 AM
> > To: [email-masked]
> > Subject: [LL12] [LL20] discussion not yet conclusive - continue till
> 17
> > Apr 03
> > 
> > 
> > Folks,
> > 
> > Please help try and close these issues by Apr 17.
> > 
> > Aside from the authors of the proposed text it appears no one supports
> > these issue formulations.  Given that there are millions of hosts
> using
> > LL right now with fixed timer values - successfully - this cannot be a
> > very hard problem to get right for a general case.  If it doesn't work
> > in some cases, well gee, we will get conflicts we will have to
> resolve.
> > 
> > Please either support or reject these issues or offer a *simple and
> > complete alternative.*
> > 
> > Erik Guttman
> > Zeroconf WG chair
> > 
> > 
> 
> 
> 
> 

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n                        
 N1 Installation and Provisioning     
 Sun Microsystems                               cell: +49 172 865 5497