content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 2740

Dear sir/madam,

A couple of years ago I enquired about whether any users had had any
poor experiences with using delayed-ack alongside failover [i]. The
answers that were forthcoming where that delayed-ack seems to work
fine which matches my own positive experiences. Perhaps ISC knows
different?

This lead to me raising a proposal for the delayed-ack feature to be
compiled in by default [ii]. The following is a refresh of that
proposal.

Please could you review and if suitable pull the following:

https://github.com/terryburton/isc-dhcp/commit/b712dc011e1ce67a3aa78db7f9a52733f9cf1a29

As a patch (also attached):

https://github.com/terryburton/isc-dhcp/commit/b712dc011e1ce67a3aa78db7f9a52733f9cf1a29.diff

Summary below...


[i] https://lists.isc.org/pipermail/dhcp-users/2014-November/018386.html
[ii] https://lists.isc.org/pipermail/dhcp-hackers/2014-December/002102.html


Many thanks,

Terry

----

ISC recommends the use of delayed-ack [1] yet this feature is still described
as experimental and is omitted from the build by default.

Myself and others [2] have had success with this feature in high-throughput
failover configurations and would like to see --enable-delayed-ack default to
yes.

This patch enables delayed-ack in the default build.

To mitigate any potentially harmful effects in untested configurations the
default "delayed-ack" runtime configuration parameter has been amended to
default to 0, rather than 28. The condition that decides between delayed- vs.
immediate-ack has been amended so that it will immediately ack if the
delayed-ack parameter has not been updated from the default of 0. This means
that users are not accidentally exposed to the "experimental" code path, only
if they add a delayed-ack parameter other than 0 to dhcpd.conf.

Pros:

* Delayed-ack support will be available without recompiling and will therefore
  find its way into distributions.
* This will increase the amount of testing that this feature receives due to
  increased exposure - hopefully getting it out of experimental status sooner.
* ISC DHCP then benefits from hugely increased performance without having to
  declare caveats.

Cons:

* Minor upgrade risk for users already compiling in delayed-ack support without
  specifying an explicit "delayed-ack" parameter in dhcpd.conf. Those who rely
  on the current default (28) will find it changed (0) thereby disabling the
  feature at runtime. Setting delayed-ack to 28 in dhcpd.conf will re-enable
  the previous behaviour. Perhaps a release note is sufficient to cover this?

[1] https://deepthought.isc.org/article/AA-00373/0/Synchronous-Disk-Writes-and-DHCP-Performance-Limitations.html
[2] https://lists.isc.org/pipermail/dhcp-users/2014-November/018387.html