[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!
Tomek
More information about the kea-dev
mailing list