Re: Regarding offloading IPv6 addrconf and ndisc

[Hugo Santos <hsantos@av.it.pt>]

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]