On Mon, Mar 22, 2010 at 11:22:49AM +0100, Lorenzo Ruggiero wrote:
> I want to understand better the DHCP retransmit behaviour suggested
> in RFC 2131. RFC says that the client retrive using a backoff
> algorithm. This backoff algorithm will chose retransmission time
> using a value of a uniform random number chosen from the range -1
> to +1.
>
> My question is what 's happen if value is negative(-1,0)?
> If is negative the client won't retransmit?
I think the intent of the RFC 2131 retransmission strategy is for
each retransmission interval to be summed with a random number in the
range (-1,1), clock granularity permitting. So the example initial
4 second timer would be between 3 and 5 seconds inclusive, the next
retransmission is exampled to be between 7 and 9 seconds inclusive.
This strategy isn't well defined, most of the behaviour is not
described in normative language, and the strongest indication
otherwise is a SHOULD. Combine this with the problem that 4 second
retransmission timeouts isn't something most users are willing to
endure while waiting for a network connection, and I think you'll find
a lot of DHCP clients don't precisely implement this falloff
mechanism.
As RFC 2131 says, or how we choose to interpret it today, what's
important is that you use an algorithm that has an exponential growth
and some randomization to keep clients from marching together.
As an example, ISC dhclient starts every query with a fixed interval
with no randomness. Every subsequent retransmission is determined by;
interval += random() % (2 * interval);
Then if the new interval exceeds the backoff_cutoff;
interval = (backoff_cutoff / 2) + (random() % backoff_cutoff);
The implication is that on average the interval will double every
round, until it reaches our cutoff boundary where it will remain
bound between 50% and 150% of the backoff cutoff.
If you want to discuss this further, I invite you to ask on the DHC
WG mailing list (dhcwg@xxxxxxxx);
https://www.ietf.org/mailman/listinfo/dhcwg
--
David W. Hankins BIND 10 needs more DHCP voices.
Software Engineer There just aren't enough in our heads.
Internet Systems Consortium, Inc. http://bind10.isc.org/
Attachment:
pgpr2JYXGoUhM.pgp
Description: PGP signature
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf