Hacker News Reader

Comment by hexchain | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com