Re: Regarding offloading IPv6 addrconf and ndisc

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

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

Hi,

On Thu, Jul 27, 2006 at 07:27:43PM -0700, David Miller wrote:
> 
> Just like a TCP connection, packets cause state transitions.
> And it is reasonable to expect that after a state transition,
> the effects can be visible by subsequent packets.

   Certainly, control packets cause state transitions. TCP is a mixed
 bag. I think the question here is whether we can afford a stack where
 the data path is fully synchronous with the control path -- considering
 the amount of "time" required by a state transition (and other burdens
 you've identified). It might not pose a problem using the current
 signalling, but as an example, if we consider SEcure Neighbor Discovery
 (SEND, RFC 3971), validating a secure prefix to derive an address from,
 involves checking certificate signatures (besides the
 certificate-obtaining procedure); a process which may take some time.

   I believe it is reasonable to be synchronous within certain limits,
 specifically when the impact is local; for instance queueing outgoing
 packets during neighbor resolution (which is something some network
 stacks don't do actually). However when we consider something as global
 to the stack as configuring an address, being synchronous is expensive.

   I understand that any kind of impact should be well thought of, and
 adding new interfaces and behaviour to the kernel just adds to complex-
 ity and maintenance hell. But in this case, i think that adding a bit
 of additional complexity to the kernel would save us from a bunch of
 extra complexity in the long run associated with supporting these new
 protocols; besides helping the development.

   Hugo

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