From nobody Sun Sep 24 14:48:25 2023 Return-Path: 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 26AA8C14CE31 for ; Sun, 24 Sep 2023 14:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.897 X-Spam-Level: ** X-Spam-Status: No, score=2.897 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, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5klHFdPbr6Sg for ; Sun, 24 Sep 2023 14:48:20 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20420C14CE27 for ; Sun, 24 Sep 2023 14:48:20 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2c131ddfc95so75359451fa.0 for ; Sun, 24 Sep 2023 14:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695592097; x=1696196897; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LdAoBX3YKRUxyV8u5xNJI7I3gP4skPcK8XVTJtHLmVE=; b=WCvSxfu2mxqQ+cQvxhln8DIoKEUei5mFfbgd1NTdFVRrXInp0PfBs0NhjnvQ/BXP90 aCkWhyqvyA0vZs6e2osiIqNsyfoZ2yTdZtKLWeYw323DyMUcPsmNRN2ykiR0HU8ulydb tnqTuMJFLxDbItxVxYL3RVct7DqhX6MC0eBKsjAADZdzL0VEenR1LVPMUCF4MzBmLJtp Ktxrx0NdO47OUN3+Cp+vqqCONLBR9ejFqE3e4Zgzz8ZCgM1i6mEcEX4xByfSSBRc2QxI Wd51VkXcZeuXl9cij+XpCoTSB3DaA/9Ub+9HVbK+SlOdS21uEeZg6Y4xoFLBpslSMKEt 7Zrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695592097; x=1696196897; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LdAoBX3YKRUxyV8u5xNJI7I3gP4skPcK8XVTJtHLmVE=; b=T5ntSPqHq9w4WdmODm+QcMLiyO7KKZjeGx3Y0UyhVMl+TVgfp0A4+lBFC1dqMGuXRS AFpyAS/qtFn7+fL5Q5Z/V5zLruTxfkyObBeEODCZlkHFk4CzoKGaKwFu108+TF6Glgnl MXPU/7yT4S0eF7lx5SJRe9bhlxN7jhrL+trSY7lN4D1J6v+RmGDq8lZYfTGvRHD6XehZ Lz+RItu3zZVrzRoLpgcV82y7xK+QgHLbMPHXBZVjnvFvuU67oLXROWLWHkMCeUHK8wiO nGVz5W5FEzSF5eGcAzpkA1PgAFxZPsCyNEmz5HDBzrLh2hacSdnBOgsDsE3Bdx6JjxXp dOgg== X-Gm-Message-State: AOJu0YypN/ArTJpw6V07XzqGq3le0WfMEij6+vrEh1zd6XvfcLYHdScg XenLtKfj9B+qif7FUeuh9i18aX0w22TEpuRnlNJ5zAf9s18= X-Google-Smtp-Source: AGHT+IFFMsQo/rLzXqW1eDRAsGPL+P3nw2rEjSKCu1ShZ2gmQNs49C7mxdvINK2BBxa3+LF+X3MttD4hQezgk97upEE= X-Received: by 2002:a2e:964d:0:b0:2bf:f9b3:d335 with SMTP id z13-20020a2e964d000000b002bff9b3d335mr4191546ljh.15.1695592096339; Sun, 24 Sep 2023 14:48:16 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Sun, 24 Sep 2023 14:48:02 -0700 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="000000000000961e96060621cce7" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2023 21:48:24 -0000 --000000000000961e96060621cce7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.=C2=B6 [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 , 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 ], 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.=C2=B6 [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.=C2=B6 [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 ] and Self-Clocked Rate Adaptation for Multimedia (SCReAM) [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.=C2=B6 [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 ]). The IETF has defined two algorithms in two Experimental RFCs (e.g. SCReAM [RFC8298 ] and NADA [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 ]. [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 , or within an RTP application layer, as described in Section 6.2 , but this document does not mandate any specific congestion control or rate adaptation algorithm for either QUIC or RTP.=C2=B6 [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. [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 , 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= . =C2=B6 [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 ] and NADA [RFC8698 ] algorithms.=C2=B6 [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 in Section 6.2 or a receiver can feedback the observed bandwidth through RTCP, e.g., usin= g [I-D.draft-alvestrand-rmcat-remb ].=C2= =B6 [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 . 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.=C2=B6 [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 , 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, no= t 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 pl= ay. 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.=C2=B6 [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. =C2=B6 =C2=B6 --000000000000961e96060621cce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looking over the coverage Congestion Control and Rate Cont= rol, the two topics appear to be conflated and also there appear to be some= issues that have not been fully considered.=C2=A0

Secti= on=C2=A01.2.2

While the effect of QUIC's response to con= gestion 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 "ceasin= g transmission" completely until the RTP sender has a reason to believ= e that restarting the flow will not result in congestion.=C2=B6

[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.=C2=A0 So saying QUIC congestion=C2=A0control = is "preferable" seems questionable.=C2=A0

Moreover, when a single QUIC connection is used to multiplex both RTP-RTC= P and non-RTP packets as described in=C2=A0Secti= on 1.2.5, the QUIC connection will still be Internet-safe, with no coor= dination required.

[BA] While it may be "Inte= rnet-safe", delays in RTCP feedback are likely to destabilize rate con= trol as well as resulting in challenges to A/V sync.=C2=A0 So not sure that= "Internet-safe" is the only important metric here.=C2=A0

Section 1.2.3

=

One word of caution is in order - RTP implem= entations may rely on at least some minimal periodic RTCP feedback, in orde= r to determine that an RTP flow is still active, and is not causing sustain= ed congestion (as described in=C2=A0[RFC8083], but since this "periodicit= y" is measured in seconds, the impact of this "duplicate" fe= edback 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 traf= fic.=C2=A0 Note also that similar considerations apply to treatment of audi= o vs. video. Serious problems with a/v sync are possible (or even likely) u= nder congestion.=C2=A0

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 al= lows QUIC receivers to piggyback QUIC ACK frames on any QUIC frames being t= ransmitted in the other direction.=C2=B6

[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 audi= o/video sync issues without having to resort to other techniques such as pr= ioritization.=C2=A0 Is this something that deserves more discussion?=C2=A0<= /p>

Section 2

Rate control:= =C2=A0

A congest= ion 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 rece= iver, without causing queues to build beyond a reasonable amount, causing &= quot;buffer bloat" and "jitter". Rate adapation is one way t= o accomplish congestion control for real-time media, especially when a send= er has multiple media streams to the receiver, because the sum of all sendi= ng rates for media streams must not be high enough to cause congestion on t= he path these media streams share between sender and receiver.=C2= =B6

[BA] Rate= control and congestion control are distinct. So the definition here doesn&= #39;t seem right, particularly for RoQ where congestion control is built in= to QUIC while rate adaptation is application and even codec-specific.=C2=A0=


Overall, a bette= r way to think of the distinction is that QUIC congestion control limits th= e 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 los= s.=C2=A0

But sinc= e congestion control and rate control are distinct and are handled at diffe= rent layers, rate control is not "one way to accomplish congestion con= trol" but rather "one way to respond to send rate limitations imp= osed 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 manda= te any specific rate adaptation algorithm, because the desired response to = congestion can be application and codec-specific. For example, adjusting qu= antization in response to congestion may work well in many cases, but if wh= at'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).=C2=A0=C2=A0


As of this writing, the IETF has produced two Ex= perimental-track rate adaptation specifications, Network-Assisted Dynamic A= daptation (NADA)=C2=A0[RFC8698]=C2=A0and Self-Clocked Rate A= daptation for Multimedia (SCReAM)=C2=A0[RFC8298]. These rate = adaptation algorithms require some feedback about the network's perform= ance 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 &q= uot;rate adaptation algorithms"?=C2=A0 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 the= refore they do not provide application and codec-specific rate control mech= anisms.=C2=A0


Sec= tion 6=C2=A0


Like any other application on the internet, RoQ applications n= eed a mechanism to perform congestion control to avoid overloading the netw= ork. While any generic congestion controller can protect the network, this = document takes advantage of the opportunity to use rate adaptation mechanis= ms that are designed to provide superior user experiences for real-time med= ia applications.=C2=B6

[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 c= ongestion control.=C2=A0

Since earlier it was stated that there is no= normative guidance on rate control, how can "this document take advan= tage of the opportunity to use rate adaptation mechanisms that are designed= to provide superior user experiences"?=C2=A0

A wide variety of = rate adaptation algorithms for real-time media have been developed (for exa= mple, "Google Congestion Controller"=C2=A0[I-D.draft-ietf-rmcat-gcc]). The IETF has defined two algorit= hms in two Experimental RFCs (e.g. SCReAM=C2=A0[RFC8298]=C2= =A0and NADA=C2=A0[RFC8698]). These rate adaptation algorithms= for RTP are specifically tailored for real-time transmissions at low laten= cies, but this section would apply to any rate adaptation algorithm that me= ets the requirements described in "Congestion Control Requirements for= Interactive Real-Time Media"=C2=A0[RFC8836].


=

[BA] As noted earlier, these are not rate control algorithms (e.g. p= er-frame QP), they are congestion control algorithms.


This= document defines two architectures for congestion control and bandwidth es= timation for RoQ, depending on whether most rate adaptation is performed wi= thin a QUIC implementation at the transport layer, as described in=C2=A0Section 6.1, or within an RTP application la= yer, as described in=C2=A0Section 6.2, but this document does not mandate any specific congestion control or r= ate adaptation algorithm for either QUIC or RTP.=C2=B6

[BA] QU= IC implementations cannot implement rate control, because as you state earl= ier, that is application and/or codec-specific. So again you seem to be con= flating congestion control and rate control.=C2=A0

It is assumed that the congestion c= ontroller in use provides a pacing mechanism to determine when a packet can= be sent to avoid bursts. The currently proposed congestion control algorit= hms for real-time communications (e.g. SCReAM and NADA) provide such pacing= mechanisms. The use of congestion controllers which don't provide a pa= cing mechanism is out of scope of this document.

[= BA] In this paragraph you correctly refer to SCReaM and NADA as congestion = control algorithms. Please use this terminology consistently.=C2=A0

Section 6.1

If a QUIC implementation is to perfor= m rate adaptation in a way that accommodates real-time media, one way for t= he 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 "T= LS Application-Layer Protocol Negotiation (ALPN) Protocol ID", as desc= ribed in=C2=A0Section 4, that a QUIC implementation= can use as a signal to choose a real-time media-centric rate controller, b= ut this is not required for ROQ deployments.=C2=B6

[BA] A= gain, QUIC implementations do not perform rate adaptation. That is an appli= cation layer function. I think you mean "perform congestion control&qu= ot; here.=C2=A0

However, congestion control is orthogonal to the us= e of an ALPN, so mixing these two concepts is problematic.=C2=A0

If= congestion control is to be applied at the transport layer, it is RECOMMEN= DED that the QUIC Implementation uses a congestion controller that keeps qu= eueing delays short to keep the transmission latency for RTP and RTCP packe= ts as low as possible, such as the IETF-defined SCReAM=C2=A0[RFC8298= ]=C2=A0and NADA=C2=A0[RFC8698]=C2=A0algorithms.= =C2=B6

<= p id=3D"gmail-section-6.1-3" style=3D"box-sizing:border-box;margin-right:0p= x;margin-left:3ch">[BA] You might also mention L4S here. This seems more li= kely to be supported with QUIC than the algorithms you mention in the draft= .=C2=A0

If = congestion control is done by the QUIC implementation, the application need= s a mechanism to query the currently available bandwidth to adapt media cod= ec configurations. The employed congestion controller of the QUIC connectio= n SHOULD expose such an API to the application. If a current bandwidth esti= mate is not available from the QUIC congestion controller, the sender can e= ither implement an alternative bandwidth estimation at the application laye= r as described in=C2=A0Section 6.2=C2=A0or a receiver can feedback the observed bandwidth through RTCP, e.g., us= ing=C2=A0[I-D.draft-alvestrand-rmcat-remb].=C2=B6=

<= p id=3D"gmail-section-6.1-5" style=3D"box-sizing:border-box;margin-right:0p= x;margin-left:3ch">[BA] This paragraph is good, since it describes how the = QUIC implementation provides info to the application, to be used in rate co= ntrol. I think you need to be more clear about the relationship throughout = the document. But the normative language is problematic because this docume= nt cannot have normative API dependencies. Also, you need to be careful wit= h references to drafts which will not be published as RFCs, particularly RE= MB which has been deprecated in favor of transport CC.=C2=A0


Section 6.2

The rate adaptation algorithms for RTP are speci= fically tailored for real-time transmissions at low latencies, as described= in=C2=A0Section 6. The available rat= e adaptation algorithms expose a=C2=A0target_bitrate=C2=A0th= at 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.= =C2=B6

[BA] Again, there is a conflation of rate adaptation= and congestion control. In this paragraph "congestion control algorit= hms" should be used instead of "rate control algorithms".=C2= =A0

Section 6.3

Because QUIC is a congestion-controlled tra= nsport, as described in=C2=A0Section 6.1, = and RTP applications can also perform congestion control and rate adaptatio= n,=C2=A0

[BA] Since congestion control is built into QUIC, RoQ = applications can only do rate control, not congestion control.=C2=A0

  • Application-limited Media Flows=C2=A0- if an application cho= oses RTP as its transport mechanism, the goal will be maximizing the user e= xperience, not maximizing path bandwidth utilization. If the application is= , in fact, transmitting media that does not saturate path bandwidth, and pa= ces its transmission, more heavy-handed congestion control mechanisms (dras= tic 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 sat= urate the path bandwidth, and does not adapt its own sending rate, drastic = measures will be required in order to avoid sustained or oscillating conges= tion along the path.=C2=B6

[BA] This document pr= obably isn't the right place to discuss this, but it is a very big issu= e that has limited the deployment of the algorithms produced by RMCAT, beca= use probing was supported by gcc and not in the NADA, SCreAM, etc. In pract= ice, 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.=C2=A0


=C2=B6=C2=A0


=C2=B6