Re: [Moq] congestion control (was: Two questions about how to move MOQ forward)

[Christian Huitema <[e-mail]>]

On 10/30/2021 7:27 PM, Bernard Aboba wrote:

> As a result, if QUIC were to be put forward as a solution, it would
> probably be with the understanding that the QUIC congestion control
> algorithm would be replaced with an algorithm more appropriate for realtime
> communications. Also, P2P operation might be required.

First, maybe just a nit, but there is not a single one "QUIC congestion 
control". There is a variant of TCP-RENO described in RFC 9002, but 
different implementations have used different algorithms. Both Cubic and 
BBR are widely deployed. Some implementations let the application select 
the algorithms from a menu, or even provide a plug-in API for selecting 
an application provided algorithm. Remember that QUIC is designed as an 
"in app" protocol, and that the application has a lot more flexibility 
than with an "in kernel" protocol.

The issue goes in fact beyond congestion control to include multiplexing 
and scheduling. Suppose an application carrying a mix of media, some 
real-time in nature and some not. For example, a conference application 
might have audio and video as well as document sharing. At least in 
theory, transporting those as a mix of QUIC streams and QUIC datagrams 
allow the application to manage allocation of the transport resource, 
and for example reduce video quality when pushing a copy of a document 
is more important, or vice-versa. In practice, that can easily go wrong. 
Which is why it might be good to share experience and suggestions...

-- Christian Huitema