Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What went wrong: SCTP (2009)

blog.ipspace.net

Post reply on HN
Print view View original

11–20 of 48 posts

Re: What went wrong: SCTP (2009)

#11

Post by detaro »

ketralnis wrote: post #2

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.

Aren't you basically saying the same thing? TCP was good enough for most cases, so nobody uses it. And anybody who wants to use it can't, because it isn't widely enough supported to be reliable over the public internet. And it isn't widely supported because nobody uses it.

MCTCP (which probably is most famous right now for being used by Apple for Siri) is a cool but complex hack on top of TCP to provide multi-homing without confusing middle-boxes. HTTP2/SPDY/QUIC have their own mechanisms to get multiple streams in one connection over TCP/UDP.

Re: What went wrong: SCTP (2009)

#12

Post by throwaway2048 »

elihu wrote: post #9
sargun wrote: 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.)

even at gigabit speeds, unless the implementation is really, really bad, checksumming will absolutely not be the issue here as far as my experience goes.

Benchmarks should be consulted before preformance issues are debated.

Re: What went wrong: SCTP (2009)

#13

Post by tptacek »

teacup50 wrote: post #7
tptacek wrote: post #5

Earlier quoted context omitted.

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.

That's a bit hard for me to fathom, because the overwhelming vast majority of users don't have multiple Internet connections, and serverside applications can make use of multiple Internet connections without protocol-level multihoming.

Re: What went wrong: SCTP (2009)

#15

Post by rdtsc »

SCTP should have been promoted and is actually pretty nice on paper. Every time I see someone re-implement multi-plexing and datagram/message parsing out of a TCP stream I think of SCTP. Every time I see custom 'reliable delivery on top of UDP' I think of SCTP. We might not have had QUIC or HTTP/2 in the current form if SCTP was ubiquitous.

Re: What went wrong: SCTP (2009)

#16

Post by pktgen »

elihu wrote: post #9
sargun wrote: 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.)

Some Intel NICs (at least the 10G ones, but some Googling suggests some 1G as well) support SCTP checksum offload. Also, the checksum is a CRC32C and the SSE4.2 CRC32 instruction can calculate these really fast.

Re: What went wrong: SCTP (2009)

#17

Post by mcguire »

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

Ah. "Ivan Pepelnjak, CCIE#1354 Emeritus, is an independent network architect." Ivan Pepelnjak also doesn't seem to understand network protocols. SCTP was never intended to be a TCP replacement or a basis for TCP or whatever the hell he thinks it to be. It is a separate protocol which is designed to provide a different set of features to a different set of applications.

I'm sorry that he and the large number of people like him, who would like to have exactly their use-case covered by exactly the simplest possible interface, preferably baked into the kernel or even better, the hardware, for the best performance. It's not going to happen.

I'm also sorry I have to live in a world where networking === TCP, over port 80 or 443. It wasn't supposed to be this way.

What went wrong with SCTP? By the time TCP-friendly congestion control research had reached a critical mass and started producing results, everyone had given up, adopted TCP as the sole transport protocol, and the deck was strongly stacked against anything that wasn't running on TCP.

Re: What went wrong: SCTP (2009)

#18

Post by signa11 »

tptacek wrote: post #13
teacup50 wrote: post #7

Earlier quoted context omitted.

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

That's a bit hard for me to fathom, because the overwhelming vast majority of users don't have multiple Internet connections, and serverside applications can make use of multiple Internet connections without protocol-level multihoming.

> because the overwhelming vast majority of users don't have multiple Internet connections

your shiny iphone/andriod etc. are all multihomed...

Re: What went wrong: SCTP (2009)

#20

Post by tinco »

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

SCTP was never intended to be a TCP replacement or a basis for TCP or whatever Ivan Pepelnjak thinks it to be. It is a separate protocol which is designed to provide a different set of features to a different set of applications.

He and the large number of people, would like to have exactly their use-case covered by exactly the simplest possible interface, preferably baked into the kernel or even better, the hardware, for the best performance. I don't think it's going to happen.

I'm sorry I have to live in a world where networking === TCP, over port 80 or 443. It wasn't supposed to be this way.

What went wrong with SCTP? By the time TCP-friendly congestion control research had reached a critical mass and started producing results, everyone had given up, adopted TCP as the sole transport protocol, and the deck was strongly stacked against anything that wasn't running on TCP.

(This is an edited version of mcguire's comment that was needlessly inflammatory, hopefully we can have a more sensible discussion about it this way)

Post reply on HN