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

Hi, Colin,

On Fri, Mar 25, 2022 at 4:44 AM Colin Perkins <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).

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> 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
>
> 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
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>