Subject: DHCP retransmission behaviour

From: Lorenzo Ruggiero <[email-masked]>
Date: Mon, 22 Mar 2010 11:22:49 +0100

Hello,
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?

Regards,
Lorenzo 		 	   		  
_________________________________________________________________
Scatta, ritocca e condividi le tue foto online. Gratis per te
http://www.windowslive.it/foto.aspx

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 22 Mar 2010 10:26:53 -0700

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. 
> 

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 ([email-masked]);

    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/