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

I concur with Ralph's wording.

Caveat:  The second half of it assumes
no change to the random spacing between
probes, which seems less than 100% settled.
Assuming the random delays stand, this wording
is good.

					-Alex

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ralph Droms
> Sent: Tuesday, May 11, 2004 1:43 PM
> To: [email protected]
> Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait
> 
> 
> I don't think the new text correctly captures either of the 
> behaviors we've 
> discussed - I don't see where an initial delay is specified.
> 
> I think this text is correct:
> 
>     When ready to begin probing, the host should then wait 
> for a random
>     time interval selected uniformly in the range 0 to INITIAL_DELAY
>     seconds, and should then send NUM_PROBES probe packets, spaced
>     randomly, PROBE_MIN to PROBE_MAX seconds apart.
> 
> where INITIAL_DELAY is defined somewhere to be 1.
> 
> - 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
> >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 protected]
> >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 0
> >>    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.
> 
>