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

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Mar 2022 09:42:49 +0000

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.

In the IRTF, ICCRG can provide advice about congestion control algorithms. 

Colin

> On 16 Feb 2022, at 01:12, Bernard Aboba <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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