Improved congestion control for real-time use cases

[jan-ivar]

While WebTransport already offers tangible benefits over WebRTC like scaling, the model of using WebCodecs for encode/decode and WebTransport for secure delivery seems appealing for real-time conferencing as well, perhaps someday even replacing WebRTC.

Last year at TPAC 2024 we presented latency numbers around ~200 ms.

More recently, at today's WebRTC interim meeting proposing a third API for p2p real-time use cases, concerns were raised that ~200 ms isn't sufficient for real-time conferencing.

It seems most video conferencing today doesn't even rely on p2p, so if WebTransport's CC today is insufficient for real-time, this sounds like something we should consider improving.

I'm filing this issue to track this concern.

Note, WebTransport already supports the congestionControl option, so this may be more about tracking implementation progress toward that goal:

const wt = new WebTransport(url, {congestionControl: "low-latency"});

[jan-ivar]

cc @pthatcher

[wilaw]

concerns were raised that ~200 ms isn't sufficient for real-time conferencing.

It should be noted that that 200ms number was an overall hand-waving latency result from Bernard that included media encode time via WebCodecs, transmission using WebTransport over an unspecified RTT, and then decode and rendering again via WebCodecs.

Last year I did a head-to-head test between WebRTC and WebCodecs+Webtransport. Installed a MOQ relay (early version of Moxygen using WebTransport for transport) and a WebRTC server on the same machine in Los Angeles, and then tested rountrip hand-waving latency from Zurich using a common OBS camera source. Screenshot below shows the result - which was almost identical hand-waving latency between the two solutions.

[alvestrand]

Note that the ITU specs 200 as the maximum acceptable delay for telephone audio (https://en.wikipedia.org/wiki/Latency_(audio)#Telephone_calls) - "after this, measured quality declines rapidly".
And in any server-based VC system, there are at least 2 hops.

[jan-ivar]

Meeting:

• Do we need a "real-time" enum value as well?

[jan-ivar]

This feels like a repeat of #365. Arguably, we already added "low-latency" for this. The enums are vague enough already that adding a third value seems premature. I suggest we park this for now.