Debian Bug report logs - #509089
isc-dhcp-client: speed up lease negotiation

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Michel Lespinasse <walken@zoy.org>

To: submit@bugs.debian.org

Subject: dhcp lease negotiation takes longer than necessary

Date: Thu, 18 Dec 2008 00:13:27 -0800

[Message part 1 (text/plain, inline)]

Package: dhcp3-client
Version: 3.1.1-5
Tags: patch

While trying to figure out why it takes so long to up an interface using
dhcp, I had a look at the source code. It seemed to me that a lot of
the delays were unnecessary. After fixing what I saw, it now takes about
a quarter second to up an interface on my wired network - I thought I
should send the patches here, in case there is an interest.


dhcp3-client-1.diff fixes the delays between consecutive requests
(the backoff algorithm). This algorithm is best explained in the
following code comment:
        /* If we're supposed to increase the interval, do so.  If it's
           currently zero (i.e., we haven't sent any packets yet), set
           it to initial_interval; otherwise, add to it a random number
           between zero and two times itself.  On average, this means
           that it will double with every transmission. */
However contrary to what the comment indicates, client->interval has
been initialised, before the first request is sent, to the initial_interval
value rather than to 0. Because of that, the delay between the first two
requests is, on average, double of the initial_interval value, instead of
being equal to the initial_interval value. I'm proposing to change the
initialization value to zero, in order to match the programmers expectations
as documented in that comment, and to have the initial-interval option
in dhclient.conf work as per the documented behavior.

