26 ms·

We tested this against WebRTC data channels (which also uses UDP) and found that the congestion control algorithm used for WebTransport limits its use for video

by mehagar 10mo ago

We tested this against WebRTC data channels (which also uses UDP) and found that the congestion control algorithm used for WebTransport limits its use for videoconferencing. We'll probably look into it again if browsers start allowing this to be configured.

valorzard 10mo ago
Did you try using the unreliable datagram extension?
Sean-Der 10mo ago
I haven't used WebTransport myself, how much can you control? I wonder how often libwebrtc does stuff that wouldn't be allowed in Javascript. Things like probing and overshooting the window? Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.
- kixelated 10mo ago
  There's no probing in any QUIC implementation but it's possible. There's a QUIC extension in the IETF similar to transport-wide-cc but it would still be up to the browser to use it for any upload CC.
kixelated 10mo ago
SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days. WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
- greenavocado 10mo ago
  SCTP: The FORWARD-TSN chunk was introduced to support selective unreliability: it allows the sender to tell the receiver that it will not retransmit some number of chunks, and requests that the receiver consider all these chunks as received.
  - kixelated 10mo ago
    QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams. I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing. QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
    - greenavocado 10mo ago
      Wow thanks for the tip

by mehagar 10mo ago

valorzard 10mo ago

Did you try using the unreliable datagram extension?

Sean-Der 10mo ago

I haven't used WebTransport myself, how much can you control? I wonder how often libwebrtc does stuff that wouldn't be allowed in Javascript. Things like probing and overshooting the window? Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.

kixelated 10mo ago
There's no probing in any QUIC implementation but it's possible. There's a QUIC extension in the IETF similar to transport-wide-cc but it would still be up to the browser to use it for any upload CC.

kixelated 10mo ago

SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days. WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.

greenavocado 10mo ago
SCTP: The FORWARD-TSN chunk was introduced to support selective unreliability: it allows the sender to tell the receiver that it will not retransmit some number of chunks, and requests that the receiver consider all these chunks as received.
- kixelated 10mo ago
  QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams. I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing. QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
  - greenavocado 10mo ago
    Wow thanks for the tip