Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. same subnet design (Francis Dupont)
2. receiver queue and thread (Francis Dupont)
3. Re: receiver queue and thread (Tomek Mrugalski)
4. Re: receiver queue and thread (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 05 Jul 2018 12:04:37 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] same subnet design
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
We are improving the way a subnet configured twice is detected.
A design document is available for information and comments at:
https://kea.isc.org/wiki/SameSubnet
To summary we should propose two modes:
- strict checks which should detect current configuration mistake.
It will be the default mode.
- relexed mode where only duplicated subnet IDs give an error.
It will be optional and require subnet IDs.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Thu, 05 Jul 2018 13:30:10 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] receiver queue and thread
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
This is a proposal for a receiver queue (in fact a small ring/circular
packet buffer) and thread (to fill the ring, current existing functions
will take packets from the ring instead of directly from service sockets).
Available for information and comments at: https://kea.isc.org/wiki/Receiver
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 5 Jul 2018 15:58:31 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] receiver queue and thread
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 4
Date: Thu, 05 Jul 2018 14:38:31 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] receiver queue and thread
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> Note this mechanism is not about improving performance. It will help Kea
> behave better in overloaded scenarios.
=> as some work is done in a thread it should have impact on performance.
If you are optimistic you can believe in a small improvement.
If you are not it can be like ISC DHCP: terrible performance when
bind9 libraries are built with multi threading...
Regards
Francis Dupont <[email protected]>
PS: I'll include the background in the design.
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 52, Issue 2
**************************************