Additionally, I'm proposing to enforce that the delay between consecutive
requests is always at least one second - this was already the case when
using the default values, but could be messed with if setting an
initial-interval of 0 or a backoff-cutoff of 1. Some people
(see for example http://syn.theti.ca/ ) have been suggesting to use
a backoff-cutoff of 1, so such configurations do exist in the wild.


dhcp3-client-2.diff fixes a separate issue: the dhcp client was waiting
a random delay, between 0 and 4 seconds, before sending the first dhcp
request. The maximum delay was hardcoded and this behavior was not documented
anywhere, but my guess is that this may have been intended to reduce dhcp
floods when a large number of machines boot at the same time, following
a power failure for example. It seems to me however, that such a delay is
not necessary in many common situations, such as when running on a laptop
with its own battery... I don't feel bold enough to just remove that random
delay, but I think adding a new dhclient.conf option named
initial-random-delay, which would default to 4 but be user-settable to
any desired maximum random delay value, including 0 for no delay,
is a reasonable proposal. Laptop users could then be encouraged to use
initial-random-delay = 0.


The third delay I identified was in the dhclient-script. The packaged script
sleeps for one second after upping the interface with an ip address of 0
(this is, in the PREINIT stage before sending out the first dhcp request).
A comment there says this is because the kernel needs some time to get the
interface up. I believe this is not true of current kernels. In some
situations, I can imagine that link negotiation could take a little time
and cause packets to be lost during that interval, but this does not happen
for the most common situations of using ifplugd or wpa-supplicant roaming,
for example. Also even if it does happen in some wired situations, it seems
that the worst case would be that the first request would get dropped and
that a subsequent retransmit would work. So, I would propose to drop that
one second delay as well.


After implementing these proposed changes (as well as an additional change
in ifplugd, as documented in bug 509015) I can get a wired dhcp connection
within a quarter second of plugging in the ethernet cable. The only
configuration parameter I need to apply is initial-random-delay=0 - the
other parameters governing the backoff algorithm do not even have to be
modified. Without these changes the dhcp connection would take anywhere
from 2 to 7 seconds to negociate.

Hope this helps,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[dhcp3-client-1.diff (text/x-diff, attachment)]

[dhcp3-client-2.diff (text/x-diff, attachment)]

Message #8 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: Debian Bug Tracking System <509089@bugs.debian.org>

Subject: dhcp3-client: [PATCH] Reduce dhcp lease negotiation time

Date: Thu, 05 Mar 2009 12:23:58 -0800

[Message part 1 (text/plain, inline)]

Package: dhcp3-client
Version: 3.1.1-6
Followup-For: Bug #509089

The attached patch adds both of Michel's patches to dhcp3 as dpatches in
debian/patches, and makes the suggested change to dhclient-script.  I
can confirm that these changes, together with setting
initial-random-delay to 0 in dhclient.conf, significantly reduce the
time needed to negotiate a DHCP lease.

Please consider applying the attached patch.

Please also consider changing the default dhclient.conf to set
initial-random-delay to 0, initial-interval to 1, and backoff-cutoff to
1.

- Josh Triplett

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dhcp3-client depends on:
ii  debconf [debconf-2.0]         1.5.26     Debian configuration management sy
ii  debianutils                   2.31       Miscellaneous utilities specific t
ii  dhcp3-common                  3.1.1-6    common files used by all the dhcp3
ii  libc6                         2.9-4      GNU C Library: Shared libraries

dhcp3-client recommends no packages.

Versions of packages dhcp3-client suggests:
pn  avahi-autoipd                 <none>     (no description available)
pn  resolvconf                    <none>     (no description available)

-- debconf information excluded

[dhcp3-509089.patch (text/x-diff, attachment)]

Message #11 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: Debian Bug Tracking System <509089@bugs.debian.org>

Subject: dhcp3-client: Status of this bug?

Date: Thu, 18 Jun 2009 23:04:58 -0700

I've run with these patches for several months now, and they work
wonderfully.  I get a DHCP lease far faster with these patches than
without.  Any plans to apply these patches, and to change the default
dhclient.conf to take advantage of them?

Thanks,
Josh Triplett

Message #16 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Andrew Pollock <apollock@debian.org>

To: Josh Triplett <josh@freedesktop.org>, 509089@bugs.debian.org

Subject: Re: Bug#509089: dhcp3-client: Status of this bug?

Date: Fri, 19 Jun 2009 16:31:21 +1000

[Message part 1 (text/plain, inline)]

On Thu, Jun 18, 2009 at 11:04:58PM -0700, Josh Triplett wrote:
> I've run with these patches for several months now, and they work
> wonderfully.  I get a DHCP lease far faster with these patches than
> without.  Any plans to apply these patches, and to change the default
> dhclient.conf to take advantage of them?
> 

My general policy is not to deviate from upstream unless absolutely
necessary, so these patches should be sent upstream.

dhclient-script is obviously the exception, as it's Debian-specific. I'll
look at merging that patch in a future release. I'm currently concentrating
on DHCP 4.1.

regards

Andrew

[signature.asc (application/pgp-signature, inline)]

Message #21 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: Andrew Pollock <apollock@debian.org>

Cc: 509089@bugs.debian.org

Subject: Re: Bug#509089: dhcp3-client: Status of this bug?

Date: Thu, 2 Jul 2009 15:00:25 -0700

On Fri, Jun 19, 2009 at 04:31:21PM +1000, Andrew Pollock wrote:
> On Thu, Jun 18, 2009 at 11:04:58PM -0700, Josh Triplett wrote:
> > I've run with these patches for several months now, and they work
> > wonderfully.  I get a DHCP lease far faster with these patches than
> > without.  Any plans to apply these patches, and to change the default
> > dhclient.conf to take advantage of them?
> 
> My general policy is not to deviate from upstream unless absolutely
> necessary, so these patches should be sent upstream.

I understand, and that seems sensible.  Any plans to poke upstream about
these patches?  Any upstream bug-tracking system to which someone could
send these patches?  Or does "sent upstream" just mean "poke the mailing
list and hope it doesn't get lost"?

> dhclient-script is obviously the exception, as it's Debian-specific. I'll
> look at merging that patch in a future release. I'm currently concentrating
> on DHCP 4.1.

OK.

- Josh Triplett

Message #26 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Andrew Pollock <apollock@debian.org>

To: Josh Triplett <josh@freedesktop.org>

Cc: 509089@bugs.debian.org

Subject: Re: Bug#509089: dhcp3-client: Status of this bug?

Date: Fri, 3 Jul 2009 08:16:57 +1000

On Thu, Jul 02, 2009 at 03:00:25PM -0700, Josh Triplett wrote:
> On Fri, Jun 19, 2009 at 04:31:21PM +1000, Andrew Pollock wrote:
> > On Thu, Jun 18, 2009 at 11:04:58PM -0700, Josh Triplett wrote:
> > > I've run with these patches for several months now, and they work
> > > wonderfully.  I get a DHCP lease far faster with these patches than
> > > without.  Any plans to apply these patches, and to change the default
> > > dhclient.conf to take advantage of them?
> > 
> > My general policy is not to deviate from upstream unless absolutely
> > necessary, so these patches should be sent upstream.
> 
> I understand, and that seems sensible.  Any plans to poke upstream about
> these patches?  Any upstream bug-tracking system to which someone could
> send these patches?  Or does "sent upstream" just mean "poke the mailing
> list and hope it doesn't get lost"?

I'm having lunch with upstream next week. I am planning on going through all
of the open Debian bugs as well as the ones I've sent upstream to determine
the status of them.
 
> > dhclient-script is obviously the exception, as it's Debian-specific. I'll
> > look at merging that patch in a future release. I'm currently concentrating
> > on DHCP 4.1.
> 
> OK.
> 
> - Josh Triplett
> 

Message #31 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@freedesktop.org>

To: Andrew Pollock <apollock@debian.org>

Cc: 509089@bugs.debian.org

Subject: Re: Bug#509089: dhcp3-client: Status of this bug?

Date: Thu, 2 Jul 2009 15:21:18 -0700

On Fri, Jul 03, 2009 at 08:16:57AM +1000, Andrew Pollock wrote:
> On Thu, Jul 02, 2009 at 03:00:25PM -0700, Josh Triplett wrote:
> > On Fri, Jun 19, 2009 at 04:31:21PM +1000, Andrew Pollock wrote:
> > > On Thu, Jun 18, 2009 at 11:04:58PM -0700, Josh Triplett wrote:
> > > > I've run with these patches for several months now, and they work
> > > > wonderfully.  I get a DHCP lease far faster with these patches than
> > > > without.  Any plans to apply these patches, and to change the default
> > > > dhclient.conf to take advantage of them?
> > > 
> > > My general policy is not to deviate from upstream unless absolutely
> > > necessary, so these patches should be sent upstream.
> > 
> > I understand, and that seems sensible.  Any plans to poke upstream about
> > these patches?  Any upstream bug-tracking system to which someone could
> > send these patches?  Or does "sent upstream" just mean "poke the mailing
> > list and hope it doesn't get lost"?
> 
> I'm having lunch with upstream next week. I am planning on going through all
> of the open Debian bugs as well as the ones I've sent upstream to determine
> the status of them.

Awesome!

Thank you for maintaining the DHCP client packages.

- Josh Triplett

Message #36 received at 509089@bugs.debian.org (full text, mbox, reply):

From: Andrew Pollock <apollock@debian.org>

To: dhcp-bugs@isc.org

Cc: walken@zoy.org, 509089-forwarded@bugs.debian.org, 509089@bugs.debian.org

Subject: [walken@zoy.org: Bug#509089: dhcp lease negotiation takes longer than necessary]

Date: Sun, 1 Nov 2009 14:43:22 -0800

Hi,

I'm pretty certain that we discussed this bug when we last had lunch together,
but I don't think I ever forwarded it upstream and got an upstream bug number
for it, so here it is.

Please maintain the cc line to keep our bug tracking system in the loop.

regards

Andrew

----- Forwarded message from Michel Lespinasse <walken@zoy.org> -----

Subject: Bug#509089: dhcp lease negotiation takes longer than necessary
Reply-To: Michel Lespinasse <walken@zoy.org>, 509089@bugs.debian.org
Resent-From: Michel Lespinasse <walken@zoy.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Andrew Pollock <apollock@debian.org>
Resent-Date: Thu, 18 Dec 2008 08:18:02 +0000
Resent-Message-ID: <handler.509089.B.12295880094275@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 509089
X-Debian-PR-Package: dhcp3-client
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: dhcp3
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rietz.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0.0000 Tokens: new, 154; hammy, 144; neutral, 267; spammy,
	7. spammytokens:0.999-1--8396, 0.999-1--8398, 0.999-1--retransmit,
	0.998-1--9477, 0.998-1--EXECUTE hammytokens:0.000-+--H*UA:1.5.13,
	0.000-+--H*UA:2006-08-11, 0.000-+--H*u:1.5.13, 0.000-+--H*u:2006-08-11,
	0.000-+--UD:conf
X-Spam-Status: No, score=-9.1 required=4.0 tests=BAYES_00,FOURLA,HAS_PACKAGE,
	MDO_CABLE_TV3,MURPHY_DRUGS_REL8,MURPHY_SEX_L2,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
From: Michel Lespinasse <walken@zoy.org>
To: submit@bugs.debian.org

Package: dhcp3-client
Version: 3.1.1-5
Tags: patch

While trying to figure out why it takes so long to up an interface using
dhcp, I had a look at the source code. It seemed to me that a lot of
the delays were unnecessary. After fixing what I saw, it now takes about
a quarter second to up an interface on my wired network - I thought I
should send the patches here, in case there is an interest.


dhcp3-client-1.diff fixes the delays between consecutive requests
(the backoff algorithm). This algorithm is best explained in the
following code comment:
        /* If we're supposed to increase the interval, do so.  If it's
           currently zero (i.e., we haven't sent any packets yet), set
           it to initial_interval; otherwise, add to it a random number
           between zero and two times itself.  On average, this means
           that it will double with every transmission. */
However contrary to what the comment indicates, client->interval has
been initialised, before the first request is sent, to the initial_interval
value rather than to 0. Because of that, the delay between the first two
requests is, on average, double of the initial_interval value, instead of
being equal to the initial_interval value. I'm proposing to change the
initialization value to zero, in order to match the programmers expectations
as documented in that comment, and to have the initial-interval option
in dhclient.conf work as per the documented behavior.

Additionally, I'm proposing to enforce that the delay between consecutive
requests is always at least one second - this was already the case when
using the default values, but could be messed with if setting an
initial-interval of 0 or a backoff-cutoff of 1. Some people
(see for example http://syn.theti.ca/ ) have been suggesting to use
a backoff-cutoff of 1, so such configurations do exist in the wild.


dhcp3-client-2.diff fixes a separate issue: the dhcp client was waiting
a random delay, between 0 and 4 seconds, before sending the first dhcp
request. The maximum delay was hardcoded and this behavior was not documented
anywhere, but my guess is that this may have been intended to reduce dhcp
floods when a large number of machines boot at the same time, following
a power failure for example. It seems to me however, that such a delay is
not necessary in many common situations, such as when running on a laptop
with its own battery... I don't feel bold enough to just remove that random
delay, but I think adding a new dhclient.conf option named
initial-random-delay, which would default to 4 but be user-settable to
any desired maximum random delay value, including 0 for no delay,
is a reasonable proposal. Laptop users could then be encouraged to use
initial-random-delay = 0.


The third delay I identified was in the dhclient-script. The packaged script
sleeps for one second after upping the interface with an ip address of 0
(this is, in the PREINIT stage before sending out the first dhcp request).
A comment there says this is because the kernel needs some time to get the
interface up. I believe this is not true of current kernels. In some
situations, I can imagine that link negotiation could take a little time
and cause packets to be lost during that interval, but this does not happen
for the most common situations of using ifplugd or wpa-supplicant roaming,
for example. Also even if it does happen in some wired situations, it seems
that the worst case would be that the first request would get dropped and
that a subsequent retransmit would work. So, I would propose to drop that
one second delay as well.


After implementing these proposed changes (as well as an additional change
in ifplugd, as documented in bug 509015) I can get a wired dhcp connection
within a quarter second of plugging in the ethernet cable. The only
configuration parameter I need to apply is initial-random-delay=0 - the
other parameters governing the backoff algorithm do not even have to be
modified. Without these changes the dhcp connection would take anywhere
from 2 to 7 seconds to negociate.

Hope this helps,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

diff -ru dhcp3-3.1.1.orig/client/dhclient.c dhcp3-3.1.1/client/dhclient.c
--- dhcp3-3.1.1.orig/client/dhclient.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/dhclient.c	2008-12-16 23:44:39.000000000 -0800
@@ -578,7 +579,7 @@
 	make_request (client, client -> active);
 	client -> destination = iaddr_broadcast;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Zap the medium list... */
 	client -> medium = (struct string_list *)0;
@@ -604,7 +605,7 @@
 	client -> destination = iaddr_broadcast;
 	client -> state = S_SELECTING;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Add an immediate timeout to cause the first DHCPDISCOVER packet
 	   to go out. */
@@ -676,7 +677,7 @@
 	client -> destination = iaddr_broadcast;
 	client -> state = S_REQUESTING;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Make a DHCPREQUEST packet from the lease we picked. */
 	make_request (client, picked);
@@ -947,7 +948,7 @@
 		client -> destination = iaddr_broadcast;
 
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 	client -> state = S_RENEWING;
 
 	/* Send the first packet immediately. */
@@ -1487,6 +1488,10 @@
 			(client -> first_sending +
 			 client -> config -> timeout) - cur_time + 1;
 
+	/* Make sure the computed interval is at least one second. */
+	if (!client->interval)
+		client->interval = 1;
+
 	/* Record the number of seconds since we started sending. */
 	if (interval < 65536)
 		client -> packet.secs = htons (interval);
@@ -1714,6 +1719,10 @@
 		client -> interval =
 			client -> active -> expiry - cur_time + 1;
 
+	/* Make sure the computed interval is at least one second. */
+	if (!client->interval)
+		client->interval = 1;
+
 	/* If the lease T2 time has elapsed, or if we're not yet bound,
 	   broadcast the DHCPREQUEST rather than unicasting. */
 	if (client -> state == S_REQUESTING ||
@@ -2882,7 +2891,7 @@
 		} else
 			client -> destination = iaddr_broadcast;
 		client -> first_sending = cur_time;
-		client -> interval = client -> config -> initial_interval;
+		client -> interval = 0;
 	
 		/* Zap the medium list... */
 		client -> medium = (struct string_list *)0;

diff -ru dhcp3-3.1.1.orig/client/clparse.c dhcp3-3.1.1/client/clparse.c
--- dhcp3-3.1.1.orig/client/clparse.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/clparse.c	2008-12-16 23:21:38.000000000 -0800
@@ -78,6 +78,7 @@
 	top_level_config.reboot_timeout = 10;
 	top_level_config.retry_interval = 300;
 	top_level_config.backoff_cutoff = 15;
+	top_level_config.initial_random_delay = 4;
 	top_level_config.initial_interval = 3;
 	top_level_config.bootp_policy = P_ACCEPT;
 	top_level_config.script_name = path_dhclient_script;
@@ -477,6 +478,11 @@
 		parse_lease_time (cfile, &config -> backoff_cutoff);
 		return;
 
+	      case INITIAL_RANDOM_DELAY:
+		token = next_token (&val, (unsigned *)0, cfile);
+		parse_lease_time (cfile, &config -> initial_random_delay);
+		return;
+
 	      case INITIAL_INTERVAL:
 		token = next_token (&val, (unsigned *)0, cfile);
 		parse_lease_time (cfile, &config -> initial_interval);
diff -ru dhcp3-3.1.1.orig/client/dhclient.c dhcp3-3.1.1/client/dhclient.c
--- dhcp3-3.1.1.orig/client/dhclient.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/dhclient.c	2008-12-16 23:44:39.000000000 -0800
@@ -424,7 +424,8 @@
 				client -> state = S_INIT;
 				/* Set up a timeout to start the initialization
 				   process. */
-				add_timeout (cur_time + random () % 5,
+				add_timeout (cur_time + random () %
+					     (client->config->initial_random_delay+1),
 					     state_reboot, client, 0, 0);
 			}
 		}
@@ -3004,7 +3013,8 @@
 			client -> state = S_INIT;
 			/* Set up a timeout to start the initialization
 			   process. */
-			add_timeout (cur_time + random () % 5,
+			add_timeout (cur_time + random () %
+				     (client->config->initial_random_delay+1),
 				     state_reboot, client, 0, 0);
 		}
 	}
diff -ru dhcp3-3.1.1.orig/common/conflex.c dhcp3-3.1.1/common/conflex.c
--- dhcp3-3.1.1.orig/common/conflex.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/common/conflex.c	2008-12-16 23:20:19.000000000 -0800
@@ -804,6 +804,8 @@
 			return IS;
 		if (!strcasecmp (atom + 1, "gnore"))
 			return IGNORE;
+		if (!strcasecmp (atom + 1, "nitial-random-delay"))
+			return INITIAL_RANDOM_DELAY;
 		break;
 	      case 'k':
 		if (!strncasecmp (atom + 1, "nown", 4)) {
diff -ru dhcp3-3.1.1.orig/includes/dhcpd.h dhcp3-3.1.1/includes/dhcpd.h
--- dhcp3-3.1.1.orig/includes/dhcpd.h	2008-12-16 22:06:59.000000000 -0800
+++ dhcp3-3.1.1/includes/dhcpd.h	2008-12-16 23:18:05.000000000 -0800
@@ -839,6 +839,8 @@
 	TIME timeout;			/* Start to panic if we don't get a
 					   lease in this time period when
 					   SELECTING. */
+	TIME initial_random_delay;	/* Maximum random delay before sending
+					   first request. */
 	TIME initial_interval;		/* All exponential backoff intervals
 					   start here. */
 	TIME retry_interval;		/* If the protocol failed to produce
diff -ru dhcp3-3.1.1.orig/includes/dhctoken.h dhcp3-3.1.1/includes/dhctoken.h
--- dhcp3-3.1.1.orig/includes/dhctoken.h	2008-12-16 22:06:59.000000000 -0800
+++ dhcp3-3.1.1/includes/dhctoken.h	2008-12-16 23:19:25.000000000 -0800
@@ -325,7 +325,8 @@
 	MIN_BALANCE = 629,
 	DOMAIN_LIST = 630,
 	LEASEQUERY = 631,
-	EXECUTE = 632
+	EXECUTE = 632,
+	INITIAL_RANDOM_DELAY = 633
 };
 
 #define is_identifier(x)	((x) >= FIRST_TOKEN &&	\


----- End forwarded message -----

Message #44 received at 509089-quiet@bugs.debian.org (full text, mbox, reply):

From: Andrew Pollock <apollock@debian.org>

To: 509089-quiet@bugs.debian.org

Subject: [dhcp-bugs@isc.org: [ISC-Bugs #20556] AutoReply: [walken@zoy.org: Bug#509089: dhcp lease negotiation takes longer than necessary]]

Date: Mon, 2 Nov 2009 09:10:44 +1000

----- Forwarded message from DHCP Bugs via RT <dhcp-bugs@isc.org> -----

From: DHCP Bugs via RT <dhcp-bugs@isc.org>
To: apollock@debian.org
Subject: [ISC-Bugs #20556] AutoReply: [walken@zoy.org: Bug#509089: dhcp lease negotiation takes longer than necessary] 
Date: Sun, 1 Nov 2009 22:43:31 +0000


Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
	"[walken@zoy.org: Bug#509089: dhcp lease negotiation takes longer than necessary]", 
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [ISC-Bugs #20556].

Please include the string:

         [ISC-Bugs #20556]

in the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.

                        Thank you,
                        dhcp-bugs@isc.org

-------------------------------------------------------------------------
Hi,

I'm pretty certain that we discussed this bug when we last had lunch together,
but I don't think I ever forwarded it upstream and got an upstream bug number
for it, so here it is.

Please maintain the cc line to keep our bug tracking system in the loop.

regards

Andrew

----- Forwarded message from Michel Lespinasse <walken@zoy.org> -----

Subject: Bug#509089: dhcp lease negotiation takes longer than necessary
Reply-To: Michel Lespinasse <walken@zoy.org>, 509089@bugs.debian.org
Resent-From: Michel Lespinasse <walken@zoy.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Andrew Pollock <apollock@debian.org>
Resent-Date: Thu, 18 Dec 2008 08:18:02 +0000
Resent-Message-ID: <handler.509089.B.12295880094275@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 509089
X-Debian-PR-Package: dhcp3-client
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: dhcp3
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rietz.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0.0000 Tokens: new, 154; hammy, 144; neutral, 267; spammy,
	7. spammytokens:0.999-1--8396, 0.999-1--8398, 0.999-1--retransmit,
	0.998-1--9477, 0.998-1--EXECUTE hammytokens:0.000-+--H*UA:1.5.13,
	0.000-+--H*UA:2006-08-11, 0.000-+--H*u:1.5.13, 0.000-+--H*u:2006-08-11,
	0.000-+--UD:conf
X-Spam-Status: No, score=-9.1 required=4.0 tests=BAYES_00,FOURLA,HAS_PACKAGE,
	MDO_CABLE_TV3,MURPHY_DRUGS_REL8,MURPHY_SEX_L2,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
From: Michel Lespinasse <walken@zoy.org>
To: submit@bugs.debian.org

Package: dhcp3-client
Version: 3.1.1-5
Tags: patch

While trying to figure out why it takes so long to up an interface using
dhcp, I had a look at the source code. It seemed to me that a lot of
the delays were unnecessary. After fixing what I saw, it now takes about
a quarter second to up an interface on my wired network - I thought I
should send the patches here, in case there is an interest.


dhcp3-client-1.diff fixes the delays between consecutive requests
(the backoff algorithm). This algorithm is best explained in the
following code comment:
        /* If we're supposed to increase the interval, do so.  If it's
           currently zero (i.e., we haven't sent any packets yet), set
           it to initial_interval; otherwise, add to it a random number
           between zero and two times itself.  On average, this means
           that it will double with every transmission. */
However contrary to what the comment indicates, client->interval has
been initialised, before the first request is sent, to the initial_interval
value rather than to 0. Because of that, the delay between the first two
requests is, on average, double of the initial_interval value, instead of
being equal to the initial_interval value. I'm proposing to change the
initialization value to zero, in order to match the programmers expectations
as documented in that comment, and to have the initial-interval option
in dhclient.conf work as per the documented behavior.

Additionally, I'm proposing to enforce that the delay between consecutive
requests is always at least one second - this was already the case when
using the default values, but could be messed with if setting an
initial-interval of 0 or a backoff-cutoff of 1. Some people
(see for example http://syn.theti.ca/ ) have been suggesting to use
a backoff-cutoff of 1, so such configurations do exist in the wild.


dhcp3-client-2.diff fixes a separate issue: the dhcp client was waiting
a random delay, between 0 and 4 seconds, before sending the first dhcp
request. The maximum delay was hardcoded and this behavior was not documented
anywhere, but my guess is that this may have been intended to reduce dhcp
floods when a large number of machines boot at the same time, following
a power failure for example. It seems to me however, that such a delay is
not necessary in many common situations, such as when running on a laptop
with its own battery... I don't feel bold enough to just remove that random
delay, but I think adding a new dhclient.conf option named
initial-random-delay, which would default to 4 but be user-settable to
any desired maximum random delay value, including 0 for no delay,
is a reasonable proposal. Laptop users could then be encouraged to use
initial-random-delay = 0.


The third delay I identified was in the dhclient-script. The packaged script
sleeps for one second after upping the interface with an ip address of 0
(this is, in the PREINIT stage before sending out the first dhcp request).
A comment there says this is because the kernel needs some time to get the
interface up. I believe this is not true of current kernels. In some
situations, I can imagine that link negotiation could take a little time
and cause packets to be lost during that interval, but this does not happen
for the most common situations of using ifplugd or wpa-supplicant roaming,
for example. Also even if it does happen in some wired situations, it seems
that the worst case would be that the first request would get dropped and
that a subsequent retransmit would work. So, I would propose to drop that
one second delay as well.


After implementing these proposed changes (as well as an additional change
in ifplugd, as documented in bug 509015) I can get a wired dhcp connection
within a quarter second of plugging in the ethernet cable. The only
configuration parameter I need to apply is initial-random-delay=0 - the
other parameters governing the backoff algorithm do not even have to be
modified. Without these changes the dhcp connection would take anywhere
from 2 to 7 seconds to negociate.

Hope this helps,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

diff -ru dhcp3-3.1.1.orig/client/dhclient.c dhcp3-3.1.1/client/dhclient.c
--- dhcp3-3.1.1.orig/client/dhclient.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/dhclient.c	2008-12-16 23:44:39.000000000 -0800
@@ -578,7 +579,7 @@
 	make_request (client, client -> active);
 	client -> destination = iaddr_broadcast;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Zap the medium list... */
 	client -> medium = (struct string_list *)0;
@@ -604,7 +605,7 @@
 	client -> destination = iaddr_broadcast;
 	client -> state = S_SELECTING;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Add an immediate timeout to cause the first DHCPDISCOVER packet
 	   to go out. */
@@ -676,7 +677,7 @@
 	client -> destination = iaddr_broadcast;
 	client -> state = S_REQUESTING;
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 
 	/* Make a DHCPREQUEST packet from the lease we picked. */
 	make_request (client, picked);
@@ -947,7 +948,7 @@
 		client -> destination = iaddr_broadcast;
 
 	client -> first_sending = cur_time;
-	client -> interval = client -> config -> initial_interval;
+	client -> interval = 0;
 	client -> state = S_RENEWING;
 
 	/* Send the first packet immediately. */
@@ -1487,6 +1488,10 @@
 			(client -> first_sending +
 			 client -> config -> timeout) - cur_time + 1;
 
+	/* Make sure the computed interval is at least one second. */
+	if (!client->interval)
+		client->interval = 1;
+
 	/* Record the number of seconds since we started sending. */
 	if (interval < 65536)
 		client -> packet.secs = htons (interval);
@@ -1714,6 +1719,10 @@
 		client -> interval =
 			client -> active -> expiry - cur_time + 1;
 
+	/* Make sure the computed interval is at least one second. */
+	if (!client->interval)
+		client->interval = 1;
+
 	/* If the lease T2 time has elapsed, or if we're not yet bound,
 	   broadcast the DHCPREQUEST rather than unicasting. */
 	if (client -> state == S_REQUESTING ||
@@ -2882,7 +2891,7 @@
 		} else
 			client -> destination = iaddr_broadcast;
 		client -> first_sending = cur_time;
-		client -> interval = client -> config -> initial_interval;
+		client -> interval = 0;
 	
 		/* Zap the medium list... */
 		client -> medium = (struct string_list *)0;

diff -ru dhcp3-3.1.1.orig/client/clparse.c dhcp3-3.1.1/client/clparse.c
--- dhcp3-3.1.1.orig/client/clparse.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/clparse.c	2008-12-16 23:21:38.000000000 -0800
@@ -78,6 +78,7 @@
 	top_level_config.reboot_timeout = 10;
 	top_level_config.retry_interval = 300;
 	top_level_config.backoff_cutoff = 15;
+	top_level_config.initial_random_delay = 4;
 	top_level_config.initial_interval = 3;
 	top_level_config.bootp_policy = P_ACCEPT;
 	top_level_config.script_name = path_dhclient_script;
@@ -477,6 +478,11 @@
 		parse_lease_time (cfile, &config -> backoff_cutoff);
 		return;
 
+	      case INITIAL_RANDOM_DELAY:
+		token = next_token (&val, (unsigned *)0, cfile);
+		parse_lease_time (cfile, &config -> initial_random_delay);
+		return;
+
 	      case INITIAL_INTERVAL:
 		token = next_token (&val, (unsigned *)0, cfile);
 		parse_lease_time (cfile, &config -> initial_interval);
diff -ru dhcp3-3.1.1.orig/client/dhclient.c dhcp3-3.1.1/client/dhclient.c
--- dhcp3-3.1.1.orig/client/dhclient.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/client/dhclient.c	2008-12-16 23:44:39.000000000 -0800
@@ -424,7 +424,8 @@
 				client -> state = S_INIT;
 				/* Set up a timeout to start the initialization
 				   process. */
-				add_timeout (cur_time + random () % 5,
+				add_timeout (cur_time + random () %
+					     (client->config->initial_random_delay+1),
 					     state_reboot, client, 0, 0);
 			}
 		}
@@ -3004,7 +3013,8 @@
 			client -> state = S_INIT;
 			/* Set up a timeout to start the initialization
 			   process. */
-			add_timeout (cur_time + random () % 5,
+			add_timeout (cur_time + random () %
+				     (client->config->initial_random_delay+1),
 				     state_reboot, client, 0, 0);
 		}
 	}
diff -ru dhcp3-3.1.1.orig/common/conflex.c dhcp3-3.1.1/common/conflex.c
--- dhcp3-3.1.1.orig/common/conflex.c	2008-12-16 22:06:57.000000000 -0800
+++ dhcp3-3.1.1/common/conflex.c	2008-12-16 23:20:19.000000000 -0800
@@ -804,6 +804,8 @@
 			return IS;
 		if (!strcasecmp (atom + 1, "gnore"))
 			return IGNORE;
+		if (!strcasecmp (atom + 1, "nitial-random-delay"))
+			return INITIAL_RANDOM_DELAY;
 		break;
 	      case 'k':
 		if (!strncasecmp (atom + 1, "nown", 4)) {
diff -ru dhcp3-3.1.1.orig/includes/dhcpd.h dhcp3-3.1.1/includes/dhcpd.h
--- dhcp3-3.1.1.orig/includes/dhcpd.h	2008-12-16 22:06:59.000000000 -0800
+++ dhcp3-3.1.1/includes/dhcpd.h	2008-12-16 23:18:05.000000000 -0800
@@ -839,6 +839,8 @@
 	TIME timeout;			/* Start to panic if we don't get a
 					   lease in this time period when
 					   SELECTING. */
+	TIME initial_random_delay;	/* Maximum random delay before sending
+					   first request. */
 	TIME initial_interval;		/* All exponential backoff intervals
 					   start here. */
 	TIME retry_interval;		/* If the protocol failed to produce
diff -ru dhcp3-3.1.1.orig/includes/dhctoken.h dhcp3-3.1.1/includes/dhctoken.h
--- dhcp3-3.1.1.orig/includes/dhctoken.h	2008-12-16 22:06:59.000000000 -0800
+++ dhcp3-3.1.1/includes/dhctoken.h	2008-12-16 23:19:25.000000000 -0800
@@ -325,7 +325,8 @@
 	MIN_BALANCE = 629,
 	DOMAIN_LIST = 630,
 	LEASEQUERY = 631,
-	EXECUTE = 632
+	EXECUTE = 632,
+	INITIAL_RANDOM_DELAY = 633
 };
 
 #define is_identifier(x)	((x) >= FIRST_TOKEN &&	\


----- End forwarded message -----




----- End forwarded message -----

Send a report that this bug log contains spam.