[kea-dev] Design for Kea Host Reservation

Tomek Mrugalski tomasz at isc.org
Wed Oct 8 13:16:16 UTC 2014

On 08.10.2014 14:35, Marcin Siodelski wrote:
>>> I don't see a reason whye the reservation can't be out of the pool. So
>>> you're proposing that when I define a reservation, the configuration
>>> mechanism checks if this reservation happens to be in one of the pools
>>> defined for a subnet? And if it is, reject the reservation? How would I
>>> guarantee this for the HR configuration in the database? What about the
>>> cases that someone reconfigured the server as we were discussing above?
>> That's what I what thinking about. If the HR is defined in config, we
>> could sanity check it during config reload. If the HR is in the database
>> we could do two things. First, sanity check it during runtime when we
>> happen to read it from the DB. Second, we could implement a command,
>> something like host-reservation-check, that would go read all HRs and
>> sanity check them. We may implement such a command anyway, regardless of
>> what we decide for this particular case.
>> The primary reason why in my opinion reservation shouldn't be out of the
>> pool is performance. As I said before, if you allow in-pool
>> reservations, lease select will become slower.
> I see. Performance is a valid point here. I am afraid that without
> actual performance data we're not really able to assess what that impact
> would be.
> I think the in-pool reservations are in fact popular. For example, on my
> home router I have a pool of addresses to be handed out to my home
> devices. The router's administration panel lists the devices which were
> handed out an addresses and for each of them I have a "Reserve" button
> which makes a reservation of the address they are currently using. This
> is the in-pool reservation.
> On the other hand, my home router doesn't have to support thousands of
> leases per-second because I have a couple of devices at best. So the
> performance is not critical. But, what precludes Kea from being a DHCP
> server for small networks like my home network or any other networks
> where performance is not a key requirement? This is honest question.
> Although the additional check for existing HRs during the dynamic
> allocation will always cause performance penalty, I would like to
> discuss the usefulness of caching here which could help mitigating the
> problem of excessive queries to database. See this scenario:
> Client A has a reservation for address X. Client B doesn't have any
> reservations but will get an address from the dynamic pool. Client A
> requests an address first and will be allocated an address reserved for
> him. The HostMgr will have to make a query to the database to obtain
> reservations for client A. The caching layer stores this reservation in
> server's memory. Client B requests an address and allocation engine
> picks one from the pool. This address happens to be X. The server
> doesn't have to make additional query to the HR database because the
> reservation has been cached. Of course, lookup in memory for the
> reservation has performance implications. But, the performance
> assessment we made some time ago did not reveal that the server is CPU
> bound.
> Assuming that the Client B is the first one to send a request, the
> HostMgr will not have the reservation for Client A cached. Hence, the
> server would need to query the database for the reservation of the
> specific address. This would have a performance impact for the dynamic
> allocation for the Client B. But, the caching layer would store this
> reservation in memory and when Client A shows up, there is no need to
> query HR database because the entry has been already cached.
And what happens if there are no reservations at all? You can't cache
negative HR responses (well, technically you could, but it's a very bad
idea for other reasons). Assuming there are no reservations, every time
you attempt to pick a lease, you'd first need if it's free and then
check if it's reserved.

Depending on what your pool utilization and HR numbers are, this will in
the most optimistic case add one extra query and in pessimistic case
will double number of queries.

Adding one query may seem not much, but consider this. Our allocation
engine is tuned to handle lots of new clients efficiently. In typical
case, it requires just one query during lease selection phase. With HR
implemented, that +1 actually doubles the number of queries in
optimistic case. If we oversimplify and say that our performance is
related only to number of queries, we just halved our performance.

> Thankfully, I believe that we can make a final decision on this after
> doing some performance measurements as the change in the code to take
> into account HR reservations during dynamic allocation would be straight
> forward (both ways).
I agree that any speculations about actual performance impact are
useless. We need to implement this and then assess the damage by running
tests. Whoever implements this, will have to keep in memory that we may
change our mind later, so the code should be flexible enough to
accommodate the change.

> When I was reading your use case for monitoring and the trigger, I had a
> thought that the pool definition could come with an optional parameter
> which defines whether the pool has a relaxed or strict policy, i.e.
> whether host reservations are allowed or disallowed within this pool.
> The allocation engine gets the pool for the client and checks this
> property. If it finds that it is a relaxed pool it must use HostMgr to
> check for existing reservations which has all the bad sides you
> mentioned. If the pool has a strict policy the allocation engine doesn't
> have to worry about HRs and proceeds as usual. Now that the pool is
> defined as a map in the configuration file, adding this parameter would
> be trivial. Of course, for each pool following a strict policy the
> conflicts with HRs would need to be checked before configuration is
> committed.
I like that approach.

> Having an additional switch always require some more code and some more
> work. So, it doesn't have to be done from day one. Maybe we could use a
> strict approach first and then introduce a relaxed one as an extension.
> If we do opposite, someone using a relaxed approach (implemented first)
> would be unhappy seeing his configuration invalidate with a next release
> of Kea (assuming that the strict approach becomes a default). But, which
> one should be a default is another discussion.
Strict approach is also easier to do, because it doesn't require
allocation engine modifications. I think relaxed could be the default
once we have it implemented. It gives more flexibility and makes the
software easier to do. If you're after performance, it is natural that
you need to tweak some knobs.


More information about the kea-dev mailing list