The primary problem is that Microsoft blatantly refuses to even consider adding support for it. Without full access to it on clients, it’ll go nowhere fast.

SCTP is awesome, and I’m saddened that it seems to be struggling to gain traction while older and far more problematic/limited protocols building on the even older and even more limited IP stack keep the net back.
All the nifty things they do on IP these days, like web sockets and streams are essentially hacks trying to approximate what you get out of the box on SCTP.

I don’t think so.

Doing new things meant risk as well as longer time to get a standard approved and vendors behind the initiative. Going with something that is known made more sense.

Don’t be so harsh. It’s a good protocol.
Some info – SCTP was created as an effort to allow carrying SS7(signalling) traffic on top of IP. TCP is not suitable for this purpose. This is the reason SCTP is message oriented(rather than stream) and supports redundancy on protocol level (multi-homing). SS7, for the readers not familiar with Telecoms, is an ancient protocol stack which predates TCP/IP and has its roots in circuit switched networks.
The lovechild of this effort is the SIGTRAN stack. Currently SCTP + M3UA is the de-facto standard for carrying signalling traffic in Telco networks around the world.
Yes, SCTP presence in consumer devices might be abysmal but that’s not true in general. There are many products and systems which rely on it. Implementations(some proprietary) are mostly for Linux, Unix and Solaris (yeah nobody runs Windows in this kind of environment).

Back to the topic why SCTP is used for WebRTC. Maybe (I don’t know) the idea was to make WebRTC ubiquitous. Make it a standard for both consumer peer to peer communications and larger scale enterprise systems(PBXs). SCTP shines in use cases where two nodes communicate with each other for the sessions of many users.
There were plenty of vendors on the last MWC(in Barcelona) offering enterprise products which supported WebRTC(along with other protocols).

I don’t know how technically accurate you want to be, but ICE does not encapsulate packets:
so it’s actually SCTP over DTLS with ICE, not over ICE.

well, some of the recent discussions on the IETF list make it seem that SCTP now gets the first real deployment experience.

That also seems true for TURN though 😉

Protocols like SCTP can perfectly done in user space. You only need the kernel to make sure that one application can’t receive packets of a different application — UDP does this in the webrtc case. On could argue that moving session-specific protocol handling into user space is the rigth thing to do if you believe in the end-to-end principle. The kernel is just another hop on the path. It is always easier to add function to an application than adding a function to the kernel (see tls vs ipsec).

Without knowing the details, I assume there are packets that don’t need to go “all the way up” to the application.

There’s also the nagging issue of needing to reassemble packets into messages (again, no need to do that in user space).

And there’s the possibility of using asynchronous I/O or lord forbid zero copying (or close to it).

What I am looking for, is an SCTP kernel mode implementation that is comparable to that of UDP and TCP – both live in kernel mode and spewing buffers up to the application.

That’s a big ask. Looking at your diagram, you’ll have to push DTLS and ICE into the kernel too. If you don’t every
packet that is received by the kernel will come out to the ICE/DTLS stack in user land, then transit back into the kernel for SCTP, then back out again to the end application, which would be staggeringly inefficient.
There is also a downside to pushing SCTP down to the kernel, you lose the tight connection of the data channel with the rest of the web app/media and blur the security boundaries between users. Both are currently pretty well served in webRTC.

I can imagine some gateways (say to IMS or the rest of the legacy VoIP world) might want to push all of this into a product specific kernel. However for the bulk of the server side webRTC use-cases you want the data-channel close to the web app so as to leverage the context of the web session.

Tim,

For a first release, that will do. The thing is that data channel related startups are already taking this capability to the extreme with their P2P assisted delivery. To make this work well, SCTP will need to find its way into the kernel instead of running on top of the OS in user mode.