Subject: Re: Resend policy

From: [email-masked]
Date: Tue, 9 Apr 2002 10:07:50 +0200

Stuart,

We also have major problems with the Timeout value of 8 seconds.
Not so much the 8 seconds at the start, but the 8 seconds after sensing a 
clash is considered
prohibitively long. (It means disruption of ongoing service during 8 
seconds)

I propose not to fix the de resend intervals but keep them open.
A best resend strategy depends on the environment (for example on wired 
IEEE 1394 another strategy can be 
used than on IEEE 802.11(b) while Bluetooth communication is going on with 
a packet loss
probability of 30%.). I understand that a number of resends is specified 
and that a recommendation is done
for ethernet but that every link-local implementation can decide itself on 
the best intervals as function of
communication technology and transmission statistics. (a minimum interval 
may be specified
to avoid overloads).

Greetings

Peter van der Stok                Philips Research Laboratories Eindhoven
Bldg: WDC 1-015                  Prof. Holstlaan 4
Phone: +31 40 2742649       5656 AA Eindhoven
Fax:      +31 40 2745033       The Netherlands
Mailto: Peter.van.der.Stok@ philips.com

Stuart Cheshire <[email-masked]>
Sent by: [email-masked]
09-04-2002 08:18

        To:     "Nevo Hed" <[email-masked]>
<[email-masked]>
        cc:     (bcc: Peter van der Stok/EHV/RESEARCH/PHILIPS)
        Subject:        Re: Draft status?
        Classification: 

>I skimmed recent posts and could not understand for sure whats
>the current link-local draft state ... the current draft seems
>to be the 04 version and expiration date of January ...
>
>I saw the 'summary of issues...' post from November ... 
>
>Is there any idea if and when link-local will become an RFC?
>
>Thanks
>   -Nevo

I'm glad you asked :-)

As a result of IETF Last-Call on Draft-04, a number of issues were 
raised. The "Summary of Issues" email thread in November proposed 
resolutions to all those issues.

Also, in the DHC Working Group at the Salt-Lake City IETF meeting, one of 
our Area Directors made a very valid observation -- that waiting 8-10 
seconds before using an IP address may be unacceptable for many new 
devices that wish to use Zeroconf. If the Working Group is in agreement, 
I think we can address this concern with the addition of the following 
text:

>2.3 Shorter Timeouts on Appropriate Network Technologies
>
>   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 using DHCP,
>   this 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.
>
>   Should future versions of the IEEE Spanning Tree Protocol be enhanced
>   to inform clients when the link is ready to begin forwarding packets,
>   then the shorter time values may be used on these networks too.

I urge anyone with an opinion for or against this text to send mail to 
the list. If we can get consensus on this last remaining timeout 
question, then as soon as I hear from our Area Directors and from Keith 
Moore that they approve of the resolutions to the earlier issues, I can 
submit draft-05 and request that the RFC Editor publish it as a Standards 
Track RFC.

For those eager to see a preview of what draft-05 should look like, the 
current working copy is available at:

<http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal-04bis.txt>

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org