Re: [Moq] Fwd: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt

[Bernard Aboba <[e-mail]>]

Sergio said:

"With RTP over QUIC we can do probing and bwe as in WebRTC. The main issue
is how the rtp bwe and the quic congestion control interact when running
simultaneously,  as we would get the worse of both worlds. Typically could
be bypassed by the native quic apps by removing the quic congestion control
and rely on the rtp bwe instead."

[BA]  Yes, there is a potential conflict between RTP and QUIC congestion
control, particularly with respect to recovery.  My expectation is that
native apps will remove QUIC congestion control in order to use something
closer to what is done in WebRTC (including mechanisms such as probing, to
allow faster recovery).  This is already done in server -> client low
latency streaming use cases such as game streaming or remote desktop.

"This approach however won't work for webtransport on browsers as the rtp
bwe would be done in the app js and the browser can't trust the js app to
do the right thing. "

[BA] Right.  Where media is sent Client -> server I think there is going to
be a problem.  Use cases that might be affected are video conferencing or
low-latency video upload, particularly if the client is sending simulcast
and/or SVC.  If there is loss and the client drops a layer, the client
won't be filling the congestion window so the BWE won't recover fast
enough. Adding back a simulcast or SVC layer is a "multiplicative
increase", not an "additive increase".  Without probing as there is in
WebRTC, app won't know when simulcast and/or SVC layers can be added back.
As a result, the JS application will be stuck sending low quality video.

On Wed, Oct 27, 2021 at 8:36 AM Sergio Garcia Murillo <
[e-mail]> wrote:

>
>
> El mié., 27 oct. 2021 17:02, Bernard Aboba <[e-mail]>
> escribió:
>
>> Sergio said:
>>
>> "We should only support RTP over quick datagram, what about
>> webtransport support?"
>>
>> [BA] Currently there are issues with WebTransport support for Web
>> realtime communications in the client -> server direction, summarized here:
>>
>> https://docs.google.com/presentation/d/1SG1FUvn9UKGx_gAqWnCzPHlsIXkDUXctZPs7blfqS5k/
>>
>> While the metrics issue is unique to WebTransport, the issues with QUIC
>> congestion control will also affect realtime media directly over QUIC.  The
>> biggest issue is slow recovery of media quality after packet loss. Without
>> probing similar to what is done in WebRTC today, recovering media quality
>> will be slow, particularly when simulcast or SVC is used.
>>
>
> With RTP over QUIC we can do probing and bwe as in WebRTC. The main issue
> is how the rtp bwe and the quic congestion control interact when running
> simultaneously,  as we would get the worse of both worlds. Typically could
> be bypassed by the native quic apps by removing the quic congestion control
> and rely on the rtp bwe instead.
>
> This approach however won't work for webtransport on browsers as the rtp
> bwe would be done in the app js and the browser can't trust the js app to
> do the right thing.
>
> Best regards
> Sergio
>
>
>
>