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

Alex is correct - the second part of the text depends on the outcome of 
issue LL62, I guess...

- Ralph

At 12:43 PM 5/11/2004 -0700, Elder, Alex wrote:
>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.
> >
> >