What went wrong: SCTP

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.

16 comments:

  1. Note Firefox/Mozilla has some on-going activity to revive proper SCTP support, see https://bugzilla.mozilla.org/show_bug.cgi?id=486199
  2. I realize this is a blog that usually caters to vendor C stuff but Vendor J has SCTP stateful inspection in their ISG products.... :-)
  3. That's great news ... and an excellent topic for a follow-up post ;)
  4. That's great news ... and an excellent topic for a follow-up post ;)
  5. Well, it's more like the author of this blog has a severe case of the non-C-blindness. I'm very familiar with what vendor C does but not what vendors J,H,N ... have to offer. However, this is my personal blog and thus does not have to be exclusively C-focused. Let's widen the perspective ;)

    I'm most grateful for your additions, please keep them coming. A link to the relevant section of the product documentation would also be most appreciated.
  6. Stateful inspection in screenos 6.1.0, release notes http://www.juniper.net/techpubs/software/screenos/screenos6.1.0/rn_610_r2.pdf

    SCTP protocol filtering in screenos 6.3.0 (very new) and only on the "high end" platforms, release notes http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_rn_r1.pdf

    SCTP ALG (one command) page 54 in http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ipv4_cli.pdf

    Chapter 91 (high end platforms) how to filter it. Mostly geared towards telco packet core (signaling) protocols though.

    HTH :)
  7. That's great. Thanks 8-)
  8. Yes Yes deleightfull backyard theorists.

    As stated no working experience with it.

    Now that SIP 3/4 G, wifi and other technologies have evolved to take advantage of such a protocall which was knowledge at the time of writing i might add.

    You looked at the layers but failed to recognise why TCP and UDP techniques had been a key player.

    A look at wiki or protocall comparisons once again would have shown you the pro's and con's.

    But basicly we get tech chaff from such blogs wasting our time on google with such empty banter.

    IBM and MS proved more usefull thank you for wasting another portion of my life and bandwidth that i will never get back.

    (CENSORED)
  9. Greeting! Well I am new to protocols and all network stuff but I really like them and want to learn as many things as I can. My opinion is that SCTP must mature before they use it as best option. It is really a promising protocol. 4G networks fully support it. So I think it is like IPv4 and IPv6. There is no need to use only IPv6 when you can use IPv4 with an IPv6 prefix. It will get years to upgrade all world's servers, routers and applications IP versions from 4 to 6, they just let it be, and it is not efficient or profitable at all to change that. So that's the way they move around SCTP too. They will not change a thing allready in use, optimized by TCP let's say in today's standards, but they will emerge new things into old ones using this awesome protocol!
  10. You'll laugh when you read that WebRTC Datachannels uses SCTP over DTLS over UDP. :-)
  11. RFC 1925 section 2.6a ;)
  12. I've seen mention of a transparent TCP-to-SCTP shim that would allow unmodified applications to use SCTP.
    http://www.eecis.udel.edu/~amer/PEL/poc/pdf/EuroBSDCon2007-bickhart-SCTP-Shim-layer.pdf

    Variations of that ought to be possible for various OS's.
  13. I couldn't agree more with what you say about the broken socket API - please join the effort that's trying to fix that: https://sites.google.com/site/transportprotocolservices/
  14. About the shim by Ryan Bickhart et al, this gives you only the multihoming benefit transparently. You can do more transparently, cf. http://heim.ifi.uio.no/~michawe/research/publications/globecom2011.pdf , but for full benefit you really want to change the API, try using SCTP, and fall back to TCP using e.g. Happy Eyeballs: http://www.ipjforum.org/?p=378
  15. I think the time has come and move on to multihoming transport protocols. We would have multihomed access network these days and would definately would help. Could you imagine a laptop with wireless, ethernet and 4G/3G dongle will improve lot customer experience. Even that would be applicable to mobility where we are talking about different access roaming.
  16. We use it extensively in our network and it's too bad ACI doesn't support it yet.

Add comment
Sidebar