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
signature.asc
Description: Digital signature
