Changes between Version 4 and Version 5 of Receiver


Ignore:
Timestamp:
Aug 20, 2018, 7:52:02 PM (15 months ago)
Author:
vicky
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Receiver

    v4 v5  
    11= Receiver queue and thread =
    22
    3 == Background ==
    4 
    5 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.
    6 
    7 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.
    8 
    9 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.
    10 
    11 Note this mechanism is not about improving performance. It will help Kea behave better in overloaded scenarios.
    12 
    13 == Problem statement ==
    14 
    15 Copied from Trac #5611 ticket [https://kea.isc.org/ticket/5611]. As it is about design look at #5555 [https://kea.isc.org/ticket/5555] for tentative code.
    16 
    17 The current Kea implementation processes the inbound socket buffer as a simple queue - first in, first out. When the server is under pressure and not handling client packets as fast as they are arriving, a backlog will build up.
    18 
    19 If the situation continues for long enough, the client packets that the server is handling will have already timed-out on the client side, so it is pointless to spend time processing them and moreover wasting time on these old packets prevents the server from handling newer packets until they too have timed out. Effectively, it stops responding to active clients because it never gets through the backlog fast enough to reach the most recent inbounds.
    20 
    21 Even though the initial spike in traffic may have subsided, the degraded performance can mean that clients change their behaviour, adding retries to the backlog and/or reverting back to initial discovery - thus increasing the backlog of packets to be processed and making recovery unlikely without restarting the server to clear things down.
    22 
    23 We need to handle this situation better so that even when swamped, Kea servers are able to process a proportion of recently-received client packets, instead of none of them because it's 'stuck' with the oldest ones instead.
    24 
    25 Suggestions being mooted so far suggest either an independent socket reading thread (or process) to manage the inbound traffic and to pull it off the sockets/interfaces on which the Kea server is listening. This will prevent the UDP buffers from overflowing as well as allowing the socket reader to apply better logic to:
    26 
    27  * discarding the oldest client packets in favour of the most recently received
    28  * managing the 'waiting' buffers appropriately to the throughput capacity of the server
    29 
    30 Maximum per-server throughput will be highly dependent on both configuration and the choice of back-end (e.g database, or memfile, and if database, how and where etc..) - so it would be good to have the I/O handler be tunable too - not discarding too soon for a fast server and so on.
    31 
    32 There's no clear operational mitigation strategy for this, other than ensuring sufficient headroom when provisioning so that there are no peaks in client traffic that can overwhelm the server(s) maximum capacity.
    33 
    34 (Notably, increasing inbound UDP buffers is likely to make the situation worse rather than better.)
    35 
    36 = Proposed solutions =
    37 
    38  1 edit the ticket to explain why playing with ioctl SO_RECVBUF is not a good idea and why it won't work. `done`.
    39 
    40  2 move the interface socket scan from receive[46] to a thread, replacing it by watch socket scan.
    41 
    42  3 use a dedicated watch socket with a common message buffer to signal errors from the thread.
    43 
    44  4 manage a ring buffer filled by the new thread and 4o6 reader. New packets will be signaled using the watch socket. Consumer is receive[46] tail code.
    45 
    46  5 add a ring buffer with received packets protection by a lock on write (push by producers, pop by consumer).  Note that boost provides the class template for circular (aka ring) buffers.
    47 
    48  6 add a configuration parameter for the ring buffer size (a suitable default and size guideline is required).
    49 
    50  7 organize the receiver thread to scan interfaces receiving one packet per socket per loop (i.e. continue to the next socket instead to break at the first ready).
    51 
    52  8 add a (third) watch socket to signal to the thread when to terminate (typically in interface manager close all sockets).
    53 
    54  9 recode watch socket isReady to use FIONREAD in place of select (should be far faster and avoid imbricated select calls). Small ticket candidate.
    55 
    56  10 address the multiple packets by buffer in BPF. Small ticket candidate for a reduced version: return last instead first packet.
    57 
    58  11 discuss with QA (Quality Assurance) about statistics to maintain and of course performance impact.
     3Moved to gitlab. Please make updates here: https://gitlab.isc.org/isc-projects/kea/wikis/designs/receiver-queue-and-thread