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

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Feb 2022 17:12:55 -0800

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