SCTP with Multihoming as a Drop In Replacement for TCP

Question

SCTP has native multi-homing support which if I understand it correctly will automatically reroute your packets over a secondary NIC if the primary interface goes down. I duplicated this functionality with TCP by writing a custom routing deamon to modify the routing tables if my primary NIC goes down. I would like to try using SCTP instead.

In Steven's Unix Network Programming V1 3rd Edition on page 288 it says:

For this example, we use a one-to-many-style server. We make this choice for one important reason. The examples in Chapter 5 can be modified to run over SCTP with one minor change: modify the socket function call to specify IPPROTO_SCTP instead of IPPROTO_TCP as the third argument. Simply making this change, however, would not take advantage of any of the additional features provided by SCTP except multi-homing.

Now I've tried this with fairly poor results.

I'm running on Ubuntu 9.04 with the libsctp1, libsctp-dev, and lksctp-tools packages installed. I've verified with lksctp-tools that SCTP is working properly.

I took the UNP example code and modified as indicated above the ~/unpv13e/tcpcliserv/tcpserv04.c and ~/unpv13e/select/tcpcli02.c programs.

This is a simple echo server / client pair. The server runs apparently listening, but the client exits saying the connection was refused. Since netstat doesn't support SCTP I used lsof -n | grep tcpserv which showed me:

tcpserv04 6208      alice    3u     sock        0,4            33889 can't identify protocol

This doesn't seem to tell me much other than tcpserv04 has some kind of socket open.

I had already rewrote and tested the original TCP client in perl, so I switched it to sctp and was able to connect although piping a file on stdin didn't completely work ( hung about 2/3's of the way through receiving the echo's back ).

It seems like UNP is implying that porting TCP applications to SCTP to take advantage of multi-homing is trivial, yet based this simple attempt that doesn't really seem to be the case.

Can anyone point me to a good tutorial or give good advice on any gotcha's to watch out for when porting TCP apps to one-to-one-style SCTP to take advantage of multi-homing?

Dying

TCP can implement this form of redundancy as well ---- multiple routes from a to b in the routing table -- why bother ? – Kure

@Hassan Syed: Because I'm curious. – Dying

have you tried capturing wireshark. If everything is setup correctly, a connect call on the client should trigger the 4-way handshake towards the server. Besides, I could not find the client file (~/unpv13e/select/tcpcli02.c) from the link you provided. – Madder

@Hassan: Because SCTP multihoming does not break the connection when one of the interfaces goes down. In theory, it would be possible to to ssh over sctp from your laptop on wired ethernet with wifi running also, then undock it and keep the same connection over the wifi interface only. – Madel

@HassanSyed, the business case was originally for running SS7 over IP. Since the phone company traditionally has tremendous uptime, they want to be able to service base stations and switches with hotswap hardware, and not have to break connections. – Reinforcement

Answer 1

tcpcli02 tries to connect to port 7, while tcpserv04 listens on port 9877 (the default value for SERV_PORT). After changing those to match, it works for me.

Support for SCTP generally is very bad. Unless you control the entire network infrastructure between the hosts you are trying to connect, I would not count on it to work reliably. Porting the applications itself should be fairly hassle-free, as mentioned in UNP.

Encephalic

I would think that I'd only need to control the two endpoints that are talking to each other. Why would I need control of the "entire network infrastructure"? Ahh, I guess all the routers in the network would need to have explicit support for SCTP and most currently don't? – Dying

Indeed. In theory, routers should not be a problem, since they do not inspect into layer 4. Routers in the core of the internet probably won't. However, the closer you get to the edge, the more likely it is. Once you get to boxes doing NAPT (which relies on mapping packets to endpoints using layer 4 headers), you're probably out of luck, as they'll most certainly only deal with TCP and UDP. – Encephalic

IPv6 is the answer. – Playwright