Hacker News Reader

Comment by tptacek | Hacker News Reader

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 first-class protocol.

View on HN

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.

For the record, IP source routing has its use cases. It's done via firewall or high-end router policy, and it's not a federated protocol. but it's handy.

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

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

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

Because if you're going to start building a protocol on UDP from scratch today, you can do much better than SCTP based on what concerns you're trying to solve. Pretty much every new UDP protocol pays at least lip service to the mobile use-case, and tries to get to zero roundtrip session establishment for majority of sessions ( and here the 4-way handshake of SCTP sticks out like a sore thumb).

But then there are some people who might be more interested in making a secure protocol from scratch (rejecting the layering complexity and third-party dependence of SSL). For instance: http://cr.yp.to/tcpip/minimalt-20130522.pdf

You are possibly right, although I suspect the kernel change issue is less of a problem than the second. Getting middleboxes to pass UDP unmolested....

You can at least configure virtually every middlebox to pass UDP. You cannot reliably do that for random ipprotos.

Reply on news.ycombinator.com