On lease expiration

[Stephen Morris]

On 22/07/14 18:58, Tomek Mrugalski wrote:
> On 22/07/14 10:37, Stephen Morris wrote:
>> On 08/07/14 21:36, Tomek Mrugalski wrote:

>> On reflection, this consideration impacts all solutions to the
>> lease expiration problem.  If we were to go for an external
>> process to do the house keeping, the DHCP server process could
>> not reuse expired leases - it would have to wait until they were
>> cleaned up by the housekeeper.
> So we're talking about race conditions here. I can imagine
> displeased users who discover that the server claims to be out of
> leases, while there are expired leases available.

It's not really a race condition, more that until expiration
processing has taken place, a lease can't be reused. It's not
necessarily a problem - if a server is such that it is operating with
relatively few free addresses available, the lease expiration
processing would have to take place more frequently. (Arguably the
frequency of processing could be adaptive - if a lot of expired leases
were processed in one pass, reduce the time until the next pass on the
grounds that leases are expiring quickly.)


>> Ultimately, the best method for lease expiration processing
>> depends whether we want to expand Kea beyond its single-thread
>> implementation to embrace parallel processing; and if we do, what
>> model we use.
> I my opinion there's no such thing as a the "best" method. It will 
> depend on the deployment scale. The "best" method will likely to
> be different if you're running your home office with 5 computers
> and when you run multi-million users network. That's why I think
> that the house-keeping routine (I call it routine and not process
> or function to not skew the perception in any way) independent, so
> it could be called both from the main process and also from a
> dedicated house-keeping process.

I agree that that lease expiration code should be as independent as
possible from the implementation, although we may want to think a bit
about processing to make it work optimally in all cases. (I'm thinking
here about "copy lease info from database, delete lease, do expiration
processing" as opposed to "copy lease info from database, do
expiration processing, delete lease": the effect is the same in a
single-threaded application, but in a multi-thread/process one, the
address can be reused by a new client while the expiration processing
for the previous client's lease takes place.)

As to scale, this is related to parallelism and whether the in-memory
or external lease database is used. I'd prefer as few mechanisms as
possible for initiating lease expiration processing, just to minimise
the code that needs to be maintained.

>> As Kea is now a standalone package, we have two choices for
>> parallelism:
>> 
>> 1. Make Kea multi-threaded.  This will work for all databases,
>> including memfile.
>> 
>> 2. Make Kea multi-process, disabling this capability for the
>> memfile database.
> 
>> If we do (1), then Tomasz's suggestion of handling lease
>> expiration in the same process as the lease allocation is
>> natural: it is just one more thread.
>> 
>> If we go for (2), I argue that the case against having the lease 
>> expiration in a separate process disappears. If we have multiple
> I don't think the choice between (1) and (2) is a management
> decision. The best action would be to implement prototypes and
> measure their performance. It will be more work in the short term,
> but will let us pick the right solution that will stick with us for
> many years.

I fear you might be right.  However, that won't be until after Kea 1.0.

Stephen