Hi Jamal, Through this discussion i've identified three points: one is that some believe control and data should be kept synchronized; the other is how some (including all of the first :-) think control should remain inside the kernel; and finally you and me so far who believe they should be separated for increased flexibility. If we consider the first point, i would too have difficulties accepting the second one, taking the same considerations Stephen mentioned, where an application could possibly bork the kernel. So, first of all, we need to settle whether data really needs to be in-sync with control (already assuming the complexity control is gaining).
Personally i think the answer is clear; the overall throughput
depends on the amount of time spent in a single state. Thus, the data
path should be well contained and depend only on the current state;
while control executes in parallel as it's state transitions are much
longer and might depend on multiple sub-transitions (communicating with
peers, etc).
Deciding whether control should remain inside the kernel or not is
another story; as you point out, people generically don't like to
depend on daemons. I understand this point, and i think a solution that
would keep both parties happy would be to have the current
functionality inside the kernel while at the same time allowing control
daemons to take over and support additional complex features.
I would say that the generic worries such as 'how do we handle out of
memory', or 'what if it crashes' or even 'what if it is overloaded'
apply both to the kernel and to a possible user-space application.
- As this control daemon is important for the proper interaction of
the host with the network, we would reduce it's chances of being
OOM killed (while at the same time implementing algorithms to
prevent DoS by state flooding);
- Regarding the crashes, i think it is better for a system to have an
application rather than a kernel component crash as it might be
seamlessly restarted to recover. I would also say that the complex-
ity of the code is the same (or worst if in the kernel) to support
exactly the same features;
- The overloading problem also applies to the kernel, and would be
something that must be considered by either implementation;
Don't forget that having this functionality in a daemon would also
allow for easier updates (including updates without having to reboot
your machine) besides offering a greater degree of flexibility.
Let me also point out to any IKE daemon, where the SA/SP database is
kept in kernel, but is provided for by the daemon using explicit
requests by the kernel (ACQUIREs). If we consider neighbor discovery
for instance, if configured to do so, and as an example, instead of
sending an IPv6 NS, the kernel could netlink broadcast (or unicast to a
specific controller) the request due to an entry being STALEd and being
required where the daemon would then update the entry to REACHABLE.
I'm sure some of you will continue to disagree, but i would really
like to move this decision to the user (or system deployer).
Hugo
signature.asc
Description: Digital signature
