From 7603ce061b328caf0399de955bb74ec062870bba Mon Sep 17 00:00:00 2001 From: Mathis Engelbart Date: Tue, 10 Oct 2023 13:13:16 +0200 Subject: [PATCH] Clarify congestion and rate control --- draft-ietf-avtcore-rtp-over-quic.md | 191 ++++++++++++++-------------- 1 file changed, 99 insertions(+), 92 deletions(-) diff --git a/draft-ietf-avtcore-rtp-over-quic.md b/draft-ietf-avtcore-rtp-over-quic.md index f2977da..08e815f 100644 --- a/draft-ietf-avtcore-rtp-over-quic.md +++ b/draft-ietf-avtcore-rtp-over-quic.md @@ -213,6 +213,11 @@ when, and only when, they appear in all capitals, as shown here. The following terms are used: +Bandwidth Estimation: +: An algorithm to estimate the available bandwidth of a link in a network. Such +an estimation can be used for rate adaptation, i.e., adapt the rate at which an +application transmits data. + Congestion Control: : A mechanism to limit the aggregate amount of data that has been sent over a path to a receiver, but has not been acknowledged by the receiver. This prevents @@ -245,14 +250,14 @@ QUIC congestion controller: : A software component of an application's QUIC implementation that implements a congestion control algorithm. Rate Adaptation: -: 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. +: 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 +queues to build beyond a reasonable amount, causing *buffer bloat* and *jitter*. +Rate adaptation is one way to respond to send 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. Receiver: : An endpoint that receives media in RTP packets and may send or receive RTCP packets. @@ -711,111 +716,112 @@ CONNECTION\_CLOSE frame with one of the error codes defined in # Congestion Control and Rate Adaptation {#congestion-control} 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. +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. -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}}. - -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 -{{cc-quic-layer}}, or within an RTP application layer, as described in -{{cc-application-layer}}, but this document does not mandate any specific -congestion control or rate adaptation algorithm for either QUIC or RTP. - -This document also gives guidance about avoiding problems with "nested" -congestion controllers, in {{nested-CC}}. - -This document also discusses congestion control -implications of using shared or multiple separate QUIC connections to send and -receive multiple independent data streams, in {{shared-connections}}. +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. -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. +This document also gives guidance about avoiding problems with *nested* +congestion controllers in {{nested-CC}}. + +{{shared-connections}} discusses congestion control implications of using shared +or multiple separate QUIC connections to send and receive multiple independent +data streams. ## Congestion Control at the Transport Layer {#cc-quic-layer} -QUIC is a congestion controlled transport protocol. Senders are required to +QUIC is a congestion-controlled transport protocol. Senders are required to employ some form of congestion control. The default congestion control specified for QUIC in {{!RFC9002}} is similar to TCP NewReno {{?RFC6582}}, but senders are free to choose any congestion control algorithm as long as they follow the guidelines specified in {{Section 3 of ?RFC8085}}, and QUIC implementors make use of this freedom. -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 {{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. - -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. - -Many low latency congestion control algorithms depend on detailed arrival time -feedback to estimate the current one-way delay between sender and receiver. QUIC -does not provide arrival timestamps in its acknowledgments. The QUIC -implementations of the sender and receiver can use an extension to add this -information to QUICs acknowledgment frames, e.g. -{{!I-D.draft-smith-quic-receive-ts}} or {{!I-D.draft-huitema-quic-ts}}. - -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 -{{cc-application-layer}} or a receiver can feedback the observed bandwidth -through RTCP, e.g., using {{?I-D.draft-alvestrand-rmcat-remb}}. - -## Congestion Control at the RTP Application Layer {#cc-application-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. + +A wide variety of congestion control 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 (SCReAM {{?RFC8298}} and NADA {{?RFC8698}}). These 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}}. Some of these low latency congestion control +algorithms depend on detailed arrival time feedback to estimate the current +one-way delay between sender and receiver, which is unavailable in QUIC. The +QUIC implementations of the sender and receiver can use an extension to add this +information to QUICs as described in {{optional-extensions}}. An alternative to +these dedicated real-time media congestion-control algorithms that QUIC +implementations could support without the need for a protocol extension is the +Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service +{{?RFC9330}}. + +The application needs a mechanism to query the available bandwidth to adapt +media codec configurations. If the employed congestion controller of the QUIC +connection keeps an estimate of the available bandwidth, it could expose an API +to the application to query the current estimate. If the congestion controller +cannot provide a current bandwidth estimate to the application, the sender can +implement an alternative bandwidth estimation at the application layer as +described in {{rate-adaptation-application-layer}}. + +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, and QUIC recommends pacing for senders +based on the congestion control algorithm. + +## Rate Adaptation at the Application Layer {#rate-adaptation-application-layer} RTP itself does not specify a congestion control algorithm, but {{!RFC8888}} defines an RTCP feedback message intended to enable rate adaptation for interactive real-time traffic using RTP, and successful rate adaptation will accomplish congestion control as well. -The rate adaptation algorithms for RTP are specifically tailored for real-time -transmissions at low latencies, as described in {{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. - -If an application cannot access a bandwidth estimation from the QUIC layer, or -the QUIC implementation does not support a delay-based, low-latency congestion -control algorithm, the application can alternatively implement a bandwidth estimation -algorithm at the application layer. Calculating a bandwidth estimation at the -application layer can be done using the same bandwidth estimation algorithms as -described in {{congestion-control}} (NADA, SCReAM). The bandwidth estimation -algorithm typically needs some feedback on the transmission performance. This -feedback can be collected following the guidelines in {{rtcp-mapping}}. +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. + +If the application transmits 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 it's sending rate, drastic measures will be +required to avoid sustained or oscillating congestion along the path. + +Thus, applications are advised to only use the bandwidth estimation without +running the complete congestion control algorithm at the application layer +before passing data to the QUIC layer. + +The bandwidth estimation algorithm typically needs some feedback on the +transmission performance. This feedback can be collected via RTCP or following +the guidelines in {{rtcp-mapping}} and {{api-considerations}}. ## Resolving Interactions Between QUIC and Application-layer Congestion Control {#nested-CC} 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 {{cc-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. +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. - **Application-limited Media Flows** - if an application chooses RTP as its transport mechanism, the goal will be maximizing the user experience, not @@ -853,6 +859,7 @@ other non-real-time data. This can be realized in different ways. disadvantage that transport ports are more quickly exhausted and these are limited by the 16-bit UDP source and destination port number sizes {{!RFC768}}. + - Alternatively, all real-time channels are mapped to one QUIC connection, while a separate QUIC connection is created for the non-real-time channels. @@ -1287,7 +1294,7 @@ This document establishes a registry for RoQ error codes. --- back -# List of optional QUIC Extensions +# List of optional QUIC Extensions {#optional-extensions} The following is a list of QUIC protocol extensions that might be beneficial for RoQ, but are not required by RoQ.