Re: [AVTCORE] Response to W3C WebTransport WG Request from IETF 112

[Sergio Garcia Murillo <[e-mail]>]

On Mon, Apr 11, 2022 at 10:08 AM Colin Perkins <[e-mail]> wrote:

> Hi Spencer,
>
> On 11 Apr 2022, at 06:34, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
> Hi, Colin,
>
> On Fri, Mar 25, 2022 at 4:44 AM Colin Perkins <[e-mail]> wrote:
>
>> Hi,
>>
>> To echo my comments at the mic during IETF 113.
>>
>> RFC 8888 describes the information the group believed needed to perform
>> congestion control. QUIC already provides this information in connections.
>>
>> The RMCAT working group developed a number of RTP congestion control
>> algorithms. I expect these could be incorporated into QUIC as alternatives
>> to its current congestion control, if there was as need, but RMCAT isn’t
>> chartered to do so.
>>
>
> ISTM that there are two issues here, wrapped around each other.
>
> We don't have a way to signal congestion controllers in QUIC now, because
> the choice of NewReno, or CUBIC, or BBRv1, or BBRv2, or whatever, doesn't
> need that for HTTP/3 traffic.
>
> I'm not sure (are others sure?) whether we would need to be able to choose
> between media-oriented congestion controllers (SCReAM, or NADA, or
> whatever) for RTP traffic. So, that's one interesting issue.
>
> But even if we don't need to choose between media-oriented congestion
> controllers, we would need a QUIC extension to allow us to say "we're doing
> media, so don't use the congestion controllers you might use for non-media
> traffic".
>
> I suspect the QUIC working group would be a fine place to work on that
> extension (and if we did it anywhere else, QUIC would either ask, or be
> asked, to review that work anyway).
>
>
> I’d agree that, if such signalling is needed, the QUIC working group would
> be the right place to develop it.
>
> Does it need signalling though? Most (all?) of the congestion control
> algorithms for QUIC seem to be entirely driven by the sender, which knows
> that it’s sending media.
>
>
I agree, this should be more a WebTransport API  to allow the JS app to
inform the QUIC stack in the browser to use a media-friendly delay
sensitive quic CC (BBR, COPA, etc). I don't think that this API should
specify the exact CC algorithm, and it should be left up to the
implementation to choose which one to use. At the QUIC level, it could be
needed to allow the sender to turn on an extended feedback mechanism so the
reveicer provide a more accurate timing information of the packet arrival
timestamps and maybe expose those stats to the js app so it can implement
the media bwe algorithm by itself.

I would like also to take the opportunity to introduce David Baldassin who
has been working on reproducing the results of the "Congestion Control for
Real-time Media over QUIC" paper and has found some interesting results we
will be likely to share in upcoming IETF meetings. Also, he is also working
on extending the test to support different QUICK implementations with more
support of CC algos (BBR/COPA) and also test with webrtc GCC bwe.

Best regards
Sergio