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).
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.
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)
