[AVTCORE] draft-ietf-avtcore-rtp-over-quic: Congestion Control and Rate Control

[Bernard Aboba <[e-mail]>]

Looking over the coverage Congestion Control and Rate Control, the two
topics appear to be conflated and also there appear to be some issues that
have not been fully considered.

Section 1.2.2

While the effect of QUIC's response to congestion means that some RTP
packets will arrive at the receiver later than a user of the RTP flow might
prefer, it is still preferable to "ceasing transmission" completely until
the RTP sender has a reason to believe that restarting the flow will not
result in congestion.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-1.2.2-3>

[BA] In contrast to circuit breakers, which do not restrict the ability to
send RTCP feedback, QUIC congestion control affects RTCP feedback, not just
RTP.  So saying QUIC congestion control is "preferable" seems questionable.

Moreover, when a single QUIC connection is used to multiplex both RTP-RTCP
and non-RTP packets as described in Section 1.2.5
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#single-path>,
the QUIC connection will still be Internet-safe, with no coordination
required.

[BA] While it may be "Internet-safe", delays in RTCP feedback are likely to
destabilize rate control as well as resulting in challenges to A/V sync.
So not sure that "Internet-safe" is the only important metric here.

Section 1.2.3

One word of caution is in order - RTP implementations may rely on at least
some minimal periodic RTCP feedback, in order to determine that an RTP flow
is still active, and is not causing sustained congestion (as described in [
RFC8083 <https://www.rfc-editor.org/rfc/rfc8083>], but since this
"periodicity" is measured in seconds, the impact of this "duplicate"
feedback on path bandwidth utilization is likely close to zero.

[BA] Under congestion, RTCP feedback can potentially be delayed
substantially. Here is the issue is not "bandwidth utilization" but whether
RTCP receives the transport treatment required for control traffic.  Note
also that similar considerations apply to treatment of audio vs. video.
Serious problems with a/v sync are possible (or even likely) under
congestion.

Section 1.2.4

This is especially useful in certain conferencing topologies, where
otherwise senders have no choice but to use the lowest path MTU for all
conference participants, but even in point-to-point RTP sessions, this also
allows senders to piggyback audio media in the same UDP packet as video
media, for example, and also allows QUIC receivers to piggyback QUIC ACK
frames on any QUIC frames being transmitted in the other direction.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-1.2.4-2>

[BA] The draft does not talk much about piggybacking of audio and video
media, but we have seen some implementations experimenting with this to
avoid audio/video sync issues without having to resort to other techniques
such as prioritization.  Is this something that deserves more discussion?

Section 2

Rate control:

A congestion control mechanism that helps a sender determine and adjust its
sending rate, in order to maximize the amount of information that is sent
to a receiver, without causing queues to build beyond a reasonable amount,
causing "buffer bloat" and "jitter". Rate adapation is one way to
accomplish congestion control for real-time media, especially when a sender
has multiple media streams to the receiver, because the sum of all sending
rates for media streams must not be high enough to cause congestion on the
path these media streams share between sender and receiver.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-2-4.18.1>


[BA] Rate control and congestion control are distinct. So the definition
here doesn't seem right, particularly for RoQ where congestion control is
built into QUIC while rate adaptation is application and even
codec-specific.


Overall, a better way to think of the distinction is that QUIC congestion
control limits the amount that can be sent. Since realtime applications
seek to achieve low latency, they will typically prefer to respond to
bandwidth limitations by controlling rate, rather than experiencing
queueing delays or increased loss.


But since congestion control and rate control are distinct and are handled
at different layers, rate control is not "one way to accomplish congestion
control" but rather "one way to respond to send rate limitations imposed by
congestion control algorithms".


Section 3


A rate adaptation algorithm can be plugged in to adapt the media bitrate to
the available bandwidth. This document does not mandate any specific rate
adaptation algorithm, because the desired response to congestion can be
application and codec-specific. For example, adjusting quantization in
response to congestion may work well in many cases, but if what's being
shared is video that includes text, maintaining readability is important.


[BA] This text is good. I believe it should be placed earlier in the
document (perhaps in the scope section).


As of this writing, the IETF has produced two Experimental-track rate
adaptation specifications, Network-Assisted Dynamic Adaptation (NADA) [
RFC8698 <https://www.rfc-editor.org/rfc/rfc8698>] and Self-Clocked Rate
Adaptation for Multimedia (SCReAM) [RFC8298
<https://www.rfc-editor.org/rfc/rfc8298>]. These rate adaptation algorithms
require some feedback about the network's performance to calculate target
bitrates. Traditionally this feedback is generated at the receiver and sent
back to the sender via RTCP.


[BA] Within the context of the previous paragraph is it correct to
characterize these specifications as "rate adaptation algorithms"?  The
previous paragraph mentions QP-based rate control which is indeed codec and
application specific. NADA, SCReAM, gcc, etc. were developed as congestion
control algorithms and therefore they do not provide application and
codec-specific rate control mechanisms.


Section 6


Like any other application on the internet, RoQ applications need a
mechanism to perform congestion control to avoid overloading the network.
While any generic congestion controller can protect the network, this
document takes advantage of the opportunity to use rate adaptation
mechanisms that are designed to provide superior user experiences for
real-time media applications.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6-1>

[BA] This paragraph appears to conflate congestion control and rate
control. Congestion control is built into QUIC, and RoQ therefore inherits
it. So RoQ applications have a mechanism for congestion control.

Since earlier it was stated that there is no normative guidance on rate
control, how can "this document take advantage of the opportunity to use
rate adaptation mechanisms that are designed to provide superior user
experiences"?

A wide variety of rate adaptation algorithms for real-time media have been
developed (for example, "Google Congestion Controller" [
I-D.draft-ietf-rmcat-gcc
<https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02>]). The IETF
has defined two algorithms in two Experimental RFCs (e.g. SCReAM [RFC8298
<https://www.rfc-editor.org/rfc/rfc8298>] and NADA [RFC8698
<https://www.rfc-editor.org/rfc/rfc8698>]). These rate adaptation
algorithms for RTP are specifically tailored for real-time transmissions at
low latencies, but this section would apply to any rate adaptation
algorithm that meets the requirements described in "Congestion Control
Requirements for Interactive Real-Time Media" [RFC8836
<https://www.rfc-editor.org/rfc/rfc8836>].


[BA] As noted earlier, these are not rate control algorithms (e.g.
per-frame QP), they are congestion control algorithms.


This document defines two architectures for congestion control and
bandwidth estimation for RoQ, depending on whether most rate adaptation is
performed within a QUIC implementation at the transport layer, as described
in Section 6.1
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#cc-quic-layer>,
or within an RTP application layer, as described in Section 6.2
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#cc-application-layer>,
but this document does not mandate any specific congestion control or rate
adaptation algorithm for either QUIC or RTP.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6-3>

[BA] QUIC implementations cannot implement rate control, because as you
state earlier, that is application and/or codec-specific. So again you seem
to be conflating congestion control and rate control.

It is assumed that the congestion controller in use provides a pacing
mechanism to determine when a packet can be sent to avoid bursts. The
currently proposed congestion control algorithms for real-time
communications (e.g. SCReAM and NADA) provide such pacing mechanisms. The
use of congestion controllers which don't provide a pacing mechanism is out
of scope of this document.
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6-6>

[BA] In this paragraph you correctly refer to SCReaM and NADA as congestion
control algorithms. Please use this terminology consistently.

Section 6.1

If a QUIC implementation is to perform rate adaptation in a way that
accommodates real-time media, one way for the implementation to recognize
that it is carrying real-time media is to be explicitly told that this is
the case. This document defines a new "TLS Application-Layer Protocol
Negotiation (ALPN) Protocol ID", as described in Section 4
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#alpn>,
that a QUIC implementation can use as a signal to choose a real-time
media-centric rate controller, but this is not required for ROQ deployments.
¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.1-2>

[BA] Again, QUIC implementations do not perform rate adaptation. That is an
application layer function. I think you mean "perform congestion control"
here.

However, congestion control is orthogonal to the use of an ALPN, so mixing
these two concepts is problematic.

If congestion control is to be applied at the transport layer, it is
RECOMMENDED that the QUIC Implementation uses a congestion controller that
keeps queueing delays short to keep the transmission latency for RTP and
RTCP packets as low as possible, such as the IETF-defined SCReAM [RFC8298
<https://www.rfc-editor.org/rfc/rfc8298>] and NADA [RFC8698
<https://www.rfc-editor.org/rfc/rfc8698>] algorithms.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.1-3>

[BA] You might also mention L4S here. This seems more likely to be
supported with QUIC than the algorithms you mention in the draft.

If congestion control is done by the QUIC implementation, the application
needs a mechanism to query the currently available bandwidth to adapt media
codec configurations. The employed congestion controller of the QUIC
connection SHOULD expose such an API to the application. If a current
bandwidth estimate is not available from the QUIC congestion controller,
the sender can either implement an alternative bandwidth estimation at the
application layer as described in Section 6.2
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#cc-application-layer>
 or a receiver can feedback the observed bandwidth through RTCP, e.g., using
 [I-D.draft-alvestrand-rmcat-remb
<https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-remb-03>].¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.1-5>

[BA] This paragraph is good, since it describes how the QUIC implementation
provides info to the application, to be used in rate control. I think you
need to be more clear about the relationship throughout the document. But
the normative language is problematic because this document cannot have
normative API dependencies. Also, you need to be careful with references to
drafts which will not be published as RFCs, particularly REMB which has
been deprecated in favor of transport CC.


Section 6.2

The rate adaptation algorithms for RTP are specifically tailored for
real-time transmissions at low latencies, as described in Section 6
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#congestion-control>.
The available rate adaptation algorithms expose a target_bitrate that can
be used to dynamically reconfigure media codecs to produce media at a rate
that can be sent in real-time under the observed network conditions.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.2-2>

[BA] Again, there is a conflation of rate adaptation and congestion
control. In this paragraph "congestion control algorithms" should be used
instead of "rate control algorithms".

Section 6.3

Because QUIC is a congestion-controlled transport, as described in Section
6.1
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#cc-quic-layer>,
and RTP applications can also perform congestion control and rate
adaptation,

[BA] Since congestion control is built into QUIC, RoQ applications can only
do rate control, not congestion control.

   - Application-limited Media Flows - if an application chooses RTP as its
   transport mechanism, the goal will be maximizing the user experience, not
   maximizing path bandwidth utilization. If the application is, in fact,
   transmitting media that does not saturate path bandwidth, and paces its
   transmission, more heavy-handed congestion control mechanisms (drastic
   reductions in the sending rate when loss is detected, with much slower
   increases when losses are no longer detected) should rarely come into play.
   If the application chooses ROQ as its transport, sends enough media to
   saturate the path bandwidth, and does not adapt its own sending rate,
   drastic measures will be required in order to avoid sustained or
   oscillating congestion along the path.¶
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.3-2.1>


[BA] This document probably isn't the right place to discuss this, but it
is a very big issue that has limited the deployment of the algorithms
produced by RMCAT, because probing was supported by gcc and not in the
NADA, SCreAM, etc. In practice, fixing this problem requires probing
controlled by the CC algorithm at the QUIC layer. So far I'm not aware of
any QUIC implementations which support this kind of probing.


¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-3-3>



¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-1.2.3-2>