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

[David Baldassin <[e-mail]>]

Hi,

Thank you Sergio for the introduction.
I would be happy to share my results and contribute to the effort for
real-time media over QUIC and CC algorithms.

Best regards,
David

On Mon, Apr 11, 2022 at 12:45 PM Sergio Garcia Murillo <
[e-mail]> wrote:

>
>
> 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
>


-- 
David Baldassin