[systemd-devel] [PATCH] libsystemd-network: Support setting DHCP client initial delay

[Tom Gundersen]

On Thu, Apr 3, 2014 at 9:28 AM, Patrik Flykt
<patrik.flykt at linux.intel.com> wrote:
> Section 4.4.1 in RFC 2131 says that a DHCP client SHOULD wait a
> random time between one and ten seconds to desynchronize DHCP
> clients on startup. This is supported such that the application
> can optionally set an initial delay of approximately two and eight
> seconds or leave the initial value unset relying only on any
> machine specific randomness chosen for the main loop.
>
> The maximum delay of slightly more than eight seconds was chosen
> as it's more convenient to compute in addition to following RFC
> 2131 in spirit with a sensible margin towards the 17 years passed
> since the exact wording of the document. The two second initial
> delay variant was added to include a more neutral timeout hopefully
> good enough on a very busy network.

As discussed on G+, there is no gain in setting the minimum above 0,
all we would care about is the range between min and max.

> By default no initial delay is
> added, as the implementation is geared towards maximum speed.
>
> Thanks to Ted Lemon and to Jayson Vantul pointing out the reasons
> having DHCP initial delay support.

Hm, so I'm definitely open to adding this sort of thing should it
prove to be a problem in some scenario (it is a SHOULD in the RFC
after all).

However, I'm wondering if this really can be an issue. If the initial
DISCOVER really does flood the network and the packets get dropped (or
the answer does not get back in time), then we will just resend the
DISCOVER message after a (randomized) hold-off, so the follow up
DISCOVER(s) will no longer be in sync across the network. Even if the
DHCP server takes some seconds to recover from the initial flood, we
will just keep sending DISCOVER's at increasing intervals (with
increasingly random delays), so even in the absolute worst case we
will recover within tens of seconds (and we really don't care how slow
this is in the worst case, as it should be extremely rare).

Or am I missing something here?

Cheers,

Tom