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

Hi,

We discussed some of these issues on GitHub and opened a Pull Request to 
address them:

Issue: https://github.com/mengelbart/rtp-over-quic-draft/issues/128
Pull Request: https://github.com/mengelbart/rtp-over-quic-draft/pull/134

A diff of the documents can be seen here:

https://author-tools.ietf.org/api/iddiff?url_1=https://mengelbart.github.io/rtp-over-quic-draft/draft-ietf-avtcore-rtp-over-quic.txt&url_2=https://mengelbart.github.io/rtp-over-quic-draft/fix/128-congestion-and-rate-control/draft-ietf-avtcore-rtp-over-quic.txt

We moved some of the points Bernard made into separate issues, for which 
we will open separate pull requests:

https://github.com/mengelbart/rtp-over-quic-draft/issues/135
https://github.com/mengelbart/rtp-over-quic-draft/issues/141

If no one objects, we will merge pull request #134 by the end of the 
week to include it in a new submission, which we will make before the 
deadline next Monday.

Best,
Mathis

On 9/24/23 23:48, Bernard Aboba wrote:
> 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 inSection 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>
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt