SCTP is a good protocol itself, but there are lots of NAT devices/firewalls/other strange middleboxes that do not play nice with SCTP. These devices only recognize TCP and UDP, and they tend to drop everything they do not know.

This is not something very easy to fix - not as easy as fixing Cisco devices that hijack 1.1.1.1, or upgrade enterprise-grade MITM firewalls that don't know and block TLS 1.3.

Can't you just encapsulate SCTP in UDP? Isn't that the reason we have UDP in the first place? If a middlebox will pass QUIC, it should stand to reason that it'll pass SCTP over UDP, since they're both oddball UDP protocols.

Luckily, SCTP, like QUIC, has a standardized UDP encapsulation.

If you do SCTP in user space with UDP encapsulation, most of its benefits disappear (and you have to do that - also because of Windows).

It's standard only on paper. There is only one significant user space implementation (usrsctp). It's used both by Chrome and Firefox. I don't think it has much use outside of that. And, I don't think other browsers implement data channels (which require SCTP).

Browser implementations will probably never have to interact with kernel implementations (which are not really used outside of telecoms). There is really no reason to make them talk the same protocol. It's likely better to use two different protocols tuned to those specific uses:

https://tools.ietf.org/html/draft-joseph-quic-comparison-qui...

They will probably replace SCTP with QUIC also in WebRTC:

https://w3c.github.io/webrtc-quic/

You only need to do UDP encapsulation on the client side (and then again, you can easily fallback to the kernel acceleration on supported platforms). On the server side, SCTP has a BSD sockets API already, and with some creative ethernet bridging, you can convince the kernel to unencapsulate your SCTP packets (doing this right now in a project for WebRTC, so I know it's possible). This is a one-time investment that can be made open-source and can be done in userspace. Of course, a kernel patch to encapsulate SCTP in UDP shouldn't be that difficult either.

There's two sides to networking -- client and server. Your arguments may make sense for the client, but they do not make sense for the server, IMO.

> There is only one significant user space implementation (usrsctp)

That's right, but there are others (one was posted a while back) independent implementations, and the kernel implementations (BSD, Linux, likely others) are indeed different.

> There is only one significant user space implementation

Only one significant opensource implementation. Behind the scenes, SCTP is used to connect most telephone calls in the world.

The "IMPLEMENTED IN EVERY MAJOR BROWSER" refers to SCTP-over-UDP (as used by WebRTC).

You are forgetting to explain why the technology is preferable, apart from expressing that the technology is well-supported.

I know little about SCPT. Why is it preferable?

SCTP is a flexible transport protocol with a crazy amount of features. It is message-oriented and each message on a connection belongs to a stream (of which there can be many). Each stream is optionally ordered, but this is managed independently for each stream in a connection. My understanding is that you can tune each stream separstely from unreliable, unordered to fully reliable and ordered as your application needs it.

This looks to me like a strict superset of what QUIC is intended to solve. And it is already supported in all major operating systems.

More frustratingly, I can imagine a future where SCTP encapsulated in UDP, serving for what QUIC is going to end up doing, would have caused adoption of kernel-mode SCTP drivers and the addition of SCTP support in the damnable "middle boxes" driving this whole mess to begin with.

> 4. IT'S ALREADY IMPLEMENTED IN EVERY MAJOR BROWSER!

Google is not interested in what is implemented in every major browser. Google is interested in making sure that Chrome is the only browser of any significance on the internet and it behaves in a way that Google wants it to behave ( such as forcefully signing into Google services ).

That's why we got HTTP/2 ( which seems to be viewed as a flop at Google ) which is why we are getting HTTP/3.

Follow. The. Money.