RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait
Mika Liljeberg <[email protected]> Wed, 05 May 2004 18:37:02 +0300
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <1083771422.1129.9.camel@hades> |
I believe it should have been random initial delay + retransmissions spaced 1 seconds apart, rather than what somehow came out in the document. MikaL On Wed, 2004-05-05 at 07:25, Elder, Alex wrote: > I made this point in my December "document review > blast" e-mail. I'm sorry I didn't make it more > formally. > > I believe there should be an initial delay, but it > should be 0..<something> seconds, although that > <something> need not be related to PROBE_MAX. > (It has more to do with the number of "time slots" > you want to allot for participants to randomly > select from.) > > The proposed text does NOT include any initial > delay, therefore I do not agree with it. > > If the proposal were to have a random initial > delay, with a minimum value zero I would agree > with it. > > -Alex > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On > > Behalf Of Ralph Droms > > Sent: Tuesday, May 04, 2004 7:17 PM > > To: Erik Guttman > > Cc: [email protected] > > Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait > > > > > > 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 > > >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. > > > >