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

From: Erik Guttman <[email-masked]>
Date: Thu, 3 Apr 2003 18:18:57 +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: 

  [LL12] Does shorter timeouts for specific link technology lead to
problems?

====================================================================
Note that you are asked to choose between LL12 and LL20.
====================================================================

See also http://www.spybeam.org/ll12.html

Description of Issue Does shorter timeouts for specific link technology
text lead to problems?  
Submitter Name Erik Nordmark 
Submitter Email Address [email-masked] 
Date first submitted 6 Feb 2003 
Reference
http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html
http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.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:
The text in the document is bad advice in known cases. Lengthy
description of problem: There is text in section 2.3 which suggests
shorter time outs can be used for 802 media. I suggested some new, less
specific text which Erik Nordmark had continuing issues with. 

> 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. The time values specified above result in a
> delay of 8-10 seconds before a chosen IP address may be used.
> For a desktop machine on Ethernet,
>
>FWIW when 802.1d is enabled on the port I plug in my laptop at the
>office, the delay before the switch starts forwarding packets is 45
>seconds. (I think the 802.1d spec indicates a default time of around
>30 seconds.) So 10 seconds don't seem to do much good.

Later, Erik sent

If we talk about the protocol and not the text, I know of
two interesting cases on IEEE 802 media:
1. No spanning tree on the port to which you connect, or
the port has been enabled for a long time before the
address claim is done. In this case it probably makes
sense to have slightly shorter timers i.e. a few packets
over a few seconds might suffice. Thus 3 seconds instead
of 8.
2. Spanning tree on the port to which you connect.
If the address claim is done immediately after bringing up
the link the host might as well wait for 45 seconds before
sending any packet.

I don't know if the host can tell the difference between #1
and #2 - or if it can "ask" (at the Ethernet layer) if the
switch is running STP.

With RSTP I think the problem goes away and the approach used
in #1 can be used. 

Requested Change: 

Remove the text regarding shortening the timing for different media.
This area is not well enough understood to make any general
recommendations. 

Erik Guttman
Zeroconf WG chair