Re: SCTP, DCCP and MobileIP

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

David Young wrote:
>On Thu, Feb 27, 2014 at 03:45:47PM +0000, Robert Swindells wrote:
>> I have been doing some work on taking the remaining network protocols
>> that were developed by the Kame Project and trying to get them to work
>> on NetBSD-current.
>*snip snip*
>> Comments and suggestions on when to think about putting it in the tree
>> would be good.

>I have a few concerns about adding this to the kernel.

>Code previously brought into NetBSD from KAME, or proposed to be brought
>in, has been poorly encapsulated.  Functions whose code could/should
>have been isolated to a few new .c/.h files instead erupted in #ifdefs
>all over the IPv4/IPv6 sources.  This makes the networking code a real
>bear to work with.  Is this an eruption or not?

I don't feel that these protocols are poorly encapsulated, the diffs
to existing files in the tree are fairly small.

>What does configuring this stuff with route(8)/ifconfig(8) look like?
>It should be easy to create an actual typescript and annotate it, or
>else to simulate a typescript.  I find that a typescript can reveal the
>flaws in some software quickly compared with poring over patches.

No configuration is needed to use SCTP or DCCP.

There are two extra options to ifconfig(8) to support MobileIP. The
extra daemons for it have configuration files too, there is a description
of how to use them here:

<http://www.kame.net/newsletter/20031007/index.html>

There are also some changes to rtadvd(8) in Kame that I had missed which
modify timeouts.

Choices could be made on which use cases of MobileIP to support initially:

  NetBSD as mobile client.
  NetBSD on home router.
  NetBSD on mobile router using nemo extension.

>How does the real-world applicability of these protocols rate compared
>with other urgent networking needs like an SMP network stack?  I'm wary
>of adding features for the sake of checking boxes in a features matrix
>when I perceive a lot of architectural deficiencies.

Firefox can use SCTP, GStreamer can use DCCP.

The suggested plan in the wiki for doing a SMP network stack doesn't
propose changing all protocols at once, I don't see how adding more
components that are protected by the kernel lock affects it.

I have left the locking macros in the SCTP source that are used on
FreeBSD, they evaluate to empty at present on NetBSD but could easily
be changed to use kmutexes.

Robert Swindells