Hacker News Reader

Comment by Zash | Hacker News Reader

Whatever happened with SCTP?

Used everyday in 3G/LTE networks to setup the data paths through the network.

The only thing I've ever seen in it was a modification of FTP to use SCTP streams on a single connection rather than have two connections. This would of course make the whole active-FTP-over-NAT business easier, except for the fact that the average NAT device ($50 home router) probably doesn't play nicely with SCTP.

Given the subject matter, I should probably include my usual disclaimer string: I work as a software engineer for F5 Networks. Anything I post here is my own thought and is not intended to represent F5.

When you use a mobile phone, chances are big most of the control plane traffic (call setup, SMS, data channel setup/teardown, roaming signalling, phone registring and so on) travel through an SCTP association somewhere.

It's a shame. Erlang supports it nicely, too. But like koenigdavidmj, I understand lots of cheap home routers don't like it. If you want a protocol that consumers can use without worry, sadly it seems to me that you better base it on TCP or UDP under the covers. Which multipath TCP does, according to https://lwn.net/Articles/544399/

FOr that reason, WebRTC Data channels use SCTP but encapsulated in UDP. It is implemented in user space inside the browser (probably not what you'd want but at least encourages deployment).

[ref] http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol

I vouch for it being used in a very high-profile, highly concurrent online service with great results.

In this particular case we owned both the client and server-side networking libraries - but all-in-all it worked quite well and helped us deal with NAT traversal issues among other things.

I've never seen it mentioned outside the Stevens book and that it was supported in java 7

In short: hard to deploy because of middleboxes dropping all non-TCP/UDP traffic..

It's pretty slow and relegated to telcos and people who need HA multihoming.

Is this slowness intrinsic to SCTP, or a matter of implementation?

It's always a matter of implementation.

SCTP is the solution to the problem that Multipath TCP is trying to solve. The biggest challenge is the penetration of TCP libraries vs. SCTP libraries.

...and that SCTP has higher overhead/complexity. But 'slowness' is an imprecise term.

Some applications will perform much faster over TCP because the link is short, reliable, and the application only needs to stream data in-line. Heck, even with network loss you can see gains in TCP vs SCTP.

Some applications will be faster with SCTP because of either the nature of how the application handles network data, or the properties of the network they're traveling over. But speed was never a design consideration of SCTP.

If you want speed, use UDP. If you want something that's fast and "just works", use TCP, or this multipath TCP thing. If you want something designed to pass multiple independent unidirectional data messages across a single "connection" that can span multiple network paths and never miss a beat, use SCTP.

Wasn't sure if there was something particular about SCTP that could induce algorithmic latency such as a buffering requirement, setup/negotiation, congestion control, other overhead, etc.

It uses CRC32 as a checksum and that cannot be offloaded to most commercial NICs. This will also have an impact on routers that manipulate the transport layer ports due to checksum recalculation cost (which is trivial for the checksum used in UDP and TCP)

Routers almost NEVER manipulate the transport unless they are doing something very un-Layer3 like NAT or some other encapsulation.

Reply on news.ycombinator.com