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

[Mathis Engelbart <[e-mail]>]

Thanks, I updated the pull request with your proposal.

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