[banthar]

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/

[tathougies]

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.

[unmole]

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