Why was SCTP selected for WebRTC’s data channel? (2014) | Hacker News Reader

Why was SCTP selected for WebRTC’s data channel? (2014)

bloggeek.me

70 pointsfortran7711 comments

I think SCTP was a very good choice.

Writing a SCTP implementation for Pion WebRTC[0] was really enjoyable. The SCTP RFC is well written and easily available [1]. Once you learn all the chunk types things start to fall into place. SCTP is also battle tested and we know what flaws it has.

I am pessimistic about alternatives

* New protocols/changes are spread across multiple drafts, and they are abandoned once they land in browsers. Most of the time these changes are already going to happen and these drafts are just a way to notify the general public it is happening. So it ends up being 'the implementation is the spec', and things are brittle. SCTP doesn't break like that.

* WebRTC is still very difficult to use. For large dev teams/corporations it is a solved problem, but I really wish there was more excitement/emphasis around lowering the barrier to entry. It is a really powerful technology, but it seems like we just keep getting half-baked things out the door and then moving on.

[0] https://github.com/pion/webrtc

[1] https://tools.ietf.org/html/rfc4960

RFC490 was simply a "rollup" of SCTP at that point with minor corrections not some protocol with immaculate birth where the initial RFC gets you up to date with the protocol. It also features a large set of errata and about a dozen feature extension RFCs that have come out since (as well as an RFC on security attacks found against SCTP that one definitely should to read before writing an implementation). I'm also not familiar with any recent protocol added to browsers that has been abandoned from a standards perspective in the way you describe. Websockets and what were known as SPDY & Quic have more standards activity than ever before.

Are you referring to the barrier to use WebRTC or the barrier to make your own implementation?

Hey Sean-Der, thank you for writing Pion! In my opinion, it's the cleanest and easiest to use WebRTC implementation.

Hi Sean,

I read some article about SCTP but I still keep wondering what the best usecase for SCTP is. Can you give some examples?

SCTP has been used in professional settings for telecoms for at least a decade.

The kernel implementation in Linux is stable and has been for many versions.

There are gotchas: - Cloud support for SCTP is poor. Azure has no support for SCTP on its load balancers. - Kubernetes support is similarly poor - SCTP support is beta and behind a feature gate.

Have you done SCTP over the public internet?

I haven't tried it myself, but always heard the only way to make it work was encapsulated in UDP.

Probably down to whether routers can do NAT for SCTP, I'm part way through adding support for it in the firewall that I use.

Routing SCTP over IPv6 should be easier.

A lot of providers will filter out SCTP at the boundaries, especially for consumers. I know of providers that only whitelist TCP and UDP on their gateways.

Note the final implementation is not running directly over IP, as section 1.2 of rfc 4960 says. Instead, WebRTC uses “SCTP over DTLS over ICE/UDP”. This unfortunately means that WebRTC adoption means nothing for general STCP apps, and will never care about kernel-based implementations.

I've written that article a few years back. Today things are worse for SCTP - there are thoughts and a general intent in replacing SCTP altogether with QUIC. Didn't happen yet, but probably will in a couple of years.

Do you know of anyone that is interested in bridging that gap? I only have done user-space/embedded WebRTC. After Pion WebRTC I got hired to write a pure C WebRTC implementation [0] that is at around ~700kb. It does media + DataChannels.

I want to eventually explore building a very minimal SCTP implementation and maybe get the binary size sub 400Kb. IoT/Embedded is just getting warmed up to WebRTC, I am really excited to see what happens next.

[0] https://github.com/awslabs/amazon-kinesis-video-streams-webr...

Reply on news.ycombinator.com