SCTP, DCCP and MobileIP

[Robert Swindells]

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.

The code for SCTP, DCCP and MIP6 builds ok, I have sent and received
small messages using SCTP and DCCP over the loopback interface.

Not tried MIP6 yet as I'm still thinking about how to test it, maybe
simulate a couple of networks using Xen.

The main areas that needed work were socket locks and the use of the
route cache. The route lookups seem to work but I'm getting panics from
the socket code when the stack is cleaning things up.

I'm working on getting the MobileIP daemons to build but haven't included
the code for them.

The diffs and tarball of new files are at:

<ftp.NetBSD.org/misc/rjs/net.diff.bz2>
<ftp.NetBSD.org/misc/rjs/net.tar.bz2>

Comments and suggestions on when to think about putting it in the tree
would be good.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Robert Swindells
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.
The code for SCTP, DCCP and MIP6 builds ok, I have sent and received
small messages using SCTP and DCCP over the loopback interface.
Not tried MIP6 yet as I'm still thinking about how to test it, maybe
simulate a couple of networks using Xen.
The main areas that needed work were socket locks and the use of the
route cache. The route lookups seem to work but I'm getting panics from
the socket code when the stack is cleaning things up.
I'm working on getting the MobileIP daemons to build but haven't included
the code for them.
<ftp.NetBSD.org/misc/rjs/net.diff.bz2>
<ftp.NetBSD.org/misc/rjs/net.tar.bz2>
Comments and suggestions on when to think about putting it in the tree
would be good.

I looked, but did not find any... URL?

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by Christos Zoulas

Post by Robert Swindells
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.
The code for SCTP, DCCP and MIP6 builds ok, I have sent and received
small messages using SCTP and DCCP over the loopback interface.
Not tried MIP6 yet as I'm still thinking about how to test it, maybe
simulate a couple of networks using Xen.
The main areas that needed work were socket locks and the use of the
route cache. The route lookups seem to work but I'm getting panics from
the socket code when the stack is cleaning things up.
I'm working on getting the MobileIP daemons to build but haven't included
the code for them.
<ftp.NetBSD.org/misc/rjs/net.diff.bz2>
<ftp.NetBSD.org/misc/rjs/net.tar.bz2>
Comments and suggestions on when to think about putting it in the tree
would be good.

I looked, but did not find any... URL?

Paths should be:

<http://ftp.NetBSD.org/pub/NetBSD/misc/rjs/net.diff.bz2>
<http://ftp.NetBSD.org/pub/NetBSD/misc/rjs/net.tar.bz2>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Robert Swindells
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*

Post by Robert Swindells
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?

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.

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.

Dave

[Mouse]

Post by David Young

Post by Robert Swindells
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.

How does the real-world applicability of these protocols rate
compared with other urgent networking needs like an SMP network
stack?

Data point: I'm on a gig right now that's using SCTP on Linux. They
say they'd like to run on BSD as well, but that's pretty much a
nonstarter without SCTP.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by David Young

Post by Robert Swindells
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*

Post by Robert Swindells
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.

Post by David Young
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.

Post by David Young
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




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Mouse

Post by David Young

Post by Robert Swindells
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.

How does the real-world applicability of these protocols rate
compared with other urgent networking needs like an SMP network
stack?

Data point: I'm on a gig right now that's using SCTP on Linux. They
say they'd like to run on BSD as well, but that's pretty much a
nonstarter without SCTP.

Whether the KAME sctp code works well enough to be usefulis another
matter entirely.

The company I work for did pull the sctp code from the freebsd cvs
(I guess this was based on the KAME code) quite a few years ago
and then plumbed it into the windows kernel!
(For our kernel code to use).

It 'sort of' works, but I don't want to stress it and have to
find and fix the bugs.
We also stubbed out all the IPv6 support.

The code was being changed while we were porting it, and has changed
a lot since - and we haven't tried to copy forward any updates.

David

[Mouse]

Post by David Laight

Post by Mouse
Data point: I'm on a gig right now that's using SCTP on Linux. They
say they'd like to run on BSD as well, but that's pretty much a
nonstarter without SCTP.

Whether the KAME sctp code works well enough to be usefulis another
matter entirely.

True enough. I was considering implementing SCTP myself when I saw the
post about possibly bringing in the KAME code; I don't know whether
this gig would use Free or would use Net -current or would let the BSD
plans slide or what. (I might backport the SCTP code for my own use,
but that'd be a separate thing in any case - what I use and what this
work gig uses are pretty much orthogonal.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Mouse

Post by David Laight

Post by Mouse
Data point: I'm on a gig right now that's using SCTP on Linux. They
say they'd like to run on BSD as well, but that's pretty much a
nonstarter without SCTP.

Whether the KAME sctp code works well enough to be usefulis another
matter entirely.

True enough. I was considering implementing SCTP myself when I saw the
post about possibly bringing in the KAME code; I don't know whether
this gig would use Free or would use Net -current or would let the BSD
plans slide or what. (I might backport the SCTP code for my own use,
but that'd be a separate thing in any case - what I use and what this
work gig uses are pretty much orthogonal.)

Porting the code from freebsd to netbsd might be an option.
The freebsd versio probably has some of the worse bugs in the
original kame code fixed.

sctp isn't really that nice a protocol. It is over complex (so large
and slow) and doesn't really meet the original requirements of giving
a 'service level' similar to MTP2.
Although probably the most common use is m3ua - which actually
takes the mtp3 service interface (ie that to isup/sccp) over the IP
network.

You'd probably get better throughput by using multiple TCP connections
and relying on the application level retries to recover from packets
that are lost when a connection fails.

David

[Mouse]

sctp isn't really that nice a protocol. [...]

Yeah, I read the spec.

You'd probably get better throughput by using multiple TCP
connections and relying on the application level retries to recover
from packets that are lost when a connection fails.

...plus UDP for a few other things (unreliable packets and heartbeats
come to mind). You'd also have to rework the userland layers to impose
their own packetization on TCP, that being another thing SCTP offers.

That is certainly arguable, but it wouldn't then interoperate with the
existing SCTP-using code (currently running on Linux).

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Mouse

sctp isn't really that nice a protocol. [...]

Yeah, I read the spec.

You'd probably get better throughput by using multiple TCP
connections and relying on the application level retries to recover
from packets that are lost when a connection fails.

...plus UDP for a few other things (unreliable packets and heartbeats
come to mind). You'd also have to rework the userland layers to impose
their own packetization on TCP, that being another thing SCTP offers.
That is certainly arguable, but it wouldn't then interoperate with the
existing SCTP-using code (currently running on Linux).

I'm not sure which protocol you need to carry, but the standard sigtran
encoding (for about everythng except m2ua) contains a record length in
the userdata - so it runs fine over TCP provided you debatch the rx data.
The big advantage of TCP is that it is far easier to get multuple
user packets into a single ethernet frame.
That is almost impossible with sctp - especially if you disable Nagle.

The sctp protocol RFC does contain a whole load of stuff that isn't
directly related to the protocol.
All the stuff about handling multiple connections through a single socket
and simulating connectionless traffic is all local and hidden from the
remote system - it is all solving an orthogonal problem.

David

[Mouse]

Post by David Laight
The big advantage of TCP is that it is far easier to get multuple
user packets into a single ethernet frame. That is almost impossible
with sctp - especially if you disable Nagle.

That's a good reason to improve the SCTP API (as a simple example,
rather than having to do the analog of TCP_NODELAY, each send could
include a "hang on this, more is likely to come soon" flag). It's not
(IMO) a good reason to write off SCTP.

Post by David Laight
The sctp protocol RFC does contain a whole load of stuff that isn't
directly related to the protocol. All the stuff about handling
multiple connections through a single socket and simulating
connectionless traffic is all local and hidden from the remote system
- it is all solving an orthogonal problem.

Sure, but multiple connections over a single <addr1,port1,addr2,port2>
4-tuple is _not_ protocol-invisible. How it's presented in the API is
a separate issue (IMO out of scope for the IETF, not that the IETF
cares what I think).

Also, are we talking about the same protocol RFC? I just checked 4960,
and "socket" occurs only twice in it, neither of which describes
multiplexing multiple connections into a single socket. If you mean
6458, that's a different RFC - not the SCTP spec and not the RFC I was
talking about.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de