Subject: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait

From: Erik Guttman <[email-masked]>
Date: Wed, 5 May 2004 01:07:14 +0200

Please post discussion of this issue to the mailing list over the 
next two weeks
ending May 18, 2004.  In order to accept this issued, we will need a strong WG
consensus given that this is very late in the process.

Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of
current issues and their status.

[LL61]

Description of Issue:		Remove initial wait
Submitter Name:                 Stuart Cheshire
Submitter Email Address:        [email-masked]
Date first submitted:           04 May 04
Reference:			LL12
Comment Type ['t'ech|'e'dit]:	t
Prio ['S' Must|1 should|2 may]:	S
Section:			2.2.1
Rationale/Explanation:
Lengthy Description:

[Stuart]

>    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 NUM_PROBES probe packets, spaced
>    randomly, PROBE_MIN to PROBE_MAX seconds apart.

Why "wait for a random time interval selected uniformly in the range
PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial
one-second delay? It just slows things down.

[Erik]

This delay was intended to stop a set of hosts from beginning at the
same time in a 'LAN power up' situation.  This text has passed all
reviews and numerous WG issues to revise and hone it.

[Stuart]

I was not asking about the [0,1] random interval. That's been there since
draft-05.

I was asking about why it is now 1 + [0,1]. What's the extra fixed
one-second delay for? What is achieved by making the process uniformly
take a second longer than it should?

[Erik]

     Hmm.  Reviewing all records, I can't see how this entered the doc.
     I don't have time for archeology to find out when it entered.  I
     don't see why waiting an extra second helps, except to wait for
     network infrastructure to come up (see ll12).

Requested Change:

Text was:

    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 NUM_PROBES probe packets, spaced
    randomly, PROBE_MIN to PROBE_MAX seconds apart.

Text becomes:

    When ready to begin probing, the host should send NUM_PROBES probe
    packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 04 May 2004 20:16:31 -0400

Should the initial delay be "0 to PROBE_MAX" seconds?

I think the second randomization is appropriate.

- Ralph

At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote:
>Please post discussion of this issue to the mailing list over the next two 
>weeks
>>    time interval selected uniformly in the range PROBE_MIN 0

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 May 2004 12:00:40 -0000

Agree in principle but suggested text change is wrong.

text should read:

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

Alternatively use PROBE_MIN and PROBE_RANGE:

    When ready to begin probing, the host should then wait for a random
    time interval selected uniformly in the range 0 to PROBE_RANGE
    seconds, and should then send NUM_PROBES probe packets, spaced
    randomly, PROBE_MIN to (PROBE_MIN + PROBE_RANGE) seconds apart.

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 07 May 2004 09:08:03 -0500

>      network infrastructure to come up (see ll12).

If we can't see how it got in, it should be taken out.

john

-- 
Wear the condom. No, for the love of Pete, not the mint-flavored one. Jesus,
that thing burns.