Improve congestion control and rate adaptation in motivation section (#…

…146)

* Improve congestion control  and rate adaptation in motivation section

Also adding explanation of the use of congestion control and rate adaptation terms in this document.

* Apply comments from @aboba and @mengelbart

* Remove trailing whitespace (d'oh!)

* resolve xref issue

draft-ietf-avtcore-rtp-over-quic.md

@@ -33,10 +33,15 @@ author:
 informative:
 
   3GPP-TS-26.114:
-    target: (https://portal.3gpp.org/desktopmodules/Specifications/specificationId=1404)
+    target: https://portal.3gpp.org/desktopmodules/Specifications/specificationId=1404
     title: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction"
     date: 2023-01-05
 
+  VJMK88:
+    target: https://ee.lbl.gov/papers/congavoid.pdf
+    title: "Congestion Avoidance and Control"
+    date: November 1988
+
 --- abstract
 
 This document specifies a minimal mapping for encapsulating Real-time Transport
@@ -94,13 +99,21 @@ This is in sharp contrast to "always-on" transport-level encryption in the QUIC
 
 When RTP is carried directly over UDP, as is commonly done, the underlying UDP protocol provides no transport services beyond path multiplexing using UDP ports. All congestion avoidance behavior is up to the RTP application itself, and if anything goes wrong with the application resulting in an RTP sender failing to recognize that it is contributing to path congestion, the "worst case" response is to invoke RTP "circuit breaker" procedures {{?RFC8083}}, resulting in "ceasing transmission", as described in {{Section 4.5 of ?RFC8083}}. Because RTCP-based circuit breakers only detect long-lived congestion, a response based on these mechanisms will not happen quickly.
 
-In contrast, when RTP is carried over QUIC, QUIC implementations maintain their own estimates of key transport parameters needed to detect and respond to possible congestion, and these are independent of any measurements RTP senders and receivers are maintaining. The result is that even if an RTP sender continues to "send", QUIC congestion avoidance procedures (for example, the procedures defined in {{?RFC9002}}) will cause the RTP packets to be buffered and only placed on the network path as part of a response to detected loss. This happens without any action being requied on the part of RTP senders.
+In contrast, when RTP is carried over QUIC, QUIC implementations maintain their own estimates of key transport parameters needed to detect and respond to possible congestion, and these are independent of any measurements RTP senders and receivers are maintaining. The result is that even if an RTP sender continues to "send", QUIC congestion avoidance procedures (for example, the procedures defined in {{?RFC9002}}) will cause the RTP packets to be buffered while QUIC responds to detected packet loss. This happens without RTP senders taking any action, but the RTP sender has no control over this QUIC mechanism.
+
+Moreover, when a single QUIC connection is used to multiplex both RTP-RTCP and non-RTP packets as described in {{single-path}}, the shared QUIC connection will still be Internet-safe, with no coordination required.
+
+While QUIC's response to congestion ensures that RoQ will be "Internet-safe", from the network's perspective, it is helpful to remember that a QUIC sender responds to detected congestion by delaying packets that are already available to send, to give the path to the QUIC receiver time to recover from congestion.
+
+* If the QUIC connection encapsulates RTP, this means that some RTP packets will be delayed, and will arrive at the receiver later than a user of the RTP flow might prefer.
+* If the QUIC connection also encapsulates RTCP, this means that these RTCP messages will also be delayed, and will not be sent in a timely manner. This delay can interfere with a sender's ability to stabilize rate control and achieve audio/video synchronization.
 
-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.
+Taken as a whole,
 
-Moreover, when a single QUIC connection is used to multiplex both RTP-RTCP and non-RTP packets as described in {{single-path}}, the QUIC connection will still be Internet-safe, with no coordination required.
+* Timely RTP stream-level rate adaptation will give a better user experience by minimizing endpoint queuing delays and packet loss,
+* but in the presence of packet loss, QUIC connection-level congestion control will respond more quickly to the end of congestion than RTP "circuit breakers".
 
-### Rate Adaptation Based on QUIC Feedback {#ra-quic-feedback}
+### RTP Rate Adaptation Based on QUIC Feedback {#ra-quic-feedback}
 
 RTP makes use of a large number of RTP-specific feedback mechanisms because when RTP is carried directly over UDP, there is no other way to receive feedback. Some of these mechanisms are specific to the type of media RTP is sending, but others can be mapped from underlying QUIC implementations that are using this feedback to perform rate adaptation for any QUIC connection, regardless of the application reflected in the QUIC STREAM {{?RFC9000}} and DATAGRAM {{?RFC9221}} frames. This is described in (much) more detail in {{congestion-control}} on rate adaptation, and in {{rtcp-mapping}} on replacing RTCP and RTP header extensions with QUIC feedback.
 
@@ -214,6 +227,14 @@ when, and only when, they appear in all capitals, as shown here.
 
 > **Editor's note:** the list of terms below will almost certainly grow in size as the specification matures.
 
+> **Note to the Reader:** the meaning of the terms "congestion control" and "rate adaptation" in the IETF community have evolved over the decades since "slow start" and "congestion avoidance" were added as mandatory to implement in TCP, in {{Section 4.2.2.15 of ?RFC1122}}. At that time, "congestion control" usually referred to "achieving network stability" ({{VJMK88}}), by protecting the network from senders who continue to transmit packets that exceed the ability of the network to carry them, even after packet loss occurs (called "congestion collapse").
+
+> "Rate adaptation" more commonly referred to strategies intended to guide senders on when to send "the next packet", so that one-way delays along the network path remain minimal.
+
+> As more and more general-purpose "congestion control" algorithms focused on avoiding "bufferbloat", as described in {{rate-adaptation-application-layer}}, the difference between "congestion control" and "rate adaptation" has blurred in IETF community discussions.
+
+> In this document, these terms are used with the meanings listed below, with the recognition that not all the references in this document use these terms in the same way.
+
 The following terms are used:
 
 Bandwidth Estimation: