Comment by imglorp
4 months ago
Sort of related, I'm curious why SCTP did not take off more in this space? It might have had more telecom origins maybe but seemed to fill some of the same needs back in the day.
https://docs.kernel.org/networking/sctp.html
PS the kernel work goes back to 2003!
Windows doesn't have kernel mode SCTP so it was slow for most consumer devices for a long time. Even now, Linux SCTP is slow in comparison to other protocols. Plus, it's complicated enough already to get UDP and TCP traffic to make it's way through middleboxes. Also, not a lot of consumer routers support things like port forwards and combining SCTP with NAT doesn't seem to be widely tested. Things just didn't work out when SCTP stood to gain adoption.
It's an interesting protocol, but these days I think the internet has ossified so far that you're probably better off relying on hacks like QUIC and MPTCP to get the protocol features that SCTP stood to introduce.
I believe it's because of firewalls. You need to be either UDP or TCP to work in the Internet at large.
Though SCTP did find its place as a layer in WebRTC.
Coming from the telecoms space, I was slightly amazed to see how little well known SCTP actually is in the networking world.
My old company/offices had site internet provided by one of the top 50 UK Managed Service Providers. They swapped out the on-site router not many years ago as the fibre to site was being upgraded from 100mbit to gigabit and so a new Juniper firewall with GBE ports was required.
Turns out the newer, faster, shinier, though albeit lower model numbered'd Juniper SRX fundamentally didn't support passing SCTP data and suddenly we lost access to all our remote stuff that used it. Ended up on a call with the MSPs Head of Networks (who was not a stupid person), but their opening gambit was "Are you sure you mean SCTP? Oh. What is that then?"
There was also numerous weird kernel bugs with implementations on CentOS 5, 6 and 7 which all would manage to get themselves into weird states where only a reboot would clear - not really what you want from a multi-endpoint, 'copes and recovers well from network weirdness' tunnelling protocol.
> Juniper SRX fundamentally didn't support passing SCTP data and suddenly we lost access to all our remote stuff that used it.
did you file a customer complaint for the device you bought not supporting basic internet protocols? If I look here it mentions "internet" but not TCP or UDP. I'd argue it's false advertising if it actually only supports a percentage of actual internet traffic.
1 reply →
Funny enough, the first and last time I heard of sctp was in “Unix network programming”. It seemed so promising according to Stevens.
3 replies →
SCTP was (and probably still is) supported in many NAT devices, firewalls, and other middleboxes.
SCTP has several fundamental design flaws, which are sufficient to discourage anyone from actually trying to make all the middleware support it.
What are those flaws? And are they inherent, or something that could be fixed with enhancements/revisions?
TCP as originally specified had fundamental design flaws too, but the TCP of today has significant differences from the 1981 TCP standard (not the first version of TCP, but the first version to see significant production use).
Off the top of my head: stream count is static (an extension exists nowadays, but it's still usually unsupported), startup requires requires excessive round trips, and it's unfixably insecure (TCP actually shares this last flaw - you can only detect, not discard, injected packets - and this causes massive reliability problems in the real world). Some of the default tools were also horribly flawed even by 1990s standards (e.g. a shell script which uses $* instead of $@) last I checked.
Certainly there are things that could be done to improve the ecosystem - but why bother when you can just use a reliability layer on top of UDP instead? And these days there's a "standard" solution so you don't even need to compare choices or worry about design flaws affecting just your program: just use QUIC, everybody uses it and if something goes wrong the world will scream and the shared library will be upgraded by the distro.