[kea-dev] receiver queue and thread

Tomek Mrugalski tomasz at isc.org
Thu Jul 5 13:58:31 UTC 2018

Here's a bit more background to this proposal.

Kea processes packets sequentially in plain FIFO order. This works great 
until there is more traffic that Kea can handle. In such case Kea 
continues working through the backlog of packets, even though some of 
them are old and clients may possibly gave up waiting.

What's even worse, Kea will continue processing oldest packets first, 
which may trigger an avalanche effect. Kea responds to the oldest 
packets first that clients already given up waiting for and retransmit 
which puts more packets in the queue.

There is a mechanism in the DHCP protocol to mitigate the problem to 
some degree (the retransmissions are supposed to have the same 
transaction-id, so client should match the response to oldest 
transmission with its newest retransmission), but it only mitigates the 
problem a bit. Imagine a case where client transmitted a packet, didn't 
get a response in time, so retransmitted. Now Kea eventually processes 
the original packet and sends back a response. The client got its 
configuration and it's happy. However, Kea now has the retransmission 
packet still waiting for processing. Kea will spend cycles on it and 
will eventually produce a response nobody is waiting for anymore.

Note this mechanism is not about improving performance. It will help Kea 
behave better in overloaded scenarios.

Thanks for writing this proposal, Francis!


More information about the kea-dev mailing list