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

[Joerg Ott <[e-mail]>]

Hi,

we just finished a small initial study on congestion control in
QUIC vs. in RTP vs. in both places and their interaction.  These
early results suggest the suspected, i.e., the interaction of
two congestion control loops may be problematic and that
prioritization or some other way of sharing available capacity
(as, e.g., determined by QUIC) and then scheduling reliable
stream and datagram frames accordingly is needed.

We also confirm that one can reuse QUIC state information to
replace dedicated RTCP signaling for congestion control.

This paper will appear in the EPIQ workshop in December:
https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf

Overall, the RTP over QUIC designs submitted as drafts appear
reasonably workable; more experiments in progress, there is
still a way to go.

Best,
Jörg

On 27.10.21 18:24, Bernard Aboba wrote:
> 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] 
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>     El mié., 27 oct. 2021 17:02, Bernard Aboba <[e-mail]
>     <mailto:[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/
>         <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
> 
> 
> 
>