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

Hi Spencer,

> On 11 Apr 2022, at 06:34, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Colin, 
> 
> On Fri, Mar 25, 2022 at 4:44 AM Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>> 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. 

Colin

> Best,
> 
> Spencer
>  
> In the IRTF, ICCRG can provide advice about congestion control algorithms. 
> 
> Colin
> 
> 
>> On 16 Feb 2022, at 01:12, Bernard Aboba <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> wrote:
>> 
>> At IETF 112, the W3C WebTransport WG presented a request for feedback to the AVTCORE WG:
>> https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/edit#slide=id.gfc2dae0c1a_0_125 <https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/edit#slide=id.gfc2dae0c1a_0_125>
>> 
>> The request related to problems encountered with W3C WebTransport API use cases involving attempts to send media with low latency from client -> server. Currently, WebTransport implementations are based on BBRv1 congestion control in QUIC and support datagram prioritization in an effort to improve QUIC datagram latency.
>> 
>> The presentation today from M. Engelbart appears to shed light on the request, even though the results presented were based on NewReno CC instead of BBRv2/v2. 
>> 
>> Based on the experimental results, can we make any recommendations?  For example, can we say: 
>> 
>> 1.  Attempting to implement a low-latency congestion control algorithm for QUIC datagrams (e.g. SCReaM or GCC) on top of QUIC congestion control (New Reno, BBRv1/v2) isn't recommended.  Instead, it is preferred to implement an alternative CC algorithm within the QUIC implementation. 
>> 
>> 2. Naive prioritization schemes such as strict priority for QUIC datagrams result in high queueing delays, since reliable stream data will fill the congestion window when datagrams aren't being sent.  This problem will occur even with CC algorithms such as BBRv1/v2 (not just NewReno). 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
> 
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org <mailto:avt@ietf.org>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

-- 
Colin Perkins
https://csperkins.org/