What went wrong: SCTP (2009) • Hacker News Board

Re: What went wrong: SCTP (2009)

#31

Post by acdha » Thu, Jul 02, 2015, 7:41 PM UTC

ftigeot wrote: post #30

acdha wrote: post #27

Earlier quoted context omitted.

The big problem is that that promotion really needs to be aimed at a highly specific community: operating system and network equipment vendors. The original article was written 6 years ago and wasn't a novel position at the time. It's hard to say anything's changed since then because app developers are still blocked waiting on mainstream middle-box support and I don't see that really happening without some sort of pr…

Relevant Operating System community news here: https://news.ycombinator.com/item?id=9797932 SCTP support has just been removed from DragonFly. The code had been present for 15 years (inherited from FreeBSD) and in these 15 years there wasn't even a single known user. If there really are people using it it's effectively in a very very small niche and they will have to do everything themselves. There is no way generic…

The only way I see this cycle changing is if someone ships a real application which uses SCTP to provide significant benefits to users. If deploying SCTP improved performance or reliability for video-chat, a popular game, etc. there'd be a more compelling reason to go to e.g. Cisco, NetGear, etc. and ask them to ship kernel-level code with likely security impact to everything they sell.

WebRTC is the most obvious candidate for this but maybe one of the HTTP2-over-SCTP experiments will go well enough that someone will ship it in a real browser and start the process of saying “Web users get n% performance improvements if SCTP is implemented”. That certainly seems like a rather long game to play, however.

Re: What went wrong: SCTP (2009)

#32

Post by dang » Thu, Jul 02, 2015, 8:31 PM UTC

tinco wrote: post #20

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

> This is an edited version of mcguire's comment that was needlessly inflammatory

We appreciate your desire to make HN threads less inflammatory, but posting edited versions of others' comments under your account isn't a good way to do that.

Re: What went wrong: SCTP (2009)

#33

Post by teacup50 » Thu, Jul 02, 2015, 8:59 PM UTC

tptacek wrote: post #29

mcguire wrote: post #17

" 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 i…

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

You might be able to credibly defend it, but it's still depressingly silly that we're cut off from a large swath of our extensible-by-design protocol stack.

These days, people justify HTTP for everything with the argument that opening up a TCP socket is not guaranteed to work as reliably as HTTP-over-TCP.

They might be right, but god that sucks.

Re: What went wrong: SCTP (2009)

#34

Post by wtallis » Thu, Jul 02, 2015, 9:14 PM UTC

tptacek wrote: post #29

mcguire wrote: post #17

" 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 i…

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

They got ECN capability, which would have required OS changes even if it was built atop UDP.

Re: What went wrong: SCTP (2009)

#35

Post by tptacek » Thu, Jul 02, 2015, 9:15 PM UTC

teacup50 wrote: post #33

tptacek wrote: post #29

Earlier quoted context omitted.

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

You might be able to credibly defend it, but it's still depressingly silly that we're cut off from a large swath of our extensible-by-design protocol stack. These days, people justify HTTP for everything with the argument that opening up a TCP socket is not guaranteed to work as reliably as HTTP-over-TCP. They might be right, but god that sucks.

I see arguments like this as a form of the naturalist fallacy. Not every aspect of the original TCP/IP design is worth preserving and exploiting. We don't need an URG pointer. We don't need IP source routing (really, we don't need the IP options we have now). We don't need a "length" field in UDP. &c.

TCP should have been built on top of UDP, as should ICMP. The IP "protocol" field doesn't do us much good. I don't think we should fret too much about not exploiting it.

Re: What went wrong: SCTP (2009)

#36

Post by karmakaze » Thu, Jul 02, 2015, 9:26 PM UTC

SCTP is in Sun/Oracle Java SE 7. Examples show the multi stream aspect. Can't speak for multi-homing. Of course Java is only popular on one end of potential connections.

Re: What went wrong: SCTP (2009)

#37

Post by danellis » Thu, Jul 02, 2015, 9:58 PM UTC

tptacek wrote: post #29

mcguire wrote: post #17

" 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 i…

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

There's a spec for SCTP over UDP and libraries that implement it, so what's stopping anybody now?

Re: What went wrong: SCTP (2009)

#38

Post by pfraze » Thu, Jul 02, 2015, 10:19 PM UTC

danellis wrote: post #37

tptacek wrote: post #29

Earlier quoted context omitted.

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

There's a spec for SCTP over UDP and libraries that implement it, so what's stopping anybody now?

In fact, WebRTC's datachannel uses it

Re: What went wrong: SCTP (2009)

#39

Post by tptacek » Thu, Jul 02, 2015, 10:27 PM UTC

danellis wrote: post #37

tptacek wrote: post #29

Earlier quoted context omitted.

I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…

There's a spec for SCTP over UDP and libraries that implement it, so what's stopping anybody now?

Nothing, but there hasn't always been that spec, and SCTP over UDP is not what people usually mean when they refer to SCTP.

Re: What went wrong: SCTP (2009)

#40

Post by tinco » Thu, Jul 02, 2015, 10:53 PM UTC

dang wrote: post #32

tinco wrote: post #20

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

> This is an edited version of mcguire's comment that was needlessly inflammatory We appreciate your desire to make HN threads less inflammatory, but posting edited versions of others' comments under your account isn't a good way to do that.

Thanks, I guess I was a bit inflamed myself :)