Subject: New Issue [LL31] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?'

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

Description of Issue: Alternate text for 'Does shorter timeouts for
specific link technology lead to problems?'

Submitter Name: Christian Huitema 
Submitter Email Address: <[email-masked]>
First submitted: 11 Apr 03
Reference:  http://www.spybeam.org/ll12.html
            http://www.spybeam.org/ll20.html
Comment type: T (technical)
Priority: S (Must fix)
Section : 2.2
Rationale/ Explanation: See http://www.spybeam.org/ll12
Lengthy description of problem:

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. 

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.

Proposed Resolution: 

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. 

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

Erik Guttman
Zeroconf WG chair

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 May 2003 16:00:20 +0200 (CEST)

I think the proposal is good.

Question: does it also make sense to point out in an Appendix that
Ethernet switches/bridges following IEEE 802.3D defaults, normally block
packets for up to approximately 45 seconds immediately after a bridge
port has been enabled. Techniques for avoiding adverse impact of such L2
behavior is outside of the scope of this protocol. 

That would at least provide a bit of a warning.

  Erik