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

[Bernard Aboba <[e-mail]>]

The text relating to QUIC and RTP is somewhat confusing;

Like any other application on the internet, RoQ applications need a
mechanism to
perform congestion control to avoid overloading the network. QUIC is a
congestion-controlled transport protocol. RTP does not mandate a single
congestion control mechanism. RTP suggests that the RTP profile defines
congestion control according to the expected properties of the application's
environment.

[BA] When run over QUIC, RoQ has to live with QUIC congestion control; this
is not defined by the profile.
So this paragraph is confusing.


This document discusses aspects of transport level congestion control in
{{cc-quic-layer}} and application layer rate control in
{{rate-adaptation-application-layer}}. It does not mandate any specific
congestion control or rate adaptation algorithm for QUIC or RTP.

[BA] Within RoQ, QUIC does not handle rate adaptation, nor does RTP handle
congestion control.
So this sentence is also confusing.

On Mon, Oct 16, 2023 at 11:03 AM Bernard Aboba <[e-mail]>
wrote:

> The definition of rate adaptation still has some issues.
>
> Rate Adaptation:
> : A mechanism that adjusts the sending rate of an application in order to
> maximize the amount of information that is sent to a receiver without
> causing
> buffer bloat, when queues build beyond a reasonable amount, or jitter, when
> interpacket arrival times fluctuate due to queuing delays.  Rate
> adaptation is
> one way to respond to sending rate limitations imposed by congestion
> control
> algorithms. When a sender has multiple media streams to the receiver, 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.
>
> [BA]  This definition still mixes congestion control concepts with rate
> control ones.
> It is the congestion control algorithm that estimates the sending rate.
> It can
> take into account loss, as well as queuing effects, depending on the
> algorithm.
> The use of "must not" is confusing because it suggests normative language
> and
> because a rate set in excess of that set by congestion control cannot cause
> congestion - the packets will just be queued or dropped.
>
> I would suggest simplifying the definition as follows:
>
> Rate adaptation
> A mechanism that adjusts the sending rate of an application in order to
> respond to sending rate limitations imposed by congestion control
> algorithms.
>
>
>
>
> On Mon, Oct 16, 2023 at 9:38 AM Mathis Engelbart <[e-mail]>
> wrote:
>
>> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/avt
>>
>