Hey guys, Luke from Twitch here. I originally wrote a longer wall of text but I’ll keep it brief for now.
We’re messing around with WebRTC and definitely agree with the direction of this proposal. There are a lot of people (including ourselves) that are using WebRTC outside of video conferencing and would like to decouple the transport layer. WebRTC built on top of WebTransport would be amazing.
In our case, we want a way to transfer ordered but semi-reliable messages. This was not possible in browsers until WebRTC DataChannels.
DataChannels are great because the browser handles fragmentation, retransmitting individual packets, ordering packets into a message, dropping messages, and ordering any delivered messages into a stream. All you have to do is configure the stream and you get a function callback for each delivered message in the order they were sent.
With WebTransport unreliable streams, the browser performs fragmentation and orders packets into a message. We would have to make a stream per message and append some identifier to each message (in order mux other types of streams). If we determine a packet is lost after a timeout (NACK/SACK not possible), we need to retransmit the ENTIRE message (blocker: our messages are big). We would need to append a sequence number to each message, reordering them ourselves. This wouldn’t be acceptable.
With WebTransport datagrams, we would probably implement something similar to SCTP/QUIC on top. That’s fine to be honest. I’m not a fan of the overhead involved in implementing SCTP on top of UDP on top of QUIC on top of UDP.