new issue: [LL37] Aggressive time-outs and total delay range confusion

Description of Issue  Aggressive time-outs and total delay range confusion
Submitter Name  Thomas Narten
Submitter Email Address  [email protected]
Date first submitted  4 Nov 03
Reference  http://www.drizzle.com/~aboba/ZEROCONF/ll12.html
http://www.drizzle.com/~aboba/ZEROCONF/ll20.html
http://www.drizzle.com/~aboba/ZEROCONF/ll31.html
Comment Type ['T'echnical | 'E'ditorial] T
Priority ['S' Must fix | '1' Should fix | '2' May fix ] S
Section
Rationale/Explanation of issue:

Discussion of the 'aggressive time outs' and total delay range

Lengthy description of problem:

1)

The time values specified above are intended for use on technologies
 > such as IEEE 802, 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.

Is the time above right? I count 3 transmission, waiting 1-2 seconds
before starting and two after the last probe, resulting in 5-8 seconds
only. Is there another delay added somewhere?


Erik: 2.2.1 says

    When ready to begin probing, the host should then wait for a random
    time interval selected  uniformly in the range PROBE_MIN to PROBE_MAX
    seconds, and should then send three probe packets, spaced randomly,
    PROBE_MIN to PROBE_MAX seconds apart.

    ...

    If, by PROBE_MAX seconds after the transmission of the last ARP probe
    no conflicting ARP Reply or ARP probe has been received, then the host
    has successfully claimed the desired Link-Local IPv4 address.

    This is an equivalent to 4*PROBE_MIN + PROBE_MAX minimum to 4*PROBE_MAX
    + PROBE_MAX maximum, or 6-10 seconds, right?



=================

2)


But more to the point, where did this IEEE 802 Spanning Tree
motivation come in? Is this even true? Seems like an awful long
delay. When I asked Bernard about this, he didn't seem to think this
was the way LANs actually worked.

Erik:

    The motivation for the 1-2 second delay at each step comes from
    section 1.3:

      This specification applies to all IEEE 802 Local Area Networks
      (LANs) [802], including Ethernet [802.3], Token-Ring [802.5] and
      IEEE 802.11 wireless LANs [802.11], as well as to other link-layer
      technologies that operate at data rates of at least 1 Mbps,
!!!  have a round-trip latency of at most one second,
      and support ARP [RFC826]. Wherever this document uses the
      term "IEEE 802", the text applies equally to any of these network
      technologies.

    Note the 'round-trip latency of at most one second' requirement.
    If this is the case - a timeout of less than one second on any of the
    timers does not make sense.

    Is this a valid timing assumption. Should section 1.3 be revised?

    Christian Huitema argues the timers should be much shorter in
    http://www.drizzle.com/~aboba/ZEROCONF/ll31.html

    How should we revise section 1.3 to accomodate such a change?

==================

3)


 > a chosen IP address may be used. For a desktop machine on an IEEE
 > 802 LAN, 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 IPv4 address may be
 > used.


The above text seems pretty silly. What network technologies would
this be? And since this document isn't immediately applicable to other
technologies (per earlier text), this document probably shouldn't be
saying random implementations can choose _MUCH_ lower timer values
here.

Can someone refresh my thinking on why the subsecond recommendations
above shouldn't be the ones we use in all cases this document applies
to?

Replacement text: I will provide some, if we can agree on what the
right general timers should be.

Erik: An additional argument against this text which has been brought
    up several times is that a bridge may exist between different L2 links.
    Even though one L2 technology would allow shorter delays, some will
    not. The algorithm cannot be so aggressive that it will fail to account
    for address conflicts on slower media. Requested Change: 1)

section 2.3, from

time values specified above result in a delay of 8-10 seconds before

to

time values specified above result in a delay of 6-10 seconds before

=============

2)

no change, unless section 1.3 is to be revised.



=============

3)

proposal: since we can't agree on the text and have been over this four
times in less than a year, let's replace this paragraph with:

Network technologies may emerge for which shorter delays are appropriate
than those required by this document. A subsequent IETF publication may
be produced providing guidelines for different timer settings for 
PROBE_MIN and PROBE_MAX on those technologies.