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

[Mathis Engelbart <[e-mail]>]

Hi, see comments below:

On 10/16/23 20:07, Bernard Aboba 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.

[ME] This was intended as a general introduction, explaining what the 
specifications of QUIC and RTP say about congestion control. What do you 
think about the following text instead:

"Like any other application on the internet, RoQ needs to perform 
congestion control to avoid overloading the network. QUIC is a 
congestion-controlled transport protocol. {{!RFC9002}} describes the 
congestion control mechanisms for QUIC using a default congestion 
control algorithm. RTP congestion control considerations are given in 
{{Section 10 of !RFC3550}}, which does not mandate a single congestion 
control mechanism but suggests that the RTP profile defines congestion 
control according to the expected properties of the application's 
environment. Some coordination is required to avoid undesired 
consequences of running two congestion control algorithms at different 
layers of the protocol stack."


> 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.

[ME] I updated the pull request with this text:

"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 algorithms."

> 
> 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>
>