Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: Congestion Control and Rate Control
Mathis Engelbart <mathis.engelbart@tum.de> Tue, 17 October 2023 10:43 UTC
Return-Path: <mathis.engelbart@tum.de>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A46BC151551 for <avt@ietfa.amsl.com>; Tue, 17 Oct 2023 03:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M3TUZvhnrsU for <avt@ietfa.amsl.com>; Tue, 17 Oct 2023 03:43:38 -0700 (PDT)
Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7776C14CEFF for <avt@ietf.org>; Tue, 17 Oct 2023 03:43:37 -0700 (PDT)
Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 4S8rDl6mp9zyV0; Tue, 17 Oct 2023 12:43:35 +0200 (CEST)
Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=tu-postout21; t=1697539414; bh=GsYGjc2mtEeZkIjBrQ35GcDgXmlNXr br4rgvN1sWByo=; b=dOVmVsfsNVzllbxINfzUhdg161NpS4ztDalSRZC1z6fx+c xoCWdNvQ2ojn2Myt08Q8vHbOmDbLCynhDg+CBjsR1RZu8UDfSziM8lMGhx7muxVe DBjfiigbFu9pcxxCI5u2ustvb8iDY0ES9NBQZEL5nZoTvD1aRgoVSucYq41y7K69 24vkOpwXJdBQVGJlHMzHdJQa2yOM0CANbeNfHr+LmiMuKiq6haB4+o36tadAoQTQ bEeL9UVla22pM93MHzULyCT12nGQGdZHJGs87gWK8Egqr3ziRX1RObHqw+UCpfev MNvceev2n3C+49qXwiP+bIzdxWrmPCAGcCejT4Hg==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de
Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id wZLHwbH7dsE5; Tue, 17 Oct 2023 12:43:34 +0200 (CEST)
Received: from [IPV6:2003:ed:a70f:500b:9ede:8f79:91ff:be78] (p200300eda70f500b9ede8f7991ffbe78.dip0.t-ipconnect.de [IPv6:2003:ed:a70f:500b:9ede:8f79:91ff:be78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPSA id 4S8rDk1F0CzySl; Tue, 17 Oct 2023 12:43:34 +0200 (CEST)
Message-ID: <21617795-8a3c-dc6f-f48b-413dd96736e0@tum.de>
Date: Tue, 17 Oct 2023 12:43:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
References: <CAOW+2dvncSX52BvkbCdpXR8tOMq950XKEu18ZmPF3dGJt+3D+Q@mail.gmail.com> <dbcd27a7-065d-2b60-b78e-40b4df0c153a@tum.de> <CAOW+2dvbvgjW-SH=ob+B2wExxBYok+qeS5e_WR72YDE5sc0ynA@mail.gmail.com> <CAOW+2dtXJNRn4o6Gbba6j+YaJ3KYu6cYUzpQLYR4os4NYNLFZA@mail.gmail.com> <CAOW+2dtJv-DY+aSZ2Hu6GasvcSG8ubMr3RhJOm6_9ZhAQ5eOnw@mail.gmail.com> <CAOW+2dsJmgxt2axJ3N3BPLT3EC21CLOc_FjEJi6vjUZBs4+CiQ@mail.gmail.com>
From: Mathis Engelbart <mathis.engelbart@tum.de>
In-Reply-To: <CAOW+2dsJmgxt2axJ3N3BPLT3EC21CLOc_FjEJi6vjUZBs4+CiQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/KrkfPr1Ux4hL-fOTkEaBNYbRUnc>
Subject: Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: Congestion Control and Rate Control
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2023 10:43:43 -0000
On 10/16/23 20:29, Bernard Aboba wrote:
> Because QUIC is a congestion-controlled transport, as described in
> {{cc-quic-layer}}, and RTP applications can also perform congestion
> control and
> rate adaptation, as described in {{rate-adaptation-application-layer}},
> implementers should be aware of the possibility that these "nested"
> congestion
> control loops, where both controllers are managing rate adaptation for
> the same
> packet stream independently, may deliver problematic performance.
> Because this
> document is describing a specific case (media transport), we can provide
> some
> guidance to avoid the worst possible problems.
>
> [BA] As noted earlier, in RoQ RTP does not perform congestion control,
> only rate adaptation.
> Congestion control is handled at the QUIC layer. So this paragraph is
> confusing.
[ME] Sorry, I made a mistake here. I planned to remove the whole
subsection because the main points from here are now moved to the
previous subsection. Does that make sense?
>
> On Mon, Oct 16, 2023 at 11:27 AM Bernard Aboba <bernard.aboba@gmail.com
> <mailto:bernard.aboba@gmail.com>> 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.
>
> 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."
>
>
> On Mon, Oct 16, 2023 at 11:07 AM Bernard Aboba
> <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> 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
> <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> 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
> <mathis.engelbart@tum.de <mailto:mathis.engelbart@tum.de>>
> 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
> > avt@ietf.org <mailto:avt@ietf.org>
> > https://www.ietf.org/mailman/listinfo/avt
> <https://www.ietf.org/mailman/listinfo/avt>
>
- [AVTCORE] draft-ietf-avtcore-rtp-over-quic: Conge… Bernard Aboba
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Mathis Engelbart
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Bernard Aboba
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Bernard Aboba
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Bernard Aboba
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Bernard Aboba
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Mathis Engelbart
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Mathis Engelbart
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Mathis Engelbart
- Re: [AVTCORE] draft-ietf-avtcore-rtp-over-quic: C… Mathis Engelbart