Subject: WG Action - 1 week last call [LL20] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?'

From: Erik Guttman <[email-masked]>
Date: Thu, 3 Apr 2003 18:19:59 +0200 (CEST)

This item is entering a 1 week last call discussion period, ending Apr
10, 2003.  Please send a comment to the working group list indicating
whether you accept or reject the proposal, including more information if
appropriate.  Please use the subject line:

  [LL20] Alternate text for 'Does shorter timeouts for specific link
technology lead to problems?'

-----------------------------------------------------------------
see also http://www.spybeam.org/ll20.html

Description of Issue  Alternate text for 'Does shorter timeouts for
specific link technology lead to problems?'    
Submitter Name  Stuart Cheshire    
Submitter Email Address [email-masked]    
Date first submitted  8 Feb 2003    
Reference
http://www.spybeam.org/ll12.html
Comment Type ['T'echnical | 'E'ditorial]  T    
Priority ['S' Must fix | '1' Should fix | '2' May fix ]  S    
Section 2.3
Rationale/Explanation of issue: 
See LL12 
Lengthy description of problem:
See LL12 
Requested Change: 

The time values specified above result in a delay of 8-10 seconds before
a chosen IP address may be used. The time values specified above are
intended for use on technologies such as Ethernet, where switches that
implement Spanning Tree [802.1d] often silently discard all packets for
several seconds. 

There may be additional delays before a host is able to send and receive
datagrams on a link. Some switches may only forward packets after
several seconds. Implementors should exercise some restraint, therefore,
in setting timers to short, aggressive values. If hosts configure IPv4
link-local addresses before these addresses can be defended, there is an
increased risk of collision once the host is able to send and receive
datagrams on the link. 

For a desktop machine on Ethernet, long delays before network access is
established may not be a great problem, but for other types of device,
particularly portable hand-held wireless devices, a ten-second delay
before networking services becomes available may not be acceptable. For
this reason, shorter time values may be used on network technologies
that allow the device to determine when the link has become active and
can be reasonably trusted to deliver packets reliably. On these network
technologies the recommended time values are: The host should first wait
for a random time interval selected uniformly in the range 0-200
milliseconds, and then send four probe packets, waiting 200 milliseconds
after each probe, making a total delay of 800-1000 milliseconds before a
chosen IP address may be used. 

Erik Guttman
Zeroconf WG chair

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 4 Apr 2003 11:45:59 -0000

I don't know enough to decide between LL20 and LL12.

The text of LL20 strongly suggests (without actually stating) that a
wireless connection is a case where time intervals could be shortened. This
is clearly not true - 802.11 APs frequently bridge (rather than route) to
wired ethernet and connections may be subject to all sorts of restrictions
arising indirectly from the wired infrastructure.

If LL20 is to be adopted, I think the text needs changing to really
emphasise the fact that the host using shorter times needs "to determine
when the link has become active and can be reasonably trusted to deliver
packets reliably". I don't have any knowledge of how the host might
determine this.

LL12 on the other hand points out that the chosen time of 8-10 seconds might
be inadequate with spanning tree switches but makes no attempt to remedy
this.

Philip

----- Original Message -----
From: "Erik Guttman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 03, 2003 4:19 PM
Subject: WG Action - 1 week last call [LL20] Alternate text for 'Does
shorter timeouts for specific link technology lead to problems?'