Live data from Hacker News

What went wrong: SCTP (2009)

blog.ipspace.net

1–10 of 48 posts

Re: What went wrong: SCTP (2009)

#5

So to summarise, nobody uses it because nobody uses it? I don't buy it. I think TCP is "good enough" for most cases, so people use it. SCTP is great, but TCP isn't broken. Worse is better and all that.

This writer seems to think the killer problem SCTP solves is end-system level IP multihoming. I think that's actually not a problem that many apps really have.

To me, the real promise of SCTP always seemed to be that it was a reliable out-of-order datagram protocol that played nicely with TCP. Essentially: that it killed the need for applications that can't deal with the slowness of in-order delivery in TCP to write their own protocols.

I think the big mistake with SCTP was in making it an IP protocol, rather than a protocol that lived underneath UDP.

Re: What went wrong: SCTP (2009)

#6
I'd like to also add to this that SCTP doesn't ship on Mac OS X either by default. Although, in recent years there have been development on an SCTP over UDP standard, allowing for user-mode SCTP. Yet, I still haven't seen a mature version of this API ship on Mac OS X.

Some time ago, I also did performance testing on SCTP vs. TCP. It's surprisingly sad how much worse SCTP's performance was compared to TCP. I imagine that this is because just isn't as much work put into SCTP as TCP.

Re: What went wrong: SCTP (2009)

#7
post #5

So to summarise, nobody uses it because nobody uses it? I don't buy it. I think TCP is "good enough" for most cases, so people use it. SCTP is great, but TCP isn't broken. Worse is better and all that.

This writer seems to think the killer problem SCTP solves is end-system level IP multihoming. I think that's actually not a problem that many apps really have. To me, the real promise of SCTP always seemed to be that it was a reliable out-of-order datagram protocol that played nicely with TCP. Essentially: that it killed the need for applications that can't deal with the slowness of in-order delivery in TCP to write…

It's a problem that apps have, but they just shift it onto the user.

Re: What went wrong: SCTP (2009)

#8
post #4

WebRTC DataChannels are actually built on SCTP.

Yeah I was going to mention this. I presume since no OSes natively support SCTP out of the box they just emulate it on top of UDP.

Interestingly, Emscripten emulates UDP by using SCTP's unreliable data packet mode with max retransmission set to zero. Relatedly, there is an excellent library for game networking called enet, which implements reliable and unreliable transmission. Enet is included in Emscripten.

So if you use Enet in emscripten you have: Enet, which uses UDP, which is emulated via SCTP, which is transported via UDP! It's pretty crazy but it actually works well.

Re: What went wrong: SCTP (2009)

#9
post #6

I'd like to also add to this that SCTP doesn't ship on Mac OS X either by default. Although, in recent years there have been development on an SCTP over UDP standard, allowing for user-mode SCTP. Yet, I still haven't seen a mature version of this API ship on Mac OS X. Some time ago, I also did performance testing on SCTP vs. TCP. It's surprisingly sad how much worse SCTP's performance was compared to TCP. I imagine t…

SCTP uses 32 bit checksums rather than 16. It may be the case that your hardware can do 16 bit checksums in hardware, but for SCTP it has to do the checksum in software. (I think it used to be the case and maybe still is that SCTP vs TCP benchmarks would disable hardware checksums so that the results weren't biased unfairly in favor of TCP.)

Re: What went wrong: SCTP (2009)

#10

So to summarise, nobody uses it because nobody uses it? I don't buy it. I think TCP is "good enough" for most cases, so people use it. SCTP is great, but TCP isn't broken. Worse is better and all that.

Well "nobody" is a bit misnomer. It's still widely used in telco networks, transporting control messages to/from your mobile device within the core network, and in interconnects between carriers.
Post reply on HN