RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait
"Elder, Alex" <[email protected]> Fri, 7 May 2004 07:24:40 -0700
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
My only comment on this is that the paragraph that would follow this one in the document should be updated as well, to indicate something like: If during this period, from the beginning of the probing process until PROBE_INTERVAL seconds after the last probe packet is sent, the host receives any ARP packet (It previously used "PROBE_MAX" rather than "PROBE_INTERVAL".) Also, a few paragraphs later: If, by PROBE_INTERVAL 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. (I haven't done any exhaustive review of the document for this so there could be other spots.) -Alex > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Stuart Cheshire > Sent: Friday, May 07, 2004 12:53 AM > To: [email protected] > Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait > > > >I believe it should have been random initial delay + retransmissions > >spaced 1 seconds apart, rather than what somehow came out in the > >document. > > > > MikaL > > A long time ago, draft-07 said: > > When ready to begin probing, the host should then wait for a > random time interval selected uniformly in the range zero to two > seconds, and should then send four probe packets, spaced two > seconds apart. This initial random delay helps ensure that a > large number of hosts powered on at the same time do not all send > their initial probe packets simultaneously. > > With our new parametrized text, this becomes: > > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range zero to START_WAIT > seconds, and should then send PROBE_NUM probe packets, spaced > PROBE_INTERVAL seconds apart. This initial randomized delay helps > ensure that a large number of hosts powered on at the same time do > not all send their initial probe packets simultaneously. > > I believe this is perfectly adequate. > > Stuart Cheshire <[email protected]> > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org > >