Current state of SCTP

SCTP is a transport level protocol which works on top of IP.

For a formal introduction see RFC4960 and RFC3286.

While SCTP origin is from telecom, it turns out SCTP is pretty useful for desktop applications too.

A bit of history.

SCTP was designed primary as a reliable transport in SIGTRAN architecture. SIGTRAN provides means to send SS7 traffic over IP, allowing connecting public service telecom network with IP based applications.

Why not TCP?

TCP is not a good solution for telecom signaling switches because it has number of downsides, for example one packet loss makes stall for the entire byte sequence. This is not good when one connection controls several phone calls and all of them are waiting for some packet to be retransmitted.

A few other key points of using SCTP I have collected here:

  • inside connection (“association” in SCTP), several streams can be set with separate sequences
  • association can have up to 65K streams, loss of packet for one stream does not stall other streams
  • unordered delivery possible
  • multihoming: endpoint has set of {IP4, IP6} addresses, protocol engine chooses where to retransmit the packet
  • retransmit limit on the time, counts or buffer size
  • message made with one send operation is parsed by protocol engine. It works different from TCP byte oriented stream, where application is responsible for framing.
  • protection for SYN denial of service attacks by having stateless handshake procedure on the server side
  • heartbeat is implemented by default, while in TCP it must be turned on explicitly

One concert could be about the performance of SCTP versus TCP.

As it can be found in ACE SCTP performance test, the SCTP is not significantly slower:

SCTP performance test

You may be curious why SCTP is not used in other applictions?

It might work much better than TCP for real time or other QoS sensitive traffic.

The answer is that at this moment SCTP is relatively young protocol.

The immaturity of implementations results in possible flaws enabling DoS attacks.

See CVE-2006-1527:

The SCTP-netfilter code in Linux kernel before 2.6.16.13 allows
remote attackers to trigger a denial of service (infinite loop) via
unknown vectors that cause an invalid SCTP chunk size to be processed
by the for_each_sctp_chunk function.

However, the future of SCTP is bright. According to this study using SCTP in massive multiplayer online game environments shows that SCTP someday may beat TCP and UDP on this field.

How to use SCTP?

We have two major open source implementations for Unix based sysems and a few less known open source implementations for
Windows.

Linux:

Windows:

The list of commercial implementations could be found here.

Using SCTP

There is a wonderful SCTP introduction paper by Randall Steward, Michael Tüxen and Peter Lei which explains the features of SCTP and provides simple example of using sockets API on Linux for server and client applications.

If your Linux kernel is built with SCTP, everything is straightforward.

Good news for those of us who likes higher level of abstraction.

As it is explained here ACE library also supports SCTP protocol in both Linux based flavours (LKSCTP and OpenSS7).

ACE also provides clean and functional example in the SCTP performance test code.

One Response to “Current state of SCTP”

  1. Bruce Cran says:

    The version of sctpDrv available via the co-conv site appears to have been unmaintained since the end of 2008. I took the code that was made available via sctp.jp and have been fixing bugs and making improvements such as adding 64-bit support and fixing installation issues. The new SctpDrv site is at http://www.bluestop.org/SctpDrv/ .

RSS feed for comments on this post. And trackBack URL.

Leave a Reply