Someone really wants to hear my opinion on SCTP (RFC 4960); he’s added a “what about SCTP” comment to several Internet-related posts I wrote in the last weeks. So, here are my totally unqualified (I have no hands-on experience) thoughts about SCTP.

Let me reiterate: I’m taking a 30,000-foot perspective here and whatever I’m writing could be completely wrong. If that’s the case, please point out my mistakes in your comments.

From the distance, the protocol looks promising. It provides datagram (unreliable messages), reliable message (record) and stream transport. Even more important, each connection can run across multiple IP addresses on each endpoint, providing native support for scalable IP multihoming (where each multihomed host resides in multiple PA address blocks from various Service Providers).

Second-hand evidence points to the viability of SCTP: it’s used in complex real-life signaling applications (SS7-over-IP), it’s implemented in Cisco IOS and IOS uses it for a variety of its transport needs (including high-availability solutions and reliable export of Netflow data).

However, SCTP will not solve the current IP multihoming issues (unless we’ll experience a world-wide Internet crash first). Here are just a few non-technical reasons why (if you have links to more in-depth information, please add them in the comments):

• It was designed by the wrong working group. SCTP was a byproduct of the SIGTRAN working group which was focused on transport of PSTN signaling over IP networks.
• It was never properly promoted. The SIGTRAN working group solved their problem and moved on.
• It’s not shipped with Windows, which is a major showstopper as most clients that would benefit from SCTP’s IP multihoming support run on Windows.
• Although it’s bundled in recent Linux kernels, the support files are not included in out-of-the box Linux distributions. To get it on my Fedora 11 distribution, I had to install lksctp-tools.
• You can get libraries, source code, kernel patches and even commercial implementations of SCTP for most operating systems, but in most cases you have to do some installation and integration work. This is a great option if you want to play with the protocol, but not if you want to deploy generic applications over it.
• Since it’s rarely used, there’s no support for it in the networking equipment. You can’t even match SCTP by name with extended access lists in Cisco IOS (you have to use its numeric protocol number). Obviously you cannot perform matches on SCTP port numbers. Passing SCTP across a firewall is a nightmare, as there’s no stateful inspection of SCTP traffic.

However, by far the biggest showstopper to SCTP adoption is the lack of session layer in TCP/IP and the broken Socket API. If you want to use SCTP with the Socket API, you have to indicate the protocol to use in the socket call, which means that every application that would benefit from SCTP support must be changed, recompiled and tested. There is no way that you could take existing applications, add SCTP support in the operating system and have a better-performing Internet as the result.