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

[Mathis Engelbart <[e-mail]>]

On 10/16/23 20:27, Bernard Aboba wrote:
> More feedback:
> 
> 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.
> 
> [BA] Queueing delays are not solely determined by the QUIC congestion 
> control algorithm.  They are also affected by the manner in which RTP 
> and RTCP are transported.
> 
> For example, if the goal is to reduce potential RTCP latency, then 
> transport over QUIC datagrams might make sense.
> Similarly, for audio, transport of RTP over QUIC datagrams (or use of 
> partial reliability with QUIC streams) might be considered.
> 
> So I might rewrite this as follows:
> 
> It is RECOMMENDED that the QUIC implementation use a congestion 
> controller that seeks to minimize queueing delays.  Further 
> recommendations on the transport of RTP and RTCP are contained in 
> Section X.

[ME] I updated this in the pull request.

> If an application cannot access a bandwidth estimation from the QUIC 
> layer, the
> application can alternatively implement a bandwidth estimation algorithm 
> at the
> application layer. Congestion control algorithms for real-time media 
> such as GCC
> {{?I-D.draft-ietf-rmcat-gcc}}, NADA {{?RFC8698}}, and SCReAM 
> {{?RFC8298}} expose
> a `target_bitrate` to dynamically reconfigure media codecs to produce 
> media at
> the rate of the observed available bandwidth. Applications can use the same
> bandwidth estimation to adapt their rate when using QUIC. However, 
> running an
> additional congestion control algorithm at the application layer can have
> unintended effects due to the interaction of two *nested* congestion
> controllers.
> 
> [BA] This paragraph muddies the distinction between congestion control
> at the QUIC layer and rate adaptation at the RTP layer. Since "nested
> congestion" control is undesirable, suggest the following text
> instead:
> 
> "If an application cannot access a bandwidth estimate from the QUIC layer,
> it can attempt to implement a bandwidth estimation algorithm. However, the
> use of nested bandwidth estimates is NOT RECOMMENDED, since this
> can yield unpredictable results.  For example, if the application-derived
> bandwidth estimate is larger than that derived by QUIC, then the application
> will not be able to send at its desired rate, and queuing or loss may 
> occur."

[ME] I don't see how it muddies the distinction. The point of the 
paragraph is to explain that nested congestion control is undesirable. 
If there is no way to get a target bitrate from the underlying 
transport, then one option is to use RTP and RTCP feedback to implement 
GCC/NADA/SCReAM in the application, which may not be a good idea. The 
alternative is to estimate the available bandwidth from the available 
feedback without running a congestion control algorithm like 
GCC/NADA/SCReAM. That is also less desirable than just getting the 
bandwidth estimation from a congestion controller that runs at the QUIC 
layer, but this subsection is specifically about the case where that 
information is not available from the QUIC implementation.

> 
> On Mon, Oct 16, 2023 at 11:07 AM Bernard Aboba <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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] <mailto:[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] <mailto:[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
>             <https://github.com/mengelbart/rtp-over-quic-draft/issues/128>
>             Pull Request:
>             https://github.com/mengelbart/rtp-over-quic-draft/pull/134
>             <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 <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/135>
>             https://github.com/mengelbart/rtp-over-quic-draft/issues/141
>             <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 <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 <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
>             <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 <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 <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
>             <https://www.rfc-editor.org/rfc/rfc8698>>] and
>              >     Self-Clocked Rate Adaptation for Multimedia (SCReAM)
>             [RFC8298
>              >     <https://www.rfc-editor.org/rfc/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 <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 <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
>             <https://www.rfc-editor.org/rfc/rfc8298>>] and NADA
>              >     [RFC8698 <https://www.rfc-editor.org/rfc/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
>             <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 <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 <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 <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 <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 <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 <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
>             <https://www.rfc-editor.org/rfc/rfc8298>>] and NADA [RFC8698
>              >     <https://www.rfc-editor.org/rfc/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 <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 <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-alvestrand-rmcat-remb-03>>].¶ <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-6.1-5 <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 <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 <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 <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 <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-3-3>>
>              >
>              >
>              > ¶
>              >
>             <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-05#section-1.2.3-2 <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] <mailto:[e-mail]>
>              > https://www.ietf.org/mailman/listinfo/avt
>             <https://www.ietf.org/mailman/listinfo/avt>
>