From 2495e69c3a74c19d1dfb6a3e5d2e59dbeefc778e Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 29 Feb 2024 10:17:57 +0000 Subject: [PATCH] Script updating gh-pages from 362803a. [ci skip] --- draft-ietf-avtcore-rtp-over-quic.html | 46 +- draft-ietf-avtcore-rtp-over-quic.txt | 14 +- .../draft-ietf-avtcore-rtp-over-quic.html | 4611 ----------------- .../draft-ietf-avtcore-rtp-over-quic.txt | 2825 ---------- fix-missing-bracket/index.html | 46 - index.html | 16 - .../draft-ietf-avtcore-rtp-over-quic.html | 4605 ---------------- .../draft-ietf-avtcore-rtp-over-quic.txt | 2821 ---------- remove-media-encoder-terminology/index.html | 46 - 9 files changed, 19 insertions(+), 15011 deletions(-) delete mode 100644 fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.html delete mode 100644 fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.txt delete mode 100644 fix-missing-bracket/index.html delete mode 100644 remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.html delete mode 100644 remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.txt delete mode 100644 remove-media-encoder-terminology/index.html diff --git a/draft-ietf-avtcore-rtp-over-quic.html b/draft-ietf-avtcore-rtp-over-quic.html index 7098ba4..c15ccca 100644 --- a/draft-ietf-avtcore-rtp-over-quic.html +++ b/draft-ietf-avtcore-rtp-over-quic.html @@ -657,7 +657,7 @@ } #toc nav li { line-height: 1.3em; - margin: 0.75em 0; + margin: 2px 0; padding-left: 1.2em; text-indent: -1.2em; } @@ -750,7 +750,7 @@ z-index: 2; top: 0; right: 0; - padding: 0; + padding: 1px 0 0 0; margin: 0; border-bottom: 1px solid #ccc; opacity: 0.6; @@ -874,16 +874,13 @@ border-top: none; padding-top: 0; } - figure, pre { + figure, pre, .vcard { page-break-inside: avoid; } - figure { - overflow: scroll; - } h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } - h2+*, h3+*, h4+*, h5+*, h6+* { + :is(h2, h3, h4, h5, h6)+*, dd { page-break-before: avoid; } pre { @@ -897,6 +894,9 @@ td { border-top: 1px solid #ddd; } + .toplink { + display: none; + } } @page :first { @@ -997,28 +997,6 @@ text-align: right; } -/* Give the table caption label the same styling as the figcaption */ - -@media print { - .toplink { - display: none; - } - - /* avoid overwriting the top border line with the ToC header */ - #toc { - padding-top: 1px; - } - - /* Avoid page breaks inside dl and author address entries */ - dd { - page-break-before: avoid; - } - .vcard { - page-break-inside: avoid; - } - -} - /* Dark mode. */ @media (prefers-color-scheme: dark) { :root { @@ -1059,7 +1037,7 @@ Ott, et al. -Expires 25 August 2024 +Expires 1 September 2024 [Page] @@ -1072,12 +1050,12 @@
draft-ietf-avtcore-rtp-over-quic-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1136,7 +1114,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 25 August 2024.

+ This Internet-Draft will expire on 1 September 2024.

[I-D.draft-ietf-rmcat-gcc]
diff --git a/draft-ietf-avtcore-rtp-over-quic.txt b/draft-ietf-avtcore-rtp-over-quic.txt index 549d601..f3c29e7 100644 --- a/draft-ietf-avtcore-rtp-over-quic.txt +++ b/draft-ietf-avtcore-rtp-over-quic.txt @@ -5,9 +5,9 @@ Audio/Video Transport Core Maintenance J. Ott Internet-Draft M. Engelbart Intended status: Standards Track Technical University Munich -Expires: 25 August 2024 S. Dawkins +Expires: 1 September 2024 S. Dawkins Tencent America LLC - 22 February 2024 + 29 February 2024 RTP over QUIC (RoQ) @@ -49,7 +49,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 25 August 2024. + This Internet-Draft will expire on 1 September 2024. Copyright Notice @@ -1916,11 +1916,11 @@ Table of Contents draft-ietf-quic-multipath-06>. [I-D.draft-ietf-quic-reliable-stream-reset] - Seemann, M. and K. Oku, "Reliable QUIC Stream Resets", - Work in Progress, Internet-Draft, draft-ietf-quic- - reliable-stream-reset-05, 23 January 2024, + Seemann, M. and K. Oku, "QUIC Stream Resets with Partial + Delivery", Work in Progress, Internet-Draft, draft-ietf- + quic-reliable-stream-reset-06, 28 February 2024, . + reliable-stream-reset-06>. [I-D.draft-ietf-rmcat-gcc] Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. diff --git a/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.html b/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.html deleted file mode 100644 index 8036cba..0000000 --- a/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.html +++ /dev/null @@ -1,4611 +0,0 @@ - - - - - - -RTP over QUIC (RoQ) - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftRTP over QUIC (RoQ)January 2024
Ott, et al.Expires 2 August 2024[Page]
-
-
-
-
Workgroup:
-
Audio/Video Transport Core Maintenance
-
Internet-Draft:
-
draft-ietf-avtcore-rtp-over-quic-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
J. Ott
-
Technical University Munich
-
-
-
M. Engelbart
-
Technical University Munich
-
-
-
S. Dawkins
-
Tencent America LLC
-
-
-
-
-

RTP over QUIC (RoQ)

-
-

Abstract

-

This document specifies a minimal mapping for encapsulating Real-time Transport -Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. -This mapping is called RTP over QUIC (RoQ). -It also discusses how to leverage state from the QUIC implementation in the -endpoints, in order to reduce the need to exchange RTCP packets and how to -implement congestion control and rate adaptation without relying on RTCP -feedback.

-
-
-

-Discussion Venues -

-

This note is to be removed before publishing as an RFC.

-

Discussion of this document takes place on the - Audio/Video Transport Core Maintenance Working Group mailing list (avt@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/avt/.

-

Source for this draft and an issue tracker can be found at - https://github.com/mengelbart/rtp-over-quic-draft.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 2 August 2024.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

This document specifies a minimal mapping for encapsulating Real-time Transport -Protocol (RTP) [RFC3550] and RTP Control Protocol (RTCP) [RFC3550] packets -within the QUIC protocol ([RFC9000]). -This mapping is called RTP over QUIC (RoQ). -It also discusses how to leverage state -from the QUIC implementation in the endpoints, in order to reduce the need to -exchange RTCP packets, and how to implement congestion control and rate -adaptation without relying on RTCP feedback.

-
-
-

-1.1. Background -

-

The Real-time Transport Protocol (RTP) [RFC3550] is generally used to carry -real-time media for conversational media sessions, such as video conferences, -across the Internet. Since RTP requires real-time delivery and is tolerant to -packet losses, the default underlying transport protocol has been UDP, recently -with DTLS on top to secure the media exchange and occasionally TCP (and possibly -TLS) as a fallback.

-

This specification describes an application usage of QUIC ([RFC9308]). -As a baseline, the specification does not expect more than a standard QUIC implementation -as defined in [RFC8999], [RFC9000], [RFC9001], and [RFC9002], -providing a secure end-to-end transport that is also expected to work well through NATs and firewalls. -Beyond this baseline, real-time applications can benefit from QUIC extensions such as unreliable QUIC datagrams -[RFC9221], which provides additional desirable properties for -real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line -blocking).

-
-
-
-
-

-1.2. Motivations -

-

From time to time, someone asks the reasonable question, "why should anyone implement and deploy RoQ"? This reasonable question deserves a better answer than "because we can". Upon reflection, the following motivations seem useful to state.

-

The motivations in this section are in no particular order, and this reflects the reality that not all implementers and deployers would agree on "the most important motivations".

-
-
-

-1.2.1. "Always-On" Transport-level Authentication and Encryption -

-

Although application-level mechanisms to encrypt RTP and RTCP payloads have existed since the introduction of Secure Real-time Transport Protocol (SRTP) [RFC3711], encryption of RTP and RTCP header fields and contributing sources has only been defined recently (in Cryptex [RFC9335], and both SRTP and Cryptex are optional capabilities for RTP.

-

This is in sharp contrast to "always-on" transport-level encryption in the QUIC protocol, using Transport Layer Security (TLS 1.3) as described in [RFC9001]. QUIC implementations always authenticate the entirety of each packet, and encrypt as much of each packet as is practical, even switching from "long headers", which expose more QUIC header fields needed to establish a connection, to "short headers", which only expose the absolute minimum QUIC header fields needed to identify the connection to the receiver, so that the QUIC payload is presented to the right QUIC application [RFC8999].

-
-
-
-
-

-1.2.2. "Always-On" Internet-Safe Congestion Avoidance -

-

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 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 Section 1.2.5, 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.

    -
    • -
-

Taken as a whole,

-
    -
  • -

    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".

    -
    • -
-
-
-
-
-

-1.2.3. RTP Rate Adaptation Based on 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 Section 7 on rate adaptation, and in Section 8 on replacing RTCP and RTP header extensions with QUIC feedback.

-

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.

-
-
-
-
-

-1.2.4. Path MTU Discovery and RTP Media Coalescence -

-

The minimum Path MTU supported by conformant QUIC implementations is 1200 bytes [RFC9000], and in addition, QUIC implementations allow senders to use either DPLPMTUD ([RFC8899]) or PMTUD ([RFC1191], [RFC8201]) to determine the actual MTU size that the receiver and path between sender and receiver support, which can be even larger.

-

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.

-
-
-
-
-

-1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC Connection -

-

In order to conserve ports, especially at NATs and Firewalls, this specification defines a flow identifier, so that multiple RTP flows, RTCP flows, and non-RTP flows can be distinguished even if they are carried on the same QUIC connection. This is described in more detail in Section 5.1.

-
-
-
-
-

-1.2.6. Exploiting Multiple Connections -

-

Although there is much interest in multiplexing flows on a single QUIC connection as described in Section 1.2.5, QUIC also provides the capability of establishing and validating multiple paths for a single QUIC connection [RFC9000]. Once multiple paths have been validated, a sender can migrate from one path to another with no additional signaling, allowing an endpoint to move from one endpoint address to another without interruption, as long as only a single path is in active use at any point in time.

-

Connection migration may be desireable for a number of reasons, but to give one example, this allows a sender to distinguish between more costly cellular paths and less costly WiFi paths, with no action required from the application.

-
-
-
-
-

-1.2.7. Exploiting New QUIC Capabilities -

-

In addition to connection migration as described in Section 1.2.6, the capability of validating multiple paths for simultaneous active use is under active development in the IETF [I-D.draft-ietf-quic-multipath]. We don't discuss Multipath QUIC further in this document, because the specification hasn't been approved yet, but it's one example of ways that RTP, a mature protocol, can exploit new transport capabilities as they become available.

-
-
-
-
-
-
-

-1.3. What's in Scope for this Specification -

-

This document defines a mapping for RTP and RTCP over QUIC, called RoQ, and describes ways to reduce the -amount of RTCP traffic by leveraging state information readily available within -a QUIC endpoint. This document also describes different options for implementing -congestion control and rate adaptation for RoQ.

-

This specification focuses on providing a secure encapsulation of RTP packets -for transmission over QUIC. The expected usage is wherever RTP is used to carry -media packets, allowing QUIC in place of other transport protocols such as TCP, -UDP, SCTP, DTLS, etc. That is, we expect RoQ to be used in contexts in -which a signaling protocol is used to announce or negotiate a media -encapsulation and the associated transport parameters (such as IP address, port -number). RoQ is not intended as a stand-alone media transport, -although QUIC transport parameters could be statically configured.

-

The above implies that RoQ is targeted at peer-to-peer operation; but -it may also be used in client-server-style settings, e.g., when talking to a -conference server as described in RFC 7667 ([RFC7667]), or, if RoQ -is used to replace RTSP ([RFC7826]), to a media server.

-

An appropriate 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 mechanism, so the application can use a rate adaption mechanism of its choice.

-

Moreover, this document describes how a QUIC implementation and its API can be -extended to improve efficiency of the RoQ protocol operation.

-

RoQ does not impact the usage of RTP Audio Video Profiles (AVP) -([RFC3551]), or any RTP-based mechanisms, even though it may render some of -them unnecessary, e.g., Secure Real-Time Transport Prococol (SRTP) -([RFC3711]) might not be needed, because end-to-end security is already -provided by QUIC, and double encryption by QUIC and by SRTP might have more -costs than benefits. Nor does RoQ limit the use of RTCP-based -mechanisms, even though some information or functions obtained by using RTCP -mechanisms may also be available from the underlying QUIC implementation by -other means.

-

Between two (or more) endpoints, RoQ supports multiplexing multiple -RTP-based media streams within a single QUIC connection and thus using a single -(destination IP address, destination port number, source IP address, source port -number, protocol) 5-tuple.. We note that multiple independent QUIC connections -may be established in parallel using the same destination IP address, -destination port number, source IP address, source port number, protocol) -5-tuple., e.g. to carry different media channels. These connections would be -logically independent of one another.

-
-
-
-
-

-1.4. What's Out of Scope for this Specification -

-

This document does not attempt to enhance QUIC for real-time media or define a -replacement for, or evolution of, RTP. Work to map other media transport -protocols to QUIC is under way elsewhere in the IETF.

-

RoQ is designed for use with point-to-point connections, because QUIC -itself is not defined for multicast operation. The scope of this document is -limited to unicast RTP/RTCP, even though nothing would or should prevent its use -in multicast setups once QUIC supports multicast.

-

RoQ does not define congestion control and rate adaptation algorithms -for use with media. However, Section 7 discusses options for how -congestion control and rate adaptation could be performed at the QUIC and/or at -the RTP layer, and how information available at the QUIC layer could be exposed -via an API for the benefit of RTP layer implementation.

-
    -
  • -

    Editor's note: Need to check whether Section 7 will also -describe the QUIC interface that's being exposed, or if that ends up somewhere -else in the document.

    -
    • -
-

RoQ does not define prioritization mechanisms when handling different -media as those would be dependent on the media themselves and their -relationships. Prioritization is left to the application using RoQ.

-

This document does not cover signaling for session setup. SDP for RoQ -is defined in separate documents such as -[I-D.draft-dawkins-avtcore-sdp-rtp-quic], and can be carried in any signaling -protocol that can carry SDP, including the Session Initiation Protocol (SIP) -([RFC3261]), Real-Time Protocols for Browser-Based Applications (RTCWeb) -([RFC8825]), or WebRTC-HTTP Ingestion Protocol (WHIP) -([I-D.draft-ietf-wish-whip]).

-
-
-
-
-
-
-

-2. Terminology and Notation -

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] -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 Section 7.2, 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:
-
-

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 -a sender from overwhelming the capacity of a path between a sender and a -receiver, causing some outstanding data to be discarded before the receiver can -receive the data and acknowledge it to the sender.

-
-
-
Datagram:
-
-

Datagrams exist in UDP as well as in QUIC's unreliable datagram extension. If not explicitly noted -differently, the term datagram in this document refers to a QUIC Datagram as defined in -[RFC9221].

-
-
-
Delay-based or Low-latency congestion control algorithm:
-
-

A congestion control algorithm that aims at keeping queues, and thus the latency, at intermediary network elements as short as possible. Delay-based congestion control algorithms use, for example, an increasing one-way delay as a signal of congestion.

-
-
-
Endpoint:
-
-

A QUIC server or client that participates in an RoQ session.

-
-
-
Frame:
-
-

A QUIC frame as defined in [RFC9000].

-
-
-
Loss-based congestion control algorithm:
-
-

A congestion control algorithm that uses packet loss, or an Explicit Congestion Notification (ECN) that is interpreted as loss (as in [RFC3168]), as a signal for congestion. Loss-based congestion control algorithms allow senders to send data on a path until packets are dropped by intermediary network elements, which the algorithm treats as a signal of congestion.

-
-
-
Media Encoder:
-
-

An entity that is used by an application to produce a stream of encoded media, which can be -packetized in RTP packets to be transmitted over QUIC.

-
-
-
QUIC congestion controller:
-
-

A software component of an application's QUIC implementation that implements a congestion control algorithm.

-
-
-
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.

-
-
-
Receiver:
-
-

An endpoint that receives media in RTP packets and may send or receive RTCP packets.

-
-
-
RTP congestion controller:
-
-

A software component of an application's RTP implementation that implements a congestion control algorithm.

-
-
-
Sender:
-
-

An endpoint that sends media in RTP packets and may send or receive RTCP packets.

-
-
-
-

Packet diagrams in this document use the format defined in Section 1.3 of [RFC9000] to -illustrate the order and size of fields.

-
-
-
-
-

-3. Protocol Overview -

-

This document introduces a mapping of the Real-time Transport Protocol (RTP) to -the QUIC transport protocol. RoQ allows the use of QUIC streams and -QUIC datagrams to transport real-time data, and thus, the QUIC -implementation MUST support QUIC's datagram extension, if RTP packets -should be sent over QUIC datagrams.

-

[RFC3550] specifies that RTP sessions need to be transmitted on different -transport addresses to allow multiplexing between them. RoQ uses a -different approach to leverage the advantages of QUIC connections without -managing a separate QUIC connection per RTP session. QUIC does not provide -demultiplexing between different flows on datagrams but suggests that an -application implement a demultiplexing mechanism if required. An example of such -a mechanism would be flow identifiers prepended to each datagram frame as described -in Section 2.1 of [I-D.draft-ietf-masque-h3-datagram]. RoQ uses a -flow identifier to replace the network address and port number to multiplex many -RTP sessions over the same QUIC connection.

-

An RTP application is responsible for determining what to send in an encoded media stream, and how to send that encoded media stream within a targeted bitrate.

-

This document does not mandate how an application determines what to send in an encoded media stream, because decisions about what to send within a targeted bitrate, and how to adapt to changes in the targeted bitrate, can be application and codec-specific. For example, adjusting quantization in response to changing network conditions may work well in many cases, but if what's being shared is video that includes text, maintaining readability is important.

-

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.

-

Since QUIC also collects some metrics about the network's performance, these -metrics can be used to generate the required feedback at the sender-side and -provide it to the rate adaptation algorithm to avoid the additional overhead of the -RTCP stream. This is discussed in more detail in Section 8.

-
-
-

-3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both -

-

This document describes the use of both QUIC streams and QUIC datagrams as RTP encapsulations, but does not take a position on which encapsulation an application should use. Indeed, an application can use both QUIC streams and QUIC datagram encapsulations. The choice of which encapsulation is used is up to the application developer, but it is worth noting the differences.

-

QUIC [RFC9000] was initially designed to carry HTTP [RFC9114] in QUIC streams, and QUIC streams provide what HTTP application developers require - for example, QUIC streams provide a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC streams can be multiplexed over a single QUIC connection, using stream IDs to demultiplex incoming messages.

-

QUIC Datagrams [RFC9221] were developed as a QUIC extension, intended to support applications that do not require reliable delivery of application data. This extension defines two QUIC DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC STREAM frames within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context.

-

There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC streams. The implementation likely presents an API to allow appplications to assign relative priorities, but this is not mandated by the standard and may not be present in all implementations.

-

Because QUIC datagrams are an extension to QUIC, they inherit a great deal of functionality from QUIC (much of which is described in Section 1.2); so much so that it is easier to explain what datagrams do NOT inherit.

-
    -
  • -

    DATAGRAM frames do not provide any explicit flow control signaling. This means that a QUIC receiver may not be able to commit the necessary resources to process incoming frames, but the purpose for DATAGRAM frames is to carry application-level information that can be lost and will not be retransmitted,

    -
    • -
  • -

    DATAGRAM frames do inherit the QUIC connection's congestion controller. This means that although there is no frame-level flow control, DATAGRAM frames may be delayed until the controller allows them to be sent, or dropped (with an optional notification to the sending application). Implementations can also delay sending DATAGRAM frames to maintain consistent packet pacing (as described in Section 7.7 of [RFC9002]), and can allow an application to specify a sending expiration time, but these capabilities are not mandated by the standard and may not be present in all implementations.

    -
    • -
  • -

    DATAGRAM frames cannot be fragmented. They are limited in size by the max_datagram_frame_size transport parameter, and further limited by the max_udp_payload_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints.

    -
    • -
  • -

    DATAGRAM frames belong to a QUIC connection as a whole. There is no QUIC-level way to multiplex/demultiplex DATAGRAM frames within a single QUIC connection. Any multiplexing identifiers must be added, interpreted, and removed by an application, and they will be sent as part of the payload of the DATAGRAM frame itself.

    -
    • -
-

Because QUIC datagrams are an extension to QUIC, a RoQ endpoint cannot count on a RoQ peer supporting that extension. The RoQ endpoint may discover that its peer does not support datagrams while using signaling to set up QUIC connections, but may also discover that its peer has not negotiated the use of this extension during the QUIC handshake. When this happens, the RoQ endpoint needs to make a decision about what to do next.

-
    -
  • -

    If the use of QUIC datagrams was critical, the endpoint can simply close the QUIC connection, allowing someone or something to correct this mismatch, so that QUIC datagrams can be used.

    -
    • -
  • -

    If the use of QUIC datagrams was not critical, the endpoint can negotiate the use of QUIC streams instead.

    -
    • -
-
-
-
-
-

-3.2. Supported RTP Topologies -

-

RoQ only supports some of the RTP topologies described in -[RFC7667]. Most notably, due to QUIC [RFC9000] being a purely IP unicast -protocol at the time of writing, RoQ cannot be used as a transport -protocol for any of the paths that rely on IP multicast in several multicast -topologies (e.g., Topo-ASM, Topo-SSM, Topo-SSM-RAMS).

-

Some "multicast topologies" can include IP unicast paths (e.g., Topo-SSM, -Topo-SSM-RAMS). In these cases, the unicast paths can use RoQ.

-

RTP supports different types of translators and mixers. Whenever a middlebox -such as a translator or a mixer needs to access the content of RTP/RTCP-packets, -the QUIC connection has to be terminated at that middlebox.

-

RoQ streams (see Section 5.2) can support much larger RTP -packet sizes than other transport protocols such as UDP can, which can lead to -problems with transport translators which translate from RoQ to RTP -over a different transport protocol. A similar problem can occur if a translator -needs to translate from RTP over UDP to RoQ datagrams, where the MTU -of a QUIC datagram may be smaller than the MTU of a UDP datagram. In both cases, -the translator may need to rewrite the RTP packets to fit into the smaller MTU -of the other protocol. Such a translator may need codec-specific knowledge to -packetize the payload of the incoming RTP packets in smaller RTP packets.

-

Additional details are provided in the following table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 1
RFC 7667 SectionShortcut NameRTP over QUIC?Comments
- 3.1 -Topo-Point-to-Pointyes 
- 3.2.1.1 -Topo-PtP-RelayyesNote-NAT
- 3.2.1.2 -Topo-Trn-TranslatoryesNote-MTU
Note-SEC
- 3.2.1.3 -Topo-Media-TranslatoryesNote-MTU
- 3.2.2 -Topo-Back-To-BackyesNote-SEC
Note-MTU
Note-MCast
- 3.3.1 -Topo-ASMnoNote-MCast
- 3.3.2 -Topo-SSMpartlyNote-MCast
Note-UCast-MCast
- 3.3.3 -Topo-SSM-RAMSpartlyNote-MCast
Note-MCast-UCast
- 3.4 -Topo-MeshyesNote-MCast
- 3.5.1 -Topo-PtM-Trn-TranslatorpossiblyNote-MCast
Note-MTU
Note-Topo-PtM-Trn-Translator
- 3.6 -Topo-MixerpossiblyNote-MCast
Note-Topo-Mixer
- 3.6.1 -Media-Mixing-MixerpartlyNote-Topo-Mixer
- 3.6.2 -Media-Switching-MixerpartlyNote-Topo-Mixer
- 3.7 -Selective Forwarding MiddleboxyesNote-MCast
Note-Topo-Mixer
- 3.8 -Topo-Video-switch-MCUyesNote-MTU
Note-MCast
Note-Topo-Mixer
- 3.9 -Topo-RTCP-terminating-MCUyesNote-MTU
Note-MCast
Note-Topo-Mixer
- 3.10 -Topo-Split-TerminalyesNote-MCast
- 3.11 -Topo-AsymmetricPossiblyNote-Warn,
Note-MCast,
Note-MTU
-
-
Note-NAT:
-
-

QUIC [RFC9000] doesn't support NAT traversal.

-
-
-
Note-MTU:
-
-

Supported, but may require MTU adaptation.

-
-
-
Note-Sec:
-
-

Note that RoQ provides mandatory security, and other RTP transports -do not. Section 12 describes strategies to prevent the inadvertent -disclosure of RTP sessions to unintended third parties.

-
-
-
Note-MCast:
-
-

QUIC [RFC9000] cannot be used for multicast paths.

-
-
-
Note-UCast-MCast:
-
-

The topology refers to a Distribution Source, which receives and relays RTP -from a number of different media senders via unicast before relaying it to the -receivers via multicast. QUIC can be used between the senders and the -Distribution Source.

-
-
-
Note-MCast-UCast:
-
-

The topology refers to a Burst Source or Retransmission Source, which -retransmits RTP to receivers via unicast. QUIC can be used between the -Retransmission Source and the receivers.

-
-
-
Note-Topo-PtM-Trn-Translator:
-
-

Supports unicast paths between RTP sources and translators.

-
-
-
Note-Topo-Mixer:
-
-

Supports unicast paths between RTP senders and mixers.

-
-
-
Note-Warn:
-
-

Quote from [RFC7667]: This topology is so problematic and it is so easy to -get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this -topology.

-
-
-
-
-
-
-
-
-
-

-4. Connection Establishment and ALPN -

-

QUIC requires the use of ALPN [RFC7301] tokens during connection setup. RoQ -uses "rtp-mux-quic" as ALPN token in the TLS handshake (see also -Section 13).

-

Note that the use of a given RTP profile is not reflected in the ALPN token even -though it could be considered part of the application usage. This is simply -because different RTP sessions, which may use different RTP profiles, may be -carried within the same QUIC connection.

-
    -
  • -

    Editor's note: "rtp-mux-quic" indicates that RTP and other protocols may -be multiplexed on the same QUIC connection using a flow identifier as -described in Section 5. Applications are responsible for negotiation -of protocols in use by appropriate use of a signaling protocol such as SDP.

    -
    • -
-
    -
  • -

    Editor's note: This implies that applications cannot use RoQ as -specified in this document over WebTransport.

    -
    • -
-
-
-

-4.1. Draft version identification -

-
    -
  • -

    RFC Editor's note: Please remove this section prior to publication of a -final version of this document.

    -
    • -
-

RoQ uses the token "rtp-mux-quic" to identify itself in ALPN.

-

Only implementations of the final, published RFC can identify themselves as -"rtp-mux-quic". Until such an RFC exists, implementations MUST NOT identify -themselves using this string.

-

Implementations of draft versions of the protocol MUST add the string "-" and -the corresponding draft number to the identifier. For example, -draft-ietf-avtcore-rtp-over-quic-04 is identified using the string -"rtp-mux-quic-04".

-

Non-compatible experiments that are based on these draft versions MUST append -the string "-" and an experiment name to the identifier.

-
-
-
-
-
-
-

-5. Encapsulation -

-

This section describes the encapsulation of RTP/RTCP packets in QUIC.

-

QUIC supports two transport methods: streams [RFC9000] and -datagrams [RFC9221]. This document specifies mappings of RTP to -both of the transport modes. Senders MAY combine both modes by sending some -RTP/RTCP packets over the same or different QUIC streams and others in QUIC -datagrams.

-

Section 5.1 introduces a multiplexing mechanism that supports multiplexing -RTP, RTCP, and, with some constraints, other non-RTP protocols. Section 5.2 -and Section 5.3 explain the specifics of mapping RTP to QUIC streams and -QUIC datagrams, respectively.

-
-
-

-5.1. Multiplexing -

-

RoQ uses flow identifiers to multiplex different RTP, RTCP, and -non-RTP data streams on a single QUIC connection. A flow identifier is a QUIC -variable-length integer as described in Section 16 of [RFC9000]. Each flow -identifier is associated with a stream of RTP packets, RTCP packets, or a data -stream of a non-RTP protocol.

-

In a QUIC connection using the ALPN token defined in Section 4, every QUIC -datagram and every QUIC stream MUST start with a flow identifier. A peer MUST -NOT send any data in a datagram or stream that is not associated with the flow -identifier which started the datagram or stream.

-

RTP and RTCP packets of different RTP sessions MUST use distinct flow -identifiers. If peers wish to send multiple types of media in a single RTP -session, they MAY do so by following [RFC8860].

-

A single RTP session MAY be associated with one or two flow identifiers. Thus, -it is possible to send RTP and RTCP packets belonging to the same session using -different flow identifiers. RTP and RTCP packets of a single RTP session MAY use -the same flow identifier (following the procedures defined in [RFC5761]), or -they MAY use different flow identifiers.

-

The association between flow identifiers and data streams MUST be negotiated -using appropriate signaling. Applications MAY send data using flow identifiers -not associated with any RTP or RTCP stream. If a receiver cannot associate a -flow identifier with any RTP/RTCP or non-RTP flow, it MAY drop the data flow. If -the data flow was sent on a QUIC stream, the receiver SHOULD send a -STOP_SENDING frame with the application error code set to -ROQ_UNKNOWN_FLOW_ID.

-

There are different use cases for sharing the same QUIC connection between RTP -and non-RTP data streams. Peers might use the same connection to exchange -signaling messages or exchange data while sending and receiving media streams. -The semantics of non-RTP datagrams or streams are not in the scope of this -document. Peers MAY use any protocol on top of the encapsulation described in -this document.

-

Flow identifiers introduce some overhead in addition to the header overhead of -RTP/RTCP and QUIC. QUIC variable-length integers require between one and eight -bytes depending on the number expressed. Thus, it is advisable to use low -numbers first and only use higher ones if necessary due to an increased number -of flows.

-
-
-
-
-

-5.2. QUIC Streams -

-

To send RTP/RTCP packets over QUIC streams, a sender MUST open at least one new unidirectional QUIC stream. -RoQ uses unidirectional streams, because there is no -synchronous relationship between sent and received RTP/RTCP packets. A peer that -receives a bidirectional stream with a flow identifier that is associated with -an RTP or RTCP stream, SHOULD stop reading from the stream and send a -STOP_SENDING frame with the application protocol error code set to -ROQ_STREAM_CREATION_ERROR.

-

A RoQ sender MAY open new QUIC streams for different packets using the same flow -identifier, for example, to avoid head-of-line blocking.

-

Because a sender can continue sending on a lower stream number after starting packet transmission on a higher stream number, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and MUST not make assumptions about which RTP sequence numbers are carried in which streams.

-
-
-

-5.2.1. Stream Encapsulation -

-

Figure 1 shows the encapsulation format for RoQ Streams.

-
-
-
-
-Payload {
-  Flow Identifier (i),
-  RTP/RTCP Payload(..) ...,
-}
-
-
-
Figure 1: -RoQ Streams Payload Format -
-
-
-
Flow Identifier:
-
-

Flow identifier to demultiplex different data flows on the same QUIC -connection.

-
-
-
RTP/RTCP Payload:
-
-

Contains the RTP/RTCP payload; see Figure 2

-
-
-
-

The payload in a QUIC stream starts with the flow identifier followed by one or -more RTP/RTCP payloads. All RTP/RTCP payloads sent on a stream MUST belong to -the RTP session with the same flow identifier.

-

Each payload begins with a length field indicating the length of the RTP/RTCP -packet, followed by the packet itself, see Figure 2.

-
-
-
-
-RTP/RTCP Payload {
-  Length(i),
-  RTP/RTCP Packet(..),
-}
-
-
-
Figure 2: -RTP/RTCP payload for QUIC streams -
-
-
-
Length:
-
-

A QUIC variable length integer (see Section 16 of [RFC9000]) describing the -length of the following RTP/RTCP packets in bytes.

-
-
-
RTP/RTCP Packet:
-
-

The RTP/RTCP packet to transmit.

-
-
-
-
-
-
-
-

-5.2.2. Media Frame Cancellation -

-

QUIC uses RESET_STREAM and STOP_SENDING frames to terminate the sending part -of a stream and to request termination of an incoming stream by the sending -peer respectively.

-

A RoQ sender MAY use RESET_STREAM if it knows that a packet, which was not yet -successfully and completely transmitted, is no longer needed.

-

A RoQ receiver that is no longer interested in reading a certain partition of -the media stream MAY signal this to the sending peer using a STOP_SENDING -frame.

-

In both cases, the error code of the RESET_STREAM frame or the STOP_SENDING -frame MUST be set to ROQ_FRAME_CANCELLED.

-

STOP_SENDING is not a request to the sender to stop sending the RTP media -stream, only an indication that a receiver stopped reading the QUIC stream being -used. A sender with additional media frames to send SHOULD continue sending them -on another QUIC stream. Alternatively, new media frames can be sent as QUIC -datagrams (see Section 5.3).

-

Any media frame that has already been sent on the QUIC stream that received the -STOP_SENDING frame, MUST NOT be sent again on the new QUIC stream(s) or -datagrams.

-

Note that an RTP receiver cannot request a reset of only a particular media -frame because the sending QUIC implementation might already have sent data for -the following frame on the same stream. In that case, STOP_SENDING and the -following RESET_STREAM would also drop the following media frame and thus lead -to unintentionally skipping one or more frames.

-
    -
  • -

    Editor's note: A receiver cannot cancel a certain frame but still receive -retransmissions for a frame the was following on the same stream using -STOP_SENDING, because STOP_SENDING does not include an offset which would -allow signaling where retransmissions should continue.

    -
    • -
-

A translator that translates between two endpoints, both connected via QUIC, -MUST forward RESET_STREAM frames received from one end to the other unless it -forwards the RTP packets on QUIC datagrams.

-

Large RTP packets sent on a stream will be fragmented into smaller QUIC frames. -The QUIC frames are transmitted reliably and in order such that a receiving -application can read a complete RTP packet from the stream as long as the stream -is not closed with a RESET_STREAM frame. No retransmission has to be -implemented by the application since QUIC frames lost in transit are -retransmitted by QUIC.

-
-
-
-
-

-5.2.3. Flow control and MAX_STREAMS -

-

In order to permit QUIC streams to open, a RoQ sender SHOULD configure non-zero minimum values for the number of permitted streams and the initial stream flow-control window, based on the number of parallel, or simultaneously active, RTP/RTCP flows. -Endpoints that excessively restrict the number of streams or the flow-control window of these streams will increase the chance that the remote peer reaches the limit early and becomes blocked.

-

Opening new streams for new packets MAY implicitly limit the number of packets -concurrently in transit because the QUIC receiver provides an upper bound of -parallel streams, which it can update using QUIC MAX_STREAMS frames. The number -of packets that have to be transmitted concurrently depends on several factors, -such as the number of RTP streams within a QUIC connection, the bitrate of the -media streams, and the maximum acceptable transmission delay of a given packet. -Receivers are responsible for providing senders enough credit to open new -streams for new packets anytime.

-

As an example, consider a conference scenario -with 20 participants. Each participant receives audio and video streams of every -other participant from a central server. If the sender opens a new QUIC stream -for every frame at 30 frames per second video and 50 frames per second audio, it -will open 1520 new QUIC streams per second. A receiver must provide at least -that many credits for opening new unidirectional streams to the server every -second.

-

In addition, the receiver should also consider the requirements of -protocols into account that are multiplexed with RTP, including RTCP and data -streams. These considerations may also be relevant when implementing signaling -since it may be necessary to inform the receiver about how fast and how many -stream credits it will have to provide to the media-sending peer.

-
-
-
-
-
-
-

-5.3. QUIC Datagrams -

-

Senders can also transmit RTP packets in QUIC datagrams. QUIC datagrams are an -extension to QUIC described in [RFC9221]. QUIC datagrams can only be used if -the use of the datagram extension was successfully negotiated during the QUIC handshake. -If the QUIC extension was signaled using a signaling protocol, but that -extension was not negotiated during the QUIC handshake, a peer MAY close the -connection with the ROQ_EXPECTATION_UNMET error code.

-

QUIC datagrams preserve frame boundaries. Thus, a single RTP packet can be -mapped to a single QUIC datagram without additional framing. Senders SHOULD -consider the header overhead associated with QUIC datagrams and ensure that the -RTP/RTCP packets, including their payloads, flow identifier, QUIC, and IP -headers, will fit into path MTU.

-

Figure 3 shows the encapsulation format for RoQ -Datagrams.

-
-
-
-
-Payload {
-  Flow Identifier (i),
-  RTP/RTCP Packet (..),
-}
-
-
-
Figure 3: -RoQ Datagram Payload Format -
-
-
-
Flow Identifier:
-
-

Flow identifier to demultiplex different data flows on the same QUIC -connection.

-
-
-
RTP/RTCP Packet:
-
-

The RTP/RTCP packet to transmit.

-
-
-
-

RoQ senders need to be aware that QUIC uses the concept of QUIC frames. -Different kinds of QUIC frames are used for different application and control -data types. A single QUIC packet can contain more than one QUIC frame, -including, for example, QUIC stream or datagram frames carrying application data -and acknowledgement frames carrying QUIC acknowledgements, as long as the -overall size fits into the MTU. One implication is that the number of packets a -QUIC stack transmits depends on whether it can fit acknowledgement and datagram -frames in the same QUIC packet. Suppose the application creates many datagram -frames that fill up the QUIC packet. In that case, the QUIC stack might have to -create additional packets for acknowledgement- (and possibly other control-) -frames. The additional overhead could, in some cases, be reduced if the -application creates smaller RTP packets, such that the resulting datagram frame -can fit into a QUIC packet that can also carry acknowledgement frames.

-

Since QUIC datagrams are not retransmitted on loss (see also -Section 8.4 for loss signaling), if an application wishes to -retransmit lost RTP packets, the retransmission has to be implemented by the -application. RTP retransmissions can be done in the same RTP session or a -separate RTP session [RFC4588] and the flow identifier MUST be set to the -flow identifier of the RTP session in which the retransmission happens.

-
-
-
-
-
-
-

-6. Connection Shutdown -

-

Either peers MAY close the connection for variety of reasons. If one of the -peers wants to close the RoQ connection, the peer can use a QUIC -CONNECTION_CLOSE frame with one of the error codes defined in -Section 9.

-
-
-
-
-

-7. Congestion Control and Rate Adaptation -

-

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.

-

This document discusses aspects of transport level congestion control in -Section 7.1 and application layer rate control in -Section 7.2. It does not mandate any specific -congestion control algorithm for QUIC or rate adaptation algorithm for RTP.

-

This document also gives guidance about avoiding problems with nested -congestion controllers in Section 7.2.

-

This document also discusses congestion control implications of using shared or -multiple separate QUIC connections to send and receive multiple independent data -streams in Section 7.3.

-
-
-

-7.1. Congestion Control at the Transport Layer -

-

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.

-

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 3.1.

-

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 Appendix A. 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 Section 7.2.

-

It is assumed that the congestion controller in use provides a pacing mechanism -to determine when a packet can be sent to avoid bursts and minimize variation in -inter-packet arrival times. 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.

-
-
-
-
-

-7.2. Rate Adaptation at the 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.

-

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 being 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 Section 8 and Section 10.

-
-
-
-
-

-7.3. Sharing QUIC connections -

-

Two endpoints may establish channels in order to exchange more than one type of -data simultaneously. The channels can be intended to carry real-time RTP data or -other non-real-time data. This can be realized in different ways.

-
    -
  • -

    One straightforward solution is to establish multiple QUIC connections, one -for each channel, whether the channel is used for real-time media or -non-real-time data. This is a straightforward solution, but has the -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.

    -
    • -
-

In both cases, the congestion controllers can be chosen to match the demands of -the respective channels and the different QUIC connections will compete for the -same resources in the network. No local prioritization of data across the -different (types of) channels would be necessary.

-

Although it is possible to multiplex (all or a subset of) real-time and -non-real-time channels onto a single, shared QUIC connection, which can be done -by using the flow identifier described in Section 5.1, the underlying QUIC -implementation will likely use the same congestion controller for all channels -in the shared QUIC connection. For this reason, applications multiplexing -multiple streams in one connection SHOULD implement some form of stream -prioritization or bandwidth allocation.

-
-
-
-
-
-
-

-8. Replacing RTCP and RTP Header Extensions with QUIC Feedback -

-

Because RTP has so often used UDP as its underlying transport protocol, and -receiving little or no feedback from UDP, RTP implementations rely on feedback -from the RTP Control Protocol (RTCP) so that RTP senders and receivers can -exchange control information to monitor connection statistics and to identify -and synchronize streams.

-

Because QUIC provides transport-level feedback, it can replace at least some RTP -transport-level feedback with current QUIC feedback [RFC9000]. In addition, -RTP-level feedback that is not available in QUIC by default can potentially be -replaced with generally useful QUIC extensions in the future as described in -Appendix B.6.

-

When statistics contained in RTCP packets are also available from QUIC or can be -derived from statistics available from QUIC, it is desirable to provide these -statistics at only one protocol layer. This avoids consumption of bandwidth to -deliver equivalent control information at more than one level of the protocol -stack. QUIC and RTCP both have rules describing when certain signals have to be -sent. This document does not change any of the rules described by either -protocol, but specifies a baseline for replacing some of the RTCP packet types -by mapping the contents to QUIC connection statistics, and reducing the -transmission frequency and bandwidth requirements for some RTCP packet types -that must be transmitted periodically. Future documents can extend this mapping -for other RTCP format types, and can make use of new QUIC extensions that become -available over time. The mechanisms described in this section can enhance the -statistics provided by RTCP and reduce the bandwidth overhead required by -certain RTCP packets. Applications using RoQ need to adhere to the rules for -RTCP feedback given by [RFC3550] and the RTP profiles in use.

-

Most statements about "QUIC" in Section 8 are applicable to both RTP -encapsulated in QUIC streams and RTP encapsulated in QUIC datagrams. The -differences are described in Section 8.1 and Section 8.2.

-
    -
  • -

    Editor's Note: Additional discussion of bandwidth minimization could go in -this section, or in an earlier proposed section on motivations for defining -and deploying RoQ.

    -
    • -
-

While RoQ places no restrictions on applications sending RTCP, this document -assumes that the reason an implementor chooses to support RoQ is to obtain -benefits beyond what's available when RTP uses UDP as its underlying transport -layer. It is RECOMMENDED to expose relevant information from the QUIC layer to -the application instead of exchanging additional RTCP packets, where applicable.

-

Section 8.4 discusses what information can be exposed from the -QUIC connection layer to reduce the RTCP overhead.

-
-
-

-8.1. RoQ Datagrams -

-

QUIC Datagrams are ack-eliciting packets, which means that an acknowledgment is -triggered when a datagram frame is received. Thus, a sender can assume that an -RTP packet arrived at the receiver or was lost in transit, using the QUIC -acknowledgments of QUIC Datagram frames. In the following, an RTP packet is -regarded as acknowledged when the QUIC Datagram frame that carried the RTP -packet was acknowledged.

-
-
-
-
-

-8.2. RoQ Streams -

-

For RTP packets that are sent over QUIC streams, an RTP packet is considered -acknowledged after all frames that carried fragments of the RTP packet were -acknowledged.

-

When QUIC Streams are used, the application should be aware that the direct -mapping proposed below may not reflect the real characteristics of the network. -RTP packet loss can seem lower than actual packet loss due to QUIC's automatic -retransmissions. Similarly, timing information might be incorrect due to -retransmissions.

-
-
-
-
-

-8.3. Multihop Topologies -

-

In some topologies, RoQ may be used on only some of the links between multiple -session participants. Other links may be using RTP over UDP, or over some other -supported RTP encapsulation protocol, and some participants might be using -implementations that don't support RoQ at all. These participants will not be -able to infer feedback from QUIC, and they may receive less RTCP feedback than -expected. On the other hand, participants using RoQ might not be aware that -other participants are not using RoQ and send as little RTCP as possible since -they assume their RoQ peer will be able to infer statistics from QUIC. There are -two ways to solve this problem: if the middlebox translating between RoQ and RTP -over other RTP transport protocols such as UDP or TCP provides Back-to-Back RTP -sessions as described in Section 3.2.2 of [RFC7667], this middlebox can add -RTCP packets for the participants not using RoQ by using the statistics the -middlebox gets from QUIC and the mappings described in the following sections. -If the middlebox does not provide Back-to-Back RTP sessions, participants may -use additional signalling to let the RoQ participants know what RTCP is -required.

-
-
-
-
-

-8.4. Feedback Mappings -

-

This section explains how some of the RTCP packet types that are used to signal -reception statistics can be replaced by equivalent statistics that are already -collected by QUIC. The following list explains how this mapping can be achieved -for the individual fields of different RTCP packet types.

-

The list of RTCP packets in this section is not exhaustive, and similar -considerations SHOULD be taken into account before exchanging any other type of -RTCP control packets using RoQ.

-

A more thorough analysis of RTCP Control Packet Types (in Appendix B.1), -Generic RTP Feedback (RTPFB) (in Appendix B.3), Payload-specific RTP -Feedback (PSFB) (in Appendix B.4), Extended Reports (in -Appendix B.2), and RTP Header Extensions (in Appendix B.5), -including the information that cannot be mapped from QUIC.

-
-
-

-8.4.1. Negative Acknowledgments ("NACK") -

-

Generic Negative Acknowledgments (PT=205, FMT=1, Name=Generic NACK, -[RFC4585]) contain information about RTP packets which the receiver -considered lost. Section 6.2.1. of [RFC4585] recommends using this feature -only if the underlying protocol cannot provide similar feedback. QUIC does not -provide negative acknowledgments but can detect lost packets based on the Gap -numbers contained in QUIC ACK frames (Section 6 of [RFC9002]).

-
-
-
-
-

-8.4.2. ECN Feedback ("ECN") -

-

ECN Feedback (PT=205, FMT=8, Name=RTCP-ECN-FB, [RFC6679]) packets -report the count of observed ECN-CE marks. [RFC6679] defines two RTCP -reports, one packet type (with PT=205 and FMT=8), and a new report block for -the extended reports, which are listed above. QUIC supports ECN reporting -through acknowledgments. If the QUIC connection supports ECN, the reporting of -ECN counts SHOULD be done using QUIC acknowledgments rather than RTCP ECN -feedback reports.

-
-
-
-
-

-8.4.3. Goodbye Packets ("BYE") -

-

RTP session participants can use Goodbye RTCP packets (PT=203, Name=BYE, -[RFC3550]), to indicate that a source is no longer active. If the participant -is also going to close the QUIC connection, the BYE packet can be replaced by -a QUIC CONNECTION_CLOSE frame. In this case, the reason for leaving can be -transmitted in QUIC's CONNECTION_CLOSE Reason Phrase. However, if the -participant wishes to use this QUIC connection for any other multiplexed -traffic, the participant has to use the BYE packet because the QUIC -CONNECTION_CLOSE would close the entire QUIC connection for all other QUIC -streams and datagrams.

-
-
-
-
-
-
-
-
-

-9. Error Handling -

-

The following error codes are defined for use when abruptly terminating streams, -aborting reading of streams, or immediately closing RoQ connections.

-
-
ROQ_NO_ERROR (0x00):
-
-

No error. This is used when the connection or stream needs to be closed, but -there is no error to signal.

-
-
-
ROQ_GENERAL_ERROR (0x01):
-
-

An error that does not match a more specific error code occured.

-
-
-
ROQ_INTERNAL_ERROR (0x02):
-
-

An internal error has occured in the RoQ stack.

-
-
-
ROQ_PACKET_ERROR (0x03):
-
-

Invalid payload format, e.g., length does not match packet, invalid flow id -encoding, non-RTP on RTP-flow ID, etc.

-
-
-
ROQ_STREAM_CREATION_ERROR (0x04):
-
-

The endpoint detected that its peer created a stream that violates the ROQ protocol.

-
-
-
ROQ_FRAME_CANCELLED (0x05):
-
-

A receiving endpoint is using STOP_SENDING on the current stream to request -new frames be sent on new streams. Similarly, a sender notifies a receiver that -retransmissions of a frame were stopped using RESET_STREAM and new frames will -be sent on new streams.

-
-
-
ROQ_UNKNOWN_FLOW_ID (0x06):
-
-

An endpoint was unable to handle a flow identifier, e.g., because it was not -signalled or because the endpoint does not support multiplexing using arbitrary -flow identifiers.

-
-
-
ROQ_EXPECTATION_UNMET (0x07):
-
-

Expectiations of the QUIC transport set by RoQ out-of-band signalling were not -met by the QUIC connection.

-
-
-
-
-
-
-
-

-10. API Considerations -

-

The mapping described in the previous sections poses some interface requirements -for the QUIC implementation. Although RoQ works without these requirements, some -optimizations regarding rate adaptation and RTCP mapping require certain -functionalities to be exposed to the application.

-

Each item in the following list can be considered individually. Any exposed -information or function can be used by RoQ regardless of whether the other items -are available. Thus, RoQ does not depend on the availability of all of the -listed features but can apply different optimizations depending on the -functionality exposed by the QUIC implementation.

-
    -
  • -

    Maximum Datagram Size: The maximum datagram size that the QUIC connection -can transmit on the network path to the QUIC receiver. If a RoQ sender using -datagrams does not know the maximum datagram size for the path to the RoQ -receiver, there are only two choices - either use heuristics to limit the size -of RoQ messages, or be prepared to lose RoQ messages that were too large to be -carried through the network path and delivered to the RoQ receiver.

    -
    • -
  • -

    Datagram Acknowledgment and Loss: Section 5.2 of [RFC9221] allows QUIC -implementations to notify the application that a QUIC Datagram was -acknowledged or that it believes a datagram was lost. Given the datagram -acknowledgments and losses, the application can deduce which RTP packets -arrived at the receiver and which were lost (see also Section 8.1).

    -
    • -
  • -

    Stream States: The stream states include which parts of the data sent on a -stream were successfully delivered and which are still outstanding to be sent -or retransmitted. If an application keeps track of the RTP packets sent on a -stream, their respective sizes, and in which order they were transmitted, it -can infer which RTP packets were acknowledged according to the definition in -Section 8.2.

    -
    • -
  • -

    Arrival timestamps: If the QUIC connection uses a timestamp extension like -[I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts], the -arrival timestamps or one-way delays can support the application as described -in Section 8 and Section 7.

    -
    • -
  • -

    Bandwidth Estimation: If a bandwidth estimation is available in the QUIC -implementation, exposing it avoids the implementation of an additional -bandwidth estimation algorithm in the application.

    -
    • -
  • -

    ECN: If ECN marks are available, they can support the bandwidth estimation -of the application if necessary.

    -
    • -
-
-
-
-
-

-11. Discussion -

-
-
-

-11.1. Impact of Connection Migration -

-

RTP sessions are characterized by a continuous flow of packets into either or -both directions. A connection migration may lead to pausing media -transmission until reachability of the peer under the new address is validated. -This may lead to short breaks in media delivery in the order of RTT and, if -RTCP is used for RTT measurements, may cause spikes in observed delays. -Application layer congestion control mechanisms (and also packet repair schemes -such as retransmissions) need to be prepared to cope with such spikes.

-

If a QUIC connection is established via a signaling channel, this signaling -may have involved Interactive Connectivity Establishment (ICE) exchanges to -determine and choose suitable (IP address, port number) pairs for the QUIC -connection. Subsequent address change events may be noticed by QUIC via its -connection migration handling and/or at the ICE or other application layer, -e.g., by noticing changing IP addresses at the network interface. This may -imply that the two signaling and data "layers" get (temporarily) out of sync.

-
    -
  • -

    Editor's Note: It may be desirable that the API provides an indication -of connection migration event for either case.

    -
    • -
-
-
-
-
-

-11.2. 0-RTT considerations -

-

For repeated connections between peers, the initiator of a QUIC connection can -use 0-RTT data for both QUIC streams and datagrams. As such packets are subject to -replay attacks, applications shall carefully specify which data types and operations -are allowed. 0-RTT data may be beneficial for use with RoQ to reduce the -risk of media clipping, e.g., at the beginning of a conversation.

-

This specification defines carrying RTP on top of QUIC and thus does not finally -define what the actual application data are going to be. RTP typically carries -ephemeral media contents that is rendered and possibly recorded but otherwise -causes no side effects. Moreover, the amount of data that can be carried as 0-RTT -data is rather limited. But it is the responsibility of the respective application -to determine if 0-RTT data is permissible.

-
    -
  • -

    Editor's Note: Since the QUIC connection will often be created in the context -of an existing signaling relationship (e.g., using WebRTC or SIP), specific 0-RTT -keying material could be exchanged to prevent replays across sessions. Within -the same connection, replayed media packets would be discarded as duplicates by -the receiver.

    -
    • -
-
-
-
-
-
-
-

-12. Security Considerations -

-

RoQ is subject to the security considerations of RTP described in -Section 9 of [RFC3550] and the security considerations of any RTP profile in -use.

-

The security considerations for the QUIC protocol and datagram extension -described in Section 21 of [RFC9000], Section 9 of [RFC9001], Section 8 of [RFC9002] and Section 6 of [RFC9221] also apply to RoQ.

-

Note that RoQ provides mandatory security, and other RTP transports do -not. In order to prevent the inadvertent disclosure of RTP sessions to -unintended third parties, RTP topologies described in Section 3.2 that -include middleboxes supporting both RoQ and non-RoQ paths -MUST forward RTP packets on non-RoQ paths using a secure AVP profile -([RFC3711], [RFC4585], or another AVP profile providing equivalent -RTP-level security), whether or not RoQ senders are using a secure AVP -profile for those RTP packets.

-
-
-
-
-

-13. IANA Considerations -

-

This document registers a new ALPN protocol ID (in Section 13.1) and creates a -new registry that manages the assignment of error code points in RoQ (in -Section 13.2).

-
-
-

-13.1. Registration of a RoQ Identification String -

-

This document creates a new registration for the identification of RoQ -in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry -[RFC7301].

-

The "rtp-mux-quic" string identifies RoQ:

-
-
Protocol:
-
-

RTP over QUIC (RoQ)

-
-
-
Identification Sequence:
-
-

0x72 0x74 0x70 0x2D 0x6F 0x76 0x65 0x72 0x2D 0x71 0x75 0x69 0x63 ("rtp-mux-quic")

-
-
-
Specification:
-
-

This document

-
-
-
-
-
-
-
-

-13.2. RoQ Error Codes Registry -

-

This document establishes a registry for RoQ error codes. The "RTP over QUIC -(RoQ) Error Codes" registry manages a 62-bit space and is listed under the -"Real-Time Transport Protocol (RTP) Parameters" heading.

-

The new error codes registry created in this document operates under the QUIC -registration policy documented in Section 22.1 of [RFC9000]. This registry -includes the common set of fields listed in Section 22.1.1 of [RFC9000].

-

Permanent registrations in this registry are assigned using the Specification -Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in -hexadecimal; inclusive), which are assigned using Standards Action or IESG -Approval as defined in Sections 4.9 and 4.10 of [RFC8126].

-

Registrations for error codes are required to include a description of the error -code. An expert reviewer is advised to examine new registrations for possible -duplication or interaction with existing error codes.

-

In addition to common fields as described in Section Section 22.1 of [RFC9000], this registry includes two additional fields. Permanent -registrations in this registry MUST include the following fields:

-
-
Name:
-
-

A name for the error code.

-
-
-
Description:
-
-

A brief description of the error code semantics, which MAY be a summary if a -specification reference is provided.

-
-
-
-

The initial allocations in this registry are all assigned permanent status and -list a change controller of the IETF and a contact of the AVTCORE working group -(avt@ietf.org).

-

The entries in Table 2 are registered by this document.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 2: -Initial RoQ Error Codes -
ValueNameDescriptionSpecification
0x00ROQ_NO_ERRORNo Error - Section 9 -
0x01ROQ_GENERAL_ERRORGeneral error - Section 9 -
0x02ROQ_INTERNAL_ERRORInternal Error - Section 9 -
0x03ROQ_PACKET_ERRORInvalid payload format - Section 9 -
0x04ROQ_STREAM_CREATION_ERRORInvalid stream type - Section 9 -
0x05ROQ_FRAME_CANCELLEDFrame cancelled - Section 9 -
0x06ROQ_UNKNOWN_FLOW_IDUnknown Flow ID - Section 9 -
0x07ROQ_EXPECTATION_UNMETExternally signalled requirement unmet - Section 9 -
-
-
-
-
-
-
-

-14. References -

-
-
-

-14.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC3550]
-
-Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, , <https://www.rfc-editor.org/rfc/rfc3550>.
-
-
[RFC3551]
-
-Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, , <https://www.rfc-editor.org/rfc/rfc3551>.
-
-
[RFC3611]
-
-Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, , <https://www.rfc-editor.org/rfc/rfc3611>.
-
-
[RFC4585]
-
-Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, , <https://www.rfc-editor.org/rfc/rfc4585>.
-
-
[RFC4588]
-
-Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, , <https://www.rfc-editor.org/rfc/rfc4588>.
-
-
[RFC6679]
-
-Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, , <https://www.rfc-editor.org/rfc/rfc6679>.
-
-
[RFC7301]
-
-Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
-
-
[RFC7667]
-
-Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, , <https://www.rfc-editor.org/rfc/rfc7667>.
-
-
[RFC768]
-
-Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/rfc/rfc768>.
-
-
[RFC8126]
-
-Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC8298]
-
-Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, , <https://www.rfc-editor.org/rfc/rfc8298>.
-
-
[RFC8698]
-
-Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media", RFC 8698, DOI 10.17487/RFC8698, , <https://www.rfc-editor.org/rfc/rfc8698>.
-
-
[RFC8836]
-
-Jesup, R. and Z. Sarker, Ed., "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, , <https://www.rfc-editor.org/rfc/rfc8836>.
-
-
[RFC8888]
-
-Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, , <https://www.rfc-editor.org/rfc/rfc8888>.
-
-
[RFC8999]
-
-Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, , <https://www.rfc-editor.org/rfc/rfc8999>.
-
-
[RFC9000]
-
-Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
-
-
[RFC9001]
-
-Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/rfc/rfc9001>.
-
-
[RFC9002]
-
-Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, , <https://www.rfc-editor.org/rfc/rfc9002>.
-
-
[RFC9221]
-
-Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, , <https://www.rfc-editor.org/rfc/rfc9221>.
-
-
-
-
-
-
-

-14.2. Informative References -

-
-
[I-D.draft-dawkins-avtcore-sdp-rtp-quic]
-
-Dawkins, S., "SDP Offer/Answer for RTP using QUIC as Transport", Work in Progress, Internet-Draft, draft-dawkins-avtcore-sdp-rtp-quic-00, , <https://datatracker.ietf.org/doc/html/draft-dawkins-avtcore-sdp-rtp-quic-00>.
-
-
[I-D.draft-huitema-quic-ts]
-
-Huitema, C., "Quic Timestamps For Measuring One-Way Delays", Work in Progress, Internet-Draft, draft-huitema-quic-ts-08, , <https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts-08>.
-
-
[I-D.draft-hurst-quic-rtp-tunnelling]
-
-Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, , <https://datatracker.ietf.org/doc/html/draft-hurst-quic-rtp-tunnelling-01>.
-
-
[I-D.draft-ietf-avtcore-rtcp-green-metadata]
-
-He, Y., Herglotz, C., and E. Francois, "RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution", Work in Progress, Internet-Draft, draft-ietf-avtcore-rtcp-green-metadata-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtcp-green-metadata-02>.
-
-
[I-D.draft-ietf-avtext-lrr-07]
-
-Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", Work in Progress, Internet-Draft, draft-ietf-avtext-lrr-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07>.
-
-
[I-D.draft-ietf-masque-h3-datagram]
-
-Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", Work in Progress, Internet-Draft, draft-ietf-masque-h3-datagram-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-11>.
-
-
[I-D.draft-ietf-quic-ack-frequency]
-
-Iyengar, J., Swett, I., and M. Kühlewind, "QUIC Acknowledgement Frequency", Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-07>.
-
-
[I-D.draft-ietf-quic-multipath]
-
-Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-06>.
-
-
[I-D.draft-ietf-quic-reliable-stream-reset]
-
-Seemann, M. and K. Oku, "Reliable QUIC Stream Resets", Work in Progress, Internet-Draft, draft-ietf-quic-reliable-stream-reset-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-reliable-stream-reset-05>.
-
-
[I-D.draft-ietf-rmcat-gcc]
-
-Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real-Time Communication", Work in Progress, Internet-Draft, draft-ietf-rmcat-gcc-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02>.
-
-
[I-D.draft-ietf-wish-whip]
-
-Murillo, S. G. and A. Gouaillard, "WebRTC-HTTP ingestion protocol (WHIP)", Work in Progress, Internet-Draft, draft-ietf-wish-whip-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-wish-whip-12>.
-
-
[I-D.draft-smith-quic-receive-ts]
-
-Smith, C. and I. Swett, "QUIC Extension for Reporting Packet Receive Timestamps", Work in Progress, Internet-Draft, draft-smith-quic-receive-ts-00, , <https://datatracker.ietf.org/doc/html/draft-smith-quic-receive-ts-00>.
-
-
[I-D.draft-thomson-quic-enough]
-
-Thomson, M., "Signaling That a QUIC Receiver Has Enough Stream Data", Work in Progress, Internet-Draft, draft-thomson-quic-enough-00, , <https://datatracker.ietf.org/doc/html/draft-thomson-quic-enough-00>.
-
-
[RFC1122]
-
-Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.
-
-
[RFC1191]
-
-Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, , <https://www.rfc-editor.org/rfc/rfc1191>.
-
-
[RFC3168]
-
-Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
-
-
[RFC3261]
-
-Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, , <https://www.rfc-editor.org/rfc/rfc3261>.
-
-
[RFC3711]
-
-Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
-
-
[RFC5093]
-
-Hunt, G., "BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)", RFC 5093, DOI 10.17487/RFC5093, , <https://www.rfc-editor.org/rfc/rfc5093>.
-
-
[RFC5104]
-
-Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, , <https://www.rfc-editor.org/rfc/rfc5104>.
-
-
[RFC5450]
-
-Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, , <https://www.rfc-editor.org/rfc/rfc5450>.
-
-
[RFC5484]
-
-Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, DOI 10.17487/RFC5484, , <https://www.rfc-editor.org/rfc/rfc5484>.
-
-
[RFC5725]
-
-Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, , <https://www.rfc-editor.org/rfc/rfc5725>.
-
-
[RFC5760]
-
-Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, , <https://www.rfc-editor.org/rfc/rfc5760>.
-
-
[RFC5761]
-
-Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, , <https://www.rfc-editor.org/rfc/rfc5761>.
-
-
[RFC6051]
-
-Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, , <https://www.rfc-editor.org/rfc/rfc6051>.
-
-
[RFC6284]
-
-Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, , <https://www.rfc-editor.org/rfc/rfc6284>.
-
-
[RFC6285]
-
-Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, , <https://www.rfc-editor.org/rfc/rfc6285>.
-
-
[RFC6332]
-
-Begen, A. and E. Friedrich, "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 6332, DOI 10.17487/RFC6332, , <https://www.rfc-editor.org/rfc/rfc6332>.
-
-
[RFC6464]
-
-Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, , <https://www.rfc-editor.org/rfc/rfc6464>.
-
-
[RFC6465]
-
-Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, , <https://www.rfc-editor.org/rfc/rfc6465>.
-
-
[RFC6582]
-
-Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, , <https://www.rfc-editor.org/rfc/rfc6582>.
-
-
[RFC6642]
-
-Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report", RFC 6642, DOI 10.17487/RFC6642, , <https://www.rfc-editor.org/rfc/rfc6642>.
-
-
[RFC6776]
-
-Clark, A. and Q. Wu, "Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block", RFC 6776, DOI 10.17487/RFC6776, , <https://www.rfc-editor.org/rfc/rfc6776>.
-
-
[RFC6798]
-
-Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting", RFC 6798, DOI 10.17487/RFC6798, , <https://www.rfc-editor.org/rfc/rfc6798>.
-
-
[RFC6843]
-
-Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting", RFC 6843, DOI 10.17487/RFC6843, , <https://www.rfc-editor.org/rfc/rfc6843>.
-
-
[RFC6904]
-
-Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, , <https://www.rfc-editor.org/rfc/rfc6904>.
-
-
[RFC6958]
-
-Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, DOI 10.17487/RFC6958, , <https://www.rfc-editor.org/rfc/rfc6958>.
-
-
[RFC6990]
-
-Huang, R., Wu, Q., Asaeda, H., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting", RFC 6990, DOI 10.17487/RFC6990, , <https://www.rfc-editor.org/rfc/rfc6990>.
-
-
[RFC7002]
-
-Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, DOI 10.17487/RFC7002, , <https://www.rfc-editor.org/rfc/rfc7002>.
-
-
[RFC7003]
-
-Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, , <https://www.rfc-editor.org/rfc/rfc7003>.
-
-
[RFC7004]
-
-Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting", RFC 7004, DOI 10.17487/RFC7004, , <https://www.rfc-editor.org/rfc/rfc7004>.
-
-
[RFC7005]
-
-Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, , <https://www.rfc-editor.org/rfc/rfc7005>.
-
-
[RFC7097]
-
-Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets", RFC 7097, DOI 10.17487/RFC7097, , <https://www.rfc-editor.org/rfc/rfc7097>.
-
-
[RFC7243]
-
-Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, , <https://www.rfc-editor.org/rfc/rfc7243>.
-
-
[RFC7244]
-
-Asaeda, H., Wu, Q., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting", RFC 7244, DOI 10.17487/RFC7244, , <https://www.rfc-editor.org/rfc/rfc7244>.
-
-
[RFC7266]
-
-Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting", RFC 7266, DOI 10.17487/RFC7266, , <https://www.rfc-editor.org/rfc/rfc7266>.
-
-
[RFC7272]
-
-van Brandenburg, R., Stokking, H., van Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, , <https://www.rfc-editor.org/rfc/rfc7272>.
-
-
[RFC7294]
-
-Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications", RFC 7294, DOI 10.17487/RFC7294, , <https://www.rfc-editor.org/rfc/rfc7294>.
-
-
[RFC7380]
-
-Tong, J., Bi, C., Ed., Even, R., Wu, Q., Ed., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting", RFC 7380, DOI 10.17487/RFC7380, , <https://www.rfc-editor.org/rfc/rfc7380>.
-
-
[RFC7509]
-
-Huang, R. and V. Singh, "RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics", RFC 7509, DOI 10.17487/RFC7509, , <https://www.rfc-editor.org/rfc/rfc7509>.
-
-
[RFC7728]
-
-Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, , <https://www.rfc-editor.org/rfc/rfc7728>.
-
-
[RFC7826]
-
-Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, , <https://www.rfc-editor.org/rfc/rfc7826>.
-
-
[RFC7867]
-
-Huang, R., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications", RFC 7867, DOI 10.17487/RFC7867, , <https://www.rfc-editor.org/rfc/rfc7867>.
-
-
[RFC7941]
-
-Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, , <https://www.rfc-editor.org/rfc/rfc7941>.
-
-
[RFC8015]
-
-Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics", RFC 8015, DOI 10.17487/RFC8015, , <https://www.rfc-editor.org/rfc/rfc8015>.
-
-
[RFC8083]
-
-Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, , <https://www.rfc-editor.org/rfc/rfc8083>.
-
-
[RFC8085]
-
-Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <https://www.rfc-editor.org/rfc/rfc8085>.
-
-
[RFC8201]
-
-McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, , <https://www.rfc-editor.org/rfc/rfc8201>.
-
-
[RFC8286]
-
-Xia, J., Even, R., Huang, R., and L. Deng, "RTP/RTCP Extension for RTP Splicing Notification", RFC 8286, DOI 10.17487/RFC8286, , <https://www.rfc-editor.org/rfc/rfc8286>.
-
-
[RFC8825]
-
-Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, , <https://www.rfc-editor.org/rfc/rfc8825>.
-
-
[RFC8849]
-
-Even, R. and J. Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, , <https://www.rfc-editor.org/rfc/rfc8849>.
-
-
[RFC8852]
-
-Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", RFC 8852, DOI 10.17487/RFC8852, , <https://www.rfc-editor.org/rfc/rfc8852>.
-
-
[RFC8860]
-
-Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", RFC 8860, DOI 10.17487/RFC8860, , <https://www.rfc-editor.org/rfc/rfc8860>.
-
-
[RFC8861]
-
-Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, , <https://www.rfc-editor.org/rfc/rfc8861>.
-
-
[RFC8899]
-
-Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, , <https://www.rfc-editor.org/rfc/rfc8899>.
-
-
[RFC9114]
-
-Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <https://www.rfc-editor.org/rfc/rfc9114>.
-
-
[RFC9143]
-
-Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, , <https://www.rfc-editor.org/rfc/rfc9143>.
-
-
[RFC9308]
-
-Kühlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, , <https://www.rfc-editor.org/rfc/rfc9308>.
-
-
[RFC9330]
-
-Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, , <https://www.rfc-editor.org/rfc/rfc9330>.
-
-
[RFC9335]
-
-Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, , <https://www.rfc-editor.org/rfc/rfc9335>.
-
-
[VJMK88]
-
-"Congestion Avoidance and Control", , <https://ee.lbl.gov/papers/congavoid.pdf>.
-
-
[_3GPP-TS-26.114]
-
-"IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", , <https://portal.3gpp.org/desktopmodules/Specifications/specificationId=1404>.
-
-
-
-
-
-
-
-

-Appendix A. List of optional QUIC Extensions -

-

The following is a list of QUIC protocol extensions that might be beneficial for -RoQ, but are not required by RoQ.

-
    -
  • -

    An Unreliable Datagram Extension to QUIC [RFC9221]. Without support for -unreliable datagrams, RoQ cannot use the encapsulation specified in -Section 5.3, but can still use QUIC streams as specified in -Section 5.2.

    -
    • -
  • -

    A version of QUIC receive timestamps can be helpful for improved jitter -calculations and congestion control. If the QUIC connection uses a timestamp -extension like, the arrival timestamps or one-way delays could be exposed to -the application for improved bandwidth estimation or RTCP mappings as -described in Section 8 and Appendix B.

    - -
    • -
  • -

    QUIC Acknowledgement Frequency [I-D.draft-ietf-quic-ack-frequency] can -be used by a sender to optimize the acknowledgement behaviour of the receiver, -e.g., to optimize congestion control.

    -
    • -
  • -

    Signaling That a QUIC Receiver Has Enough Stream Data - [I-D.draft-thomson-quic-enough] and Reliable QUIC Stream Resets - [I-D.draft-ietf-quic-reliable-stream-reset] would allow RoQ senders and -receivers to use versions of CLOSE_STREAM and STOP_SENDING that contain -offsets. The offset could be used to reliably retransmit all frames up to a -certain frame that should be cancelled before resuming transmission of further -frames on new QUIC streams.

    -
    • -
-
-
-
-
-

-Appendix B. Considered RTCP Packet Types and RTP Header Extensions -

-

This section lists all the RTCP packet types and RTP header extensions that were -considered in the analysis described in Section 8.

-

Several but not all of these control packets and their attributes can be mapped -from QUIC, as described in Section 8.4. Mappable from QUIC -has one of four values: yes, partly, QUIC extension needed, and no. -Partly is used for packet types for which some fields can be mapped from QUIC, -but not all. QUIC extension needed describes packet types which could be -mapped with help from one or more QUIC extensions.

-

Examples of how certain packet types could be mapped with the help of QUIC -extensions follow in Appendix B.6.

-
-
-

-B.1. RTCP Control Packet Types -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3
NameShortcutPTDefining DocumentMappable from QUICComments
SMPTE time-code mappingSMPTETC194 - [RFC5484] -no 
Extended inter-arrival jitter reportIJ195 - [RFC5450] -noWould require send-timestamps, which are not provided by any QUIC extension today
Sender ReportsSR200 - [RFC3550] -QUIC extension needed / partlysee Appendix B.6.4 and Appendix B.6.1 -
Receiver ReportsRR201 - [RFC3550] -QUIC extension neededsee Appendix B.6.1 -
Source descriptionSDES202 - [RFC3550] -no 
GoodbyeBYE203 - [RFC3550] -partlysee Section 8.4.3 -
Application-definedAPP204 - [RFC3550] -no 
Generic RTP FeedbackRTPFB205 - [RFC4585] -partlysee Appendix B.3 -
Payload-specificPSFB205 - [RFC4585] -partlysee Appendix B.4 -
extended reportXR207 - [RFC3611] -partlysee Appendix B.2 -
AVB RTCP packetAVB    
Receiver Summary InformationRSI209 - [RFC5760] -  
Port MappingTOKEN210 - [RFC6284] -no 
IDMS SettingsIDMS211 - [RFC7272] -no 
Reporting Group Reporting SourcesRGRS212 - [RFC8861] -  
Splicing Notification MessageSNM213 - [RFC8286] -no 
-
-
-
-
-

-B.2. Extended Reports (XR) -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 4: -Extended Report Blocks -
NameDocumentMappable from QUICComments
Loss RLE Report Block - [RFC3611] -yesIf only used for acknowledgment, could be replaced by QUIC acknowledgments, see Section 8.1 and Section 8.2 -
Duplicate RLE Report Block - [RFC3611] -no 
Packet Receipt Times Report Block - [RFC3611] -QUIC extension needed / partlyQUIC could provide packet receive timestamps when using a timestamp extension that reports timestamp for every received packet, such as [I-D.draft-smith-quic-receive-ts]. However, QUIC does not provide feedback in RTP timestamp format.
Receiver Reference Time Report Block - [RFC3611] -QUIC extension neededUsed together with DLRR Report Blocks to calculate RTTs of non-senders. RTT measurements can natively be provided by QUIC.
DLRR Report Block - [RFC3611] -QUIC extension neededUsed together with Receiver Reference Time Report Blocks to calculate RTTs of non-senders. RTT can natively be provided by QUIC.
Statistics Summary Report Block - [RFC3611] -QUIC extension needed / partlyPacket loss and jitter can be inferred from QUIC acknowledgments, if a timestamp extension is used (see [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts]). The remaining fields cannot be mapped to QUIC.
VoIP Metrics Report Block - [RFC3611] -noas in other reports above, only loss and RTT available
RTCP XR - [RFC5093] -no 
Texas Instruments Extended VoIP Quality Block   
Post-repair Loss RLE Report Block - [RFC5725] -no 
Multicast Acquisition Report Block - [RFC6332] -no 
IDMS Report Block - [RFC7272] -no 
ECN Summary Report - [RFC6679] -partlysee Section 8.4.2 -
Measurement Information Block - [RFC6776] -no 
Packet Delay Variation Metrics Block - [RFC6798] -noQUIC timestamps may be used to achieve the same goal?
Delay Metrics Block - [RFC6843] -noQUIC has RTT and can provide timestamps for one-way delay, but no way of informing peers about end-to-end statistics when QUIC is only used on one segment of the path.
Burst/Gap Loss Summary Statistics Block - [RFC7004] - QUIC ACKs?
Burst/Gap Discard Summary Statistics Block - [RFC7004] -no 
Frame Impairment Statistics Summary - [RFC7004] -no 
Burst/Gap Loss Metrics Block - [RFC6958] - QUIC ACKs?
Burst/Gap Discard Metrics Block - [RFC7003] -no 
MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block - [RFC6990] -no 
De-Jitter Buffer Metrics Block - [RFC7005] -no 
Discard Count Metrics Block - [RFC7002] -no 
DRLE (Discard RLE Report) - [RFC7097] -no 
BDR (Bytes Discarded Report) - [RFC7243] -no 
RFISD (RTP Flows Initial Synchronization Delay) - [RFC7244] -no 
RFSO (RTP Flows Synchronization Offset Metrics Block) - [RFC7244] -no 
MOS Metrics Block - [RFC7266] -no 
LCB (Loss Concealment Metrics Block) - [RFC7294], Section 4.1 -no 
CSB (Concealed Seconds Metrics Block) - [RFC7294], Section 4.1 -no 
MPEG2 Transport Stream PSI Decodability Statistics Metrics Block - [RFC7380] -no 
Post-Repair Loss Count Metrics Report Block - [RFC7509] -no 
Video Loss Concealment Metric Report Block - [RFC7867] -no 
Independent Burst/Gap Discard Metrics Block - [RFC8015] -no 
-
-
-
-
-
-

-B.3. Generic RTP Feedback (RTPFB) -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 5
NameLong NameDocumentMappable from QUICComments
Generic NACKGeneric negative acknowledgement - [RFC4585] -partlysee Section 8.4.1 -
TMMBRTemporary Maximum Media Stream Bit Rate Request - [RFC5104] -no 
TMMBNTemporary Maximum Media Stream Bit Rate Notification - [RFC5104] -no 
RTCP-SR-REQRTCP Rapid Resynchronisation Request - [RFC6051] -no 
RAMSRapid Acquisition of Multicast Sessions - [RFC6285] -no 
TLLEITransport-Layer Third-Party Loss Early Indication - [RFC6642] -no?no way of telling QUIC peer "don't ask for retransmission", but QUIC would not ask that anyway, only RTCP NACK?
RTCP-ECN-FBRTCP ECN Feedback - [RFC6679] -partlysee Section 8.4.2 -
PAUSE-RESUMEMedia Pause/Resume - [RFC7728] -no 
DBIDelay Budget Information (DBI) - [_3GPP-TS-26.114] -  
CCFBRTP Congestion Control Feedback - [RFC8888] -QUIC extension neededsee Appendix B.6.2 -
-
-
-
-
-

-B.4. Payload-specific RTP Feedback (PSFB) -

-

Because QUIC is a generic transport protocol, QUIC feedback cannot replace the -following Payload-specific RTP Feedback (PSFB) feedback.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 6
NameLong NameDocument
PLIPicture Loss Indication - [RFC4585] -
SLISlice Loss Indication - [RFC4585] -
RPSIReference Picture Selection Indication - [RFC4585] -
FIRFull Intra Request Command - [RFC5104] -
TSTRTemporal-Spatial Trade-off Request - [RFC5104] -
TSTNTemporal-Spatial Trade-off Notification - [RFC5104] -
VBCMVideo Back Channel Message - [RFC5104] -
PSLEIPayload-Specific Third-Party Loss Early Indication - [RFC6642] -
ROIVideo region-of-interest (ROI) - [_3GPP-TS-26.114] -
LRRLayer Refresh Request Command - [I-D.draft-ietf-avtext-lrr-07] -
VPViewport (VP) - [_3GPP-TS-26.114] -
AFBApplication Layer Feedback - [RFC4585] -
TSRRTemporal-Spatial Resolution Request - [I-D.draft-ietf-avtcore-rtcp-green-metadata] -
TSRNTemporal-Spatial Resolution Notification - [I-D.draft-ietf-avtcore-rtcp-green-metadata] -
-
-
-
-
-

-B.5. RTP Header extensions -

-

Like the payload-specific feedback packets, QUIC cannot directly replace the -control information in the following header extensions. RoQ does not place -restrictions on sending any RTP header extensions. However, some extensions, -such as Transmission Time offsets [RFC5450] are used to improve network -jitter calculation, which can be done in QUIC if a timestamp extension is used.

-
-
-

-B.5.1. Compact Header Extensions -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 7
Extension URIDescriptionReferenceMappable from QUIC
urn:ietf:params:rtp-hdrext:toffsetTransmission Time offsets - [RFC5450] -no
urn:ietf:params:rtp-hdrext:ssrc-audio-levelAudio Level - [RFC6464] -no
urn:ietf:params:rtp-hdrext:splicing-intervalSplicing Interval - [RFC8286] -no
urn:ietf:params:rtp-hdrext:smpte-tcSMPTE time-code mapping - [RFC5484] -no
urn:ietf:params:rtp-hdrext:sdesReserved as base URN for RTCP SDES items that are also defined as RTP compact header extensions. - [RFC7941] -no
urn:ietf:params:rtp-hdrext:ntp-64Synchronisation metadata: 64-bit timestamp format - [RFC6051] -no
urn:ietf:params:rtp-hdrext:ntp-56Synchronisation metadata: 56-bit timestamp format - [RFC6051] -no
urn:ietf:params:rtp-hdrext:encryptEncrypted extension header element - [RFC6904] -no, but maybe irrelevant?
urn:ietf:params:rtp-hdrext:csrc-audio-levelMixer-to-client audio level indicators - [RFC6465] -no
urn:3gpp:video-orientation:6Higher granularity (6-bit) coordination of video orientation (CVO) feature, see clause 6.2.3 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:video-orientationCoordination of video orientation (CVO) feature, see clause 6.2.3 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:roi-sentSignalling of the arbitrary region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:predefined-roi-sentSignalling of the predefined region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 - [_3GPP-TS-26.114] -probably not(?)
-
-
-
-
-

-B.5.2. SDES Compact Header Extensions -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 8
Extension URIDescriptionReferenceMappable from QUIC
urn:ietf:params:rtp-hdrext:sdes:cnameSource Description: Canonical End-Point Identifier (SDES CNAME) - [RFC7941] -no
urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idRTP Stream Identifier - [RFC8852] -no
urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-idRTP Repaired Stream Identifier - [RFC8852] -no
urn:ietf:params:rtp-hdrext:sdes:CaptIdCLUE CaptId - [RFC8849] -no
urn:ietf:params:rtp-hdrext:sdes:midMedia identification - [RFC9143] -no
-
-
-
-
-
-
-

-B.6. Examples -

-
-
-

-B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") -

-

Considerations for mapping QUIC feedback into Receiver Reports (PT=201, -Name=RR, [RFC3550]) are:

-
    -
  • -

    Fraction lost: When RTP packets are carried in QUIC datagrams, the -fraction of lost packets can be directly inferred from QUIC's -acknowledgments. The calculation SHOULD include all packets up to the -acknowledged RTP packet with the highest RTP sequence number. Later packets -SHOULD be ignored since they may still be in flight unless other QUIC -packets that were sent after the RTP packet were already acknowledged.

    -
    • -
  • -

    Cumulative lost: Similar to the fraction of lost packets, the cumulative -loss can be inferred from QUIC's acknowledgments, including all packets up -to the latest acknowledged packet.

    -
    • -
  • -

    Highest Sequence Number received: In RTCP, this field is a 32-bit field -that contains the highest sequence number a receiver received in an RTP -packet and the count of sequence number cycles the receiver has observed. A -sender sends RTP packets in QUIC packets and receives acknowledgments for -the QUIC packets. By keeping a mapping from a QUIC packet to the RTP packets -encapsulated in that QUIC packet, the sender can infer the highest sequence -number and number of cycles seen by the receiver from QUIC acknowledgments.

    -
    • -
  • -

    Interarrival jitter: If QUIC acknowledgments carry timestamps as described -in [I-D.draft-smith-quic-receive-ts], senders can infer the interarrival -jitter from the arrival timestamps in QUIC acknowledgments.

    -
    • -
  • -

    Last SR: Similar to lost packets, the NTP timestamp of the last received -sender report can be inferred from QUIC acknowledgments.

    -
    • -
  • -

    Delay since last SR: This field is not required when the receiver reports -are entirely replaced by QUIC feedback.

    -
    • -
-
-
-
-
-

-B.6.2. Congestion Control Feedback ("CCFB") -

-

RTP Congestion Control Feedback (PT=205, FMT=11, Name=CCFB, -[RFC8888]) contains acknowledgments, arrival timestamps, and ECN -notifications for each received packet. Acknowledgments and ECNs can be inferred -from QUIC as described above. Arrival timestamps can be added through extended -acknowledgment frames as described in [I-D.draft-smith-quic-receive-ts] or -[I-D.draft-huitema-quic-ts].

-
-
-
-
-

-B.6.3. Extended Report ("XR") -

-

Extended Reports (PT=207, Name=XR, [RFC3611]) offer an extensible -framework for a variety of different control messages. Some of the statistics -that are defined as extended report blocks can be derived from QUIC, too. Other -report blocks need to be evaluated individually to determine whether the -contained information can be transmitted using QUIC instead. Table 4 -in Appendix B.2 lists considerations for mapping QUIC feedback to some -of the Extended Reports.

-
-
-
-
-

-B.6.4. Application Layer Repair and other Control Messages -

-

While Appendix B.6.1 presented some RTCP packets that can be replaced by QUIC -features, QUIC cannot replace all of the defined RTCP packet types. This mostly -affects RTCP packet types, which carry control information that is to be -interpreted by the RTP application layer rather than the underlying transport -protocol itself.

-
    -
  • -

    Sender Reports (PT=200, Name=SR, [RFC3550]) are similar to Receiver -Reports, as described in Appendix B.6.1. They are sent by media senders and -additionally contain an NTP and an RTP timestamp and the number of packets and -octets transmitted by the sender. The timestamps can be used by a receiver to -synchronize streams. QUIC cannot provide similar control information since it -does not know about RTP timestamps. A QUIC receiver cannot calculate the -packet or octet counts since it does not know about lost datagrams. Thus, -sender reports are required in RoQ to synchronize streams at the receiver. The -sender reports SHOULD not contain any receiver report blocks if the -information can be inferred from the QUIC transport as explained in -Appendix B.6.1.

    -
    • -
-

In addition to carrying transmission statistics, RTCP packets can contain -application layer control information that cannot directly be mapped to QUIC. -Examples of this information may include:

-
    -
  • -

    Source Description (PT=202, Name=SDES) and Application (PT=204, -Name=APP) packet types from [RFC3550], or

    -
    • -
  • -

    many of the payload-specific feedback messages (PT=206) defined in -[RFC4585], used to control the codec behavior of the sender.

    -
    • -
-

Since QUIC does not provide any kind of application layer control messaging, -QUIC feedback cannot be mapped into these RTCP packet types. If the RTP -application needs this information, the RTCP packet types are used in the same -way as they would be used over any other transport protocol.

-
-
-
-
-
-
-
-
-

-Appendix C. Experimental Results -

-

An experimental implementation of the mapping described in this document can be -found on Github. The application -implements the RoQ Datagrams mapping and implements SCReAM congestion -control at the application layer. It can optionally disable the builtin QUIC -congestion control (NewReno). The endpoints only use RTCP for congestion control -feedback, which can optionally be disabled and replaced by the QUIC connection -statistics as described in Section 8.4.

-

Experimental results of the implementation can be found on -Github, too.

-
-
-
-
-

-Acknowledgments -

-

Early versions of this document were similar in spirit to -[I-D.draft-hurst-quic-rtp-tunnelling], although many details differ. The -authors would like to thank Sam Hurst for providing his thoughts about how QUIC -could be used to carry RTP.

-

The guidance in Section 5.2 about configuring the number of parallel unidirectional QUIC streams is based on Section 6.2 of [RFC9114], with obvious substitutions for RTP/RTCP.

-

The authors would like to thank Bernard Aboba, David Schinazi, Lucas Pardue, -Sergio Garcia Murillo, Spencer Dawkins, and Vidhi Goel for their valuable -comments and suggestions contributing to this document.

-
-
-
-
-

-Authors' Addresses -

-
-
Jörg Ott
-
Technical University Munich
- -
-
-
Mathis Engelbart
-
Technical University Munich
- -
-
-
Spencer Dawkins
-
Tencent America LLC
- -
-
-
- - - diff --git a/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.txt b/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.txt deleted file mode 100644 index cd41586..0000000 --- a/fix-missing-bracket/draft-ietf-avtcore-rtp-over-quic.txt +++ /dev/null @@ -1,2825 +0,0 @@ - - - - -Audio/Video Transport Core Maintenance J. Ott -Internet-Draft M. Engelbart -Intended status: Standards Track Technical University Munich -Expires: 2 August 2024 S. Dawkins - Tencent America LLC - 30 January 2024 - - - RTP over QUIC (RoQ) - draft-ietf-avtcore-rtp-over-quic-latest - -Abstract - - This document specifies a minimal mapping for encapsulating Real-time - Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets - within the QUIC protocol. This mapping is called RTP over QUIC - (RoQ). It also discusses how to leverage state from the QUIC - implementation in the endpoints, in order to reduce the need to - exchange RTCP packets and how to implement congestion control and - rate adaptation without relying on RTCP feedback. - -Discussion Venues - - This note is to be removed before publishing as an RFC. - - Discussion of this document takes place on the Audio/Video Transport - Core Maintenance Working Group mailing list (avt@ietf.org), which is - archived at https://mailarchive.ietf.org/arch/browse/avt/. - - Source for this draft and an issue tracker can be found at - https://github.com/mengelbart/rtp-over-quic-draft. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 2 August 2024. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Background - 1.2. Motivations - 1.2.1. "Always-On" Transport-level Authentication and - Encryption - 1.2.2. "Always-On" Internet-Safe Congestion Avoidance - 1.2.3. RTP Rate Adaptation Based on QUIC Feedback - 1.2.4. Path MTU Discovery and RTP Media Coalescence - 1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single - QUIC Connection - 1.2.6. Exploiting Multiple Connections - 1.2.7. Exploiting New QUIC Capabilities - 1.3. What's in Scope for this Specification - 1.4. What's Out of Scope for this Specification - 2. Terminology and Notation - 3. Protocol Overview - 3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of - Both - 3.2. Supported RTP Topologies - 4. Connection Establishment and ALPN - 4.1. Draft version identification - 5. Encapsulation - 5.1. Multiplexing - 5.2. QUIC Streams - 5.2.1. Stream Encapsulation - 5.2.2. Media Frame Cancellation - 5.2.3. Flow control and MAX_STREAMS - 5.3. QUIC Datagrams - 6. Connection Shutdown - 7. Congestion Control and Rate Adaptation - 7.1. Congestion Control at the Transport Layer - 7.2. Rate Adaptation at the Application Layer - 7.3. Sharing QUIC connections - 8. Replacing RTCP and RTP Header Extensions with QUIC Feedback - 8.1. RoQ Datagrams - 8.2. RoQ Streams - 8.3. Multihop Topologies - 8.4. Feedback Mappings - 8.4.1. Negative Acknowledgments ("NACK") - 8.4.2. ECN Feedback ("ECN") - 8.4.3. Goodbye Packets ("BYE") - 9. Error Handling - 10. API Considerations - 11. Discussion - 11.1. Impact of Connection Migration - 11.2. 0-RTT considerations - 12. Security Considerations - 13. IANA Considerations - 13.1. Registration of a RoQ Identification String - 13.2. RoQ Error Codes Registry - 14. References - 14.1. Normative References - 14.2. Informative References - Appendix A. List of optional QUIC Extensions - Appendix B. Considered RTCP Packet Types and RTP Header Extensions - B.1. RTCP Control Packet Types - B.2. Extended Reports (XR) - B.3. Generic RTP Feedback (RTPFB) - B.4. Payload-specific RTP Feedback (PSFB) - B.5. RTP Header extensions - B.5.1. Compact Header Extensions - B.5.2. SDES Compact Header Extensions - B.6. Examples - B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") - B.6.2. Congestion Control Feedback ("CCFB") - B.6.3. Extended Report ("XR") - B.6.4. Application Layer Repair and other Control Messages - Appendix C. Experimental Results - Acknowledgments - Authors' Addresses - -1. Introduction - - This document specifies a minimal mapping for encapsulating Real-time - Transport Protocol (RTP) [RFC3550] and RTP Control Protocol (RTCP) - [RFC3550] packets within the QUIC protocol ([RFC9000]). This mapping - is called RTP over QUIC (RoQ). It also discusses how to leverage - state from the QUIC implementation in the endpoints, in order to - reduce the need to exchange RTCP packets, and how to implement - congestion control and rate adaptation without relying on RTCP - feedback. - -1.1. Background - - The Real-time Transport Protocol (RTP) [RFC3550] is generally used to - carry real-time media for conversational media sessions, such as - video conferences, across the Internet. Since RTP requires real-time - delivery and is tolerant to packet losses, the default underlying - transport protocol has been UDP, recently with DTLS on top to secure - the media exchange and occasionally TCP (and possibly TLS) as a - fallback. - - This specification describes an application usage of QUIC - ([RFC9308]). As a baseline, the specification does not expect more - than a standard QUIC implementation as defined in [RFC8999], - [RFC9000], [RFC9001], and [RFC9002], providing a secure end-to-end - transport that is also expected to work well through NATs and - firewalls. Beyond this baseline, real-time applications can benefit - from QUIC extensions such as unreliable QUIC datagrams [RFC9221], - which provides additional desirable properties for real-time traffic - (e.g., no unnecessary retransmissions, avoiding head-of-line - blocking). - -1.2. Motivations - - From time to time, someone asks the reasonable question, "why should - anyone implement and deploy RoQ"? This reasonable question deserves - a better answer than "because we can". Upon reflection, the - following motivations seem useful to state. - - The motivations in this section are in no particular order, and this - reflects the reality that not all implementers and deployers would - agree on "the most important motivations". - -1.2.1. "Always-On" Transport-level Authentication and Encryption - - Although application-level mechanisms to encrypt RTP and RTCP - payloads have existed since the introduction of Secure Real-time - Transport Protocol (SRTP) [RFC3711], encryption of RTP and RTCP - header fields and contributing sources has only been defined recently - (in Cryptex [RFC9335], and both SRTP and Cryptex are optional - capabilities for RTP. - - This is in sharp contrast to "always-on" transport-level encryption - in the QUIC protocol, using Transport Layer Security (TLS 1.3) as - described in [RFC9001]. QUIC implementations always authenticate the - entirety of each packet, and encrypt as much of each packet as is - practical, even switching from "long headers", which expose more QUIC - header fields needed to establish a connection, to "short headers", - which only expose the absolute minimum QUIC header fields needed to - identify the connection to the receiver, so that the QUIC payload is - presented to the right QUIC application [RFC8999]. - -1.2.2. "Always-On" Internet-Safe Congestion Avoidance - - 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 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 Section 1.2.5, 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. - - Taken as a whole, - - * 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". - -1.2.3. RTP Rate Adaptation Based on 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 - Section 7 on rate adaptation, and in Section 8 on replacing RTCP and - RTP header extensions with QUIC feedback. - - 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. - -1.2.4. Path MTU Discovery and RTP Media Coalescence - - The minimum Path MTU supported by conformant QUIC implementations is - 1200 bytes [RFC9000], and in addition, QUIC implementations allow - senders to use either DPLPMTUD ([RFC8899]) or PMTUD ([RFC1191], - [RFC8201]) to determine the actual MTU size that the receiver and - path between sender and receiver support, which can be even larger. - - 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. - -1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC - Connection - - In order to conserve ports, especially at NATs and Firewalls, this - specification defines a flow identifier, so that multiple RTP flows, - RTCP flows, and non-RTP flows can be distinguished even if they are - carried on the same QUIC connection. This is described in more - detail in Section 5.1. - -1.2.6. Exploiting Multiple Connections - - Although there is much interest in multiplexing flows on a single - QUIC connection as described in Section 1.2.5, QUIC also provides the - capability of establishing and validating multiple paths for a single - QUIC connection [RFC9000]. Once multiple paths have been validated, - a sender can migrate from one path to another with no additional - signaling, allowing an endpoint to move from one endpoint address to - another without interruption, as long as only a single path is in - active use at any point in time. - - Connection migration may be desireable for a number of reasons, but - to give one example, this allows a sender to distinguish between more - costly cellular paths and less costly WiFi paths, with no action - required from the application. - -1.2.7. Exploiting New QUIC Capabilities - - In addition to connection migration as described in Section 1.2.6, - the capability of validating multiple paths for simultaneous active - use is under active development in the IETF - [I-D.draft-ietf-quic-multipath]. We don't discuss Multipath QUIC - further in this document, because the specification hasn't been - approved yet, but it's one example of ways that RTP, a mature - protocol, can exploit new transport capabilities as they become - available. - -1.3. What's in Scope for this Specification - - This document defines a mapping for RTP and RTCP over QUIC, called - RoQ, and describes ways to reduce the amount of RTCP traffic by - leveraging state information readily available within a QUIC - endpoint. This document also describes different options for - implementing congestion control and rate adaptation for RoQ. - - This specification focuses on providing a secure encapsulation of RTP - packets for transmission over QUIC. The expected usage is wherever - RTP is used to carry media packets, allowing QUIC in place of other - transport protocols such as TCP, UDP, SCTP, DTLS, etc. That is, we - expect RoQ to be used in contexts in which a signaling protocol is - used to announce or negotiate a media encapsulation and the - associated transport parameters (such as IP address, port number). - RoQ is not intended as a stand-alone media transport, although QUIC - transport parameters could be statically configured. - - The above implies that RoQ is targeted at peer-to-peer operation; but - it may also be used in client-server-style settings, e.g., when - talking to a conference server as described in RFC 7667 ([RFC7667]), - or, if RoQ is used to replace RTSP ([RFC7826]), to a media server. - - An appropriate 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 mechanism, so the application - can use a rate adaption mechanism of its choice. - - Moreover, this document describes how a QUIC implementation and its - API can be extended to improve efficiency of the RoQ protocol - operation. - - RoQ does not impact the usage of RTP Audio Video Profiles (AVP) - ([RFC3551]), or any RTP-based mechanisms, even though it may render - some of them unnecessary, e.g., Secure Real-Time Transport Prococol - (SRTP) ([RFC3711]) might not be needed, because end-to-end security - is already provided by QUIC, and double encryption by QUIC and by - SRTP might have more costs than benefits. Nor does RoQ limit the use - of RTCP-based mechanisms, even though some information or functions - obtained by using RTCP mechanisms may also be available from the - underlying QUIC implementation by other means. - - Between two (or more) endpoints, RoQ supports multiplexing multiple - RTP-based media streams within a single QUIC connection and thus - using a single (destination IP address, destination port number, - source IP address, source port number, protocol) 5-tuple.. We note - that multiple independent QUIC connections may be established in - parallel using the same destination IP address, destination port - number, source IP address, source port number, protocol) 5-tuple., - e.g. to carry different media channels. These connections would be - logically independent of one another. - -1.4. What's Out of Scope for this Specification - - This document does not attempt to enhance QUIC for real-time media or - define a replacement for, or evolution of, RTP. Work to map other - media transport protocols to QUIC is under way elsewhere in the IETF. - - RoQ is designed for use with point-to-point connections, because QUIC - itself is not defined for multicast operation. The scope of this - document is limited to unicast RTP/RTCP, even though nothing would or - should prevent its use in multicast setups once QUIC supports - multicast. - - RoQ does not define congestion control and rate adaptation algorithms - for use with media. However, Section 7 discusses options for how - congestion control and rate adaptation could be performed at the QUIC - and/or at the RTP layer, and how information available at the QUIC - layer could be exposed via an API for the benefit of RTP layer - implementation. - - *Editor's note:* Need to check whether Section 7 will also - describe the QUIC interface that's being exposed, or if that ends - up somewhere else in the document. - - RoQ does not define prioritization mechanisms when handling different - media as those would be dependent on the media themselves and their - relationships. Prioritization is left to the application using RoQ. - - This document does not cover signaling for session setup. SDP for - RoQ is defined in separate documents such as - [I-D.draft-dawkins-avtcore-sdp-rtp-quic], and can be carried in any - signaling protocol that can carry SDP, including the Session - Initiation Protocol (SIP) ([RFC3261]), Real-Time Protocols for - Browser-Based Applications (RTCWeb) ([RFC8825]), or WebRTC-HTTP - Ingestion Protocol (WHIP) ([I-D.draft-ietf-wish-whip]). - -2. Terminology and Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in BCP - 14 [RFC2119] [RFC8174] 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 Section 7.2, - 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: 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 a sender from - overwhelming the capacity of a path between a sender and a - receiver, causing some outstanding data to be discarded before the - receiver can receive the data and acknowledge it to the sender. - - Datagram: Datagrams exist in UDP as well as in QUIC's unreliable - datagram extension. If not explicitly noted differently, the term - datagram in this document refers to a QUIC Datagram as defined in - [RFC9221]. - - Delay-based or Low-latency congestion control algorithm: A - congestion control algorithm that aims at keeping queues, and thus - the latency, at intermediary network elements as short as - possible. Delay-based congestion control algorithms use, for - example, an increasing one-way delay as a signal of congestion. - - Endpoint: A QUIC server or client that participates in an RoQ - session. - - Frame: A QUIC frame as defined in [RFC9000]. - - Loss-based congestion control algorithm: A congestion control - algorithm that uses packet loss, or an Explicit Congestion - Notification (ECN) that is interpreted as loss (as in [RFC3168]), - as a signal for congestion. Loss-based congestion control - algorithms allow senders to send data on a path until packets are - dropped by intermediary network elements, which the algorithm - treats as a signal of congestion. - - Media Encoder: An entity that is used by an application to produce a - stream of encoded media, which can be packetized in RTP packets to - be transmitted over QUIC. - - QUIC congestion controller: A software component of an application's - QUIC implementation that implements a congestion control - algorithm. - - 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. - - Receiver: An endpoint that receives media in RTP packets and may - send or receive RTCP packets. - - RTP congestion controller: A software component of an application's - RTP implementation that implements a congestion control algorithm. - - Sender: An endpoint that sends media in RTP packets and may send or - receive RTCP packets. - - Packet diagrams in this document use the format defined in - Section 1.3 of [RFC9000] to illustrate the order and size of fields. - -3. Protocol Overview - - This document introduces a mapping of the Real-time Transport - Protocol (RTP) to the QUIC transport protocol. RoQ allows the use of - QUIC streams and QUIC datagrams to transport real-time data, and - thus, the QUIC implementation MUST support QUIC's datagram extension, - if RTP packets should be sent over QUIC datagrams. - - [RFC3550] specifies that RTP sessions need to be transmitted on - different transport addresses to allow multiplexing between them. - RoQ uses a different approach to leverage the advantages of QUIC - connections without managing a separate QUIC connection per RTP - session. QUIC does not provide demultiplexing between different - flows on datagrams but suggests that an application implement a - demultiplexing mechanism if required. An example of such a mechanism - would be flow identifiers prepended to each datagram frame as - described in Section 2.1 of [I-D.draft-ietf-masque-h3-datagram]. RoQ - uses a flow identifier to replace the network address and port number - to multiplex many RTP sessions over the same QUIC connection. - - An RTP application is responsible for determining what to send in an - encoded media stream, and how to send that encoded media stream - within a targeted bitrate. - - This document does not mandate how an application determines what to - send in an encoded media stream, because decisions about what to send - within a targeted bitrate, and how to adapt to changes in the - targeted bitrate, can be application and codec-specific. For - example, adjusting quantization in response to changing network - conditions may work well in many cases, but if what's being shared is - video that includes text, maintaining readability is important. - - 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. - - Since QUIC also collects some metrics about the network's - performance, these metrics can be used to generate the required - feedback at the sender-side and provide it to the rate adaptation - algorithm to avoid the additional overhead of the RTCP stream. This - is discussed in more detail in Section 8. - -3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both - - This document describes the use of both QUIC streams and QUIC - datagrams as RTP encapsulations, but does not take a position on - which encapsulation an application should use. Indeed, an - application can use both QUIC streams and QUIC datagram - encapsulations. The choice of which encapsulation is used is up to - the application developer, but it is worth noting the differences. - - QUIC [RFC9000] was initially designed to carry HTTP [RFC9114] in QUIC - streams, and QUIC streams provide what HTTP application developers - require - for example, QUIC streams provide a stateful, connection- - oriented, flow-controlled, reliable, ordered stream of bytes to an - application. QUIC streams can be multiplexed over a single QUIC - connection, using stream IDs to demultiplex incoming messages. - - QUIC Datagrams [RFC9221] were developed as a QUIC extension, intended - to support applications that do not require reliable delivery of - application data. This extension defines two QUIC DATAGRAM frame - types (one including a length field, the other not including a length - field), and these DATAGRAM frames can co-exist with QUIC STREAM - frames within a single QUIC connection, sharing the connection's - cryptographic and authentication context, and congestion controller - context. - - There is no default relative priority between DATAGRAM frames with - respect to each other, and there is no default priority between - DATAGRAM frames and QUIC streams. The implementation likely presents - an API to allow appplications to assign relative priorities, but this - is not mandated by the standard and may not be present in all - implementations. - - Because QUIC datagrams are an extension to QUIC, they inherit a great - deal of functionality from QUIC (much of which is described in - Section 1.2); so much so that it is easier to explain what datagrams - do NOT inherit. - - * DATAGRAM frames do not provide any explicit flow control - signaling. This means that a QUIC receiver may not be able to - commit the necessary resources to process incoming frames, but the - purpose for DATAGRAM frames is to carry application-level - information that can be lost and will not be retransmitted, - - * DATAGRAM frames do inherit the QUIC connection's congestion - controller. This means that although there is no frame-level flow - control, DATAGRAM frames may be delayed until the controller - allows them to be sent, or dropped (with an optional notification - to the sending application). Implementations can also delay - sending DATAGRAM frames to maintain consistent packet pacing (as - described in Section 7.7 of [RFC9002]), and can allow an - application to specify a sending expiration time, but these - capabilities are not mandated by the standard and may not be - present in all implementations. - - * DATAGRAM frames cannot be fragmented. They are limited in size by - the max_datagram_frame_size transport parameter, and further - limited by the max_udp_payload_size transport parameter and the - Maximum Transmission Unit (MTU) of the path between endpoints. - - * DATAGRAM frames belong to a QUIC connection as a whole. There is - no QUIC-level way to multiplex/demultiplex DATAGRAM frames within - a single QUIC connection. Any multiplexing identifiers must be - added, interpreted, and removed by an application, and they will - be sent as part of the payload of the DATAGRAM frame itself. - - Because QUIC datagrams are an extension to QUIC, a RoQ endpoint - cannot count on a RoQ peer supporting that extension. The RoQ - endpoint may discover that its peer does not support datagrams while - using signaling to set up QUIC connections, but may also discover - that its peer has not negotiated the use of this extension during the - QUIC handshake. When this happens, the RoQ endpoint needs to make a - decision about what to do next. - - * If the use of QUIC datagrams was critical, the endpoint can simply - close the QUIC connection, allowing someone or something to - correct this mismatch, so that QUIC datagrams can be used. - - * If the use of QUIC datagrams was not critical, the endpoint can - negotiate the use of QUIC streams instead. - -3.2. Supported RTP Topologies - - RoQ only supports some of the RTP topologies described in [RFC7667]. - Most notably, due to QUIC [RFC9000] being a purely IP unicast - protocol at the time of writing, RoQ cannot be used as a transport - protocol for any of the paths that rely on IP multicast in several - multicast topologies (e.g., _Topo-ASM_, _Topo-SSM_, _Topo-SSM-RAMS_). - - Some "multicast topologies" can include IP unicast paths (e.g., - _Topo-SSM_, _Topo-SSM-RAMS_). In these cases, the unicast paths can - use RoQ. - - RTP supports different types of translators and mixers. Whenever a - middlebox such as a translator or a mixer needs to access the content - of RTP/RTCP-packets, the QUIC connection has to be terminated at that - middlebox. - - RoQ streams (see Section 5.2) can support much larger RTP packet - sizes than other transport protocols such as UDP can, which can lead - to problems with transport translators which translate from RoQ to - RTP over a different transport protocol. A similar problem can occur - if a translator needs to translate from RTP over UDP to RoQ - datagrams, where the MTU of a QUIC datagram may be smaller than the - MTU of a UDP datagram. In both cases, the translator may need to - rewrite the RTP packets to fit into the smaller MTU of the other - protocol. Such a translator may need codec-specific knowledge to - packetize the payload of the incoming RTP packets in smaller RTP - packets. - - Additional details are provided in the following table. - - +=======================================+============+========+==========+ - |RFC 7667 Section |Shortcut |RTP over|Comments | - | |Name |QUIC? | | - +=======================================+============+========+==========+ - |3.1 |Topo-Point- |yes | | - |(https://datatracker.ietf.org/doc/html/|to-Point | | | - |rfc7667#section-3.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.1 |Topo-PtP- |yes |Note-NAT | - |(https://datatracker.ietf.org/doc/html/|Relay | | | - |rfc7667#section-3.2.1.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.2 |Topo-Trn- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|Translator | |Note-SEC | - |rfc7667#section-3.2.1.2) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.3 |Topo-Media- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|Translator | | | - |rfc7667#section-3.2.1.3) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.2 |Topo-Back- |yes |Note-SEC | - |(https://datatracker.ietf.org/doc/html/|To-Back | |Note-MTU | - |rfc7667#section-3.2.2) | | |Note-MCast| - +---------------------------------------+------------+--------+----------+ - |3.3.1 |Topo-ASM |no |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | | | - |rfc7667#section-3.3.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.3.2 |Topo-SSM |partly |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | |Note- | - |rfc7667#section-3.3.2) | | |UCast- | - | | | |MCast | - +---------------------------------------+------------+--------+----------+ - |3.3.3 |Topo-SSM- |partly |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|RAMS | |Note- | - |rfc7667#section-3.3.3) | | |MCast- | - | | | |UCast | - +---------------------------------------+------------+--------+----------+ - |3.4 |Topo-Mesh |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | | | - |rfc7667#section-3.4) | | | | - +---------------------------------------+------------+--------+----------+ - |3.5.1 |Topo-PtM- |possibly|Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Trn- | |Note-MTU | - |rfc7667#section-3.5.1) |Translator | |Note-Topo-| - | | | |PtM-Trn- | - | | | |Translator| - +---------------------------------------+------------+--------+----------+ - |3.6 |Topo-Mixer |possibly|Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | |Note-Topo-| - |rfc7667#section-3.6) | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.6.1 |Media- |partly |Note-Topo-| - |(https://datatracker.ietf.org/doc/html/|Mixing-Mixer| |Mixer | - |rfc7667#section-3.6.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.6.2 |Media- |partly |Note-Topo-| - |(https://datatracker.ietf.org/doc/html/|Switching- | |Mixer | - |rfc7667#section-3.6.2) |Mixer | | | - +---------------------------------------+------------+--------+----------+ - |3.7 |Selective |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Forwarding | |Note-Topo-| - |rfc7667#section-3.7) |Middlebox | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.8 |Topo-Video- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|switch-MCU | |Note-MCast| - |rfc7667#section-3.8) | | |Note-Topo-| - | | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.9 |Topo-RTCP- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|terminating-| |Note-MCast| - |rfc7667#section-3.9) |MCU | |Note-Topo-| - | | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.10 |Topo-Split- |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Terminal | | | - |rfc7667#section-3.10) | | | | - +---------------------------------------+------------+--------+----------+ - |3.11 |Topo- |Possibly|Note-Warn,| - |(https://datatracker.ietf.org/doc/html/|Asymmetric | |Note- | - |rfc7667#section-3.11) | | |MCast, | - | | | |Note-MTU | - +---------------------------------------+------------+--------+----------+ - - Table 1 - - Note-NAT: QUIC [RFC9000] doesn't support NAT traversal. - - Note-MTU: Supported, but may require MTU adaptation. - - Note-Sec: Note that RoQ provides mandatory security, and other RTP - transports do not. Section 12 describes strategies to prevent the - inadvertent disclosure of RTP sessions to unintended third - parties. - - Note-MCast: QUIC [RFC9000] cannot be used for multicast paths. - - Note-UCast-MCast: The topology refers to a _Distribution Source_, - which receives and relays RTP from a number of different media - senders via unicast before relaying it to the receivers via - multicast. QUIC can be used between the senders and the - _Distribution Source_. - - Note-MCast-UCast: The topology refers to a _Burst Source_ or - _Retransmission Source_, which retransmits RTP to receivers via - unicast. QUIC can be used between the _Retransmission Source_ and - the receivers. - - Note-Topo-PtM-Trn-Translator: Supports unicast paths between RTP - sources and translators. - - Note-Topo-Mixer: Supports unicast paths between RTP senders and - mixers. - - Note-Warn: Quote from [RFC7667]: _This topology is so problematic - and it is so easy to get the RTCP processing wrong, that it is NOT - RECOMMENDED to implement this topology._ - -4. Connection Establishment and ALPN - - QUIC requires the use of ALPN [RFC7301] tokens during connection - setup. RoQ uses "rtp-mux-quic" as ALPN token in the TLS handshake - (see also Section 13). - - Note that the use of a given RTP profile is not reflected in the ALPN - token even though it could be considered part of the application - usage. This is simply because different RTP sessions, which may use - different RTP profiles, may be carried within the same QUIC - connection. - - *Editor's note:* "rtp-mux-quic" indicates that RTP and other - protocols may be multiplexed on the same QUIC connection using a - flow identifier as described in Section 5. Applications are - responsible for negotiation of protocols in use by appropriate use - of a signaling protocol such as SDP. - - *Editor's note:* This implies that applications cannot use RoQ as - specified in this document over WebTransport. - -4.1. Draft version identification - - *RFC Editor's note:* Please remove this section prior to - publication of a final version of this document. - - RoQ uses the token "rtp-mux-quic" to identify itself in ALPN. - - Only implementations of the final, published RFC can identify - themselves as "rtp-mux-quic". Until such an RFC exists, - implementations MUST NOT identify themselves using this string. - - Implementations of draft versions of the protocol MUST add the string - "-" and the corresponding draft number to the identifier. For - example, draft-ietf-avtcore-rtp-over-quic-04 is identified using the - string "rtp-mux-quic-04". - - Non-compatible experiments that are based on these draft versions - MUST append the string "-" and an experiment name to the identifier. - -5. Encapsulation - - This section describes the encapsulation of RTP/RTCP packets in QUIC. - - QUIC supports two transport methods: streams [RFC9000] and datagrams - [RFC9221]. This document specifies mappings of RTP to both of the - transport modes. Senders MAY combine both modes by sending some RTP/ - RTCP packets over the same or different QUIC streams and others in - QUIC datagrams. - - Section 5.1 introduces a multiplexing mechanism that supports - multiplexing RTP, RTCP, and, with some constraints, other non-RTP - protocols. Section 5.2 and Section 5.3 explain the specifics of - mapping RTP to QUIC streams and QUIC datagrams, respectively. - -5.1. Multiplexing - - RoQ uses flow identifiers to multiplex different RTP, RTCP, and non- - RTP data streams on a single QUIC connection. A flow identifier is a - QUIC variable-length integer as described in Section 16 of [RFC9000]. - Each flow identifier is associated with a stream of RTP packets, RTCP - packets, or a data stream of a non-RTP protocol. - - In a QUIC connection using the ALPN token defined in Section 4, every - QUIC datagram and every QUIC stream MUST start with a flow - identifier. A peer MUST NOT send any data in a datagram or stream - that is not associated with the flow identifier which started the - datagram or stream. - - RTP and RTCP packets of different RTP sessions MUST use distinct flow - identifiers. If peers wish to send multiple types of media in a - single RTP session, they MAY do so by following [RFC8860]. - - A single RTP session MAY be associated with one or two flow - identifiers. Thus, it is possible to send RTP and RTCP packets - belonging to the same session using different flow identifiers. RTP - and RTCP packets of a single RTP session MAY use the same flow - identifier (following the procedures defined in [RFC5761]), or they - MAY use different flow identifiers. - - The association between flow identifiers and data streams MUST be - negotiated using appropriate signaling. Applications MAY send data - using flow identifiers not associated with any RTP or RTCP stream. - If a receiver cannot associate a flow identifier with any RTP/RTCP or - non-RTP flow, it MAY drop the data flow. If the data flow was sent - on a QUIC stream, the receiver SHOULD send a STOP_SENDING frame with - the application error code set to ROQ_UNKNOWN_FLOW_ID. - - There are different use cases for sharing the same QUIC connection - between RTP and non-RTP data streams. Peers might use the same - connection to exchange signaling messages or exchange data while - sending and receiving media streams. The semantics of non-RTP - datagrams or streams are not in the scope of this document. Peers - MAY use any protocol on top of the encapsulation described in this - document. - - Flow identifiers introduce some overhead in addition to the header - overhead of RTP/RTCP and QUIC. QUIC variable-length integers require - between one and eight bytes depending on the number expressed. Thus, - it is advisable to use low numbers first and only use higher ones if - necessary due to an increased number of flows. - -5.2. QUIC Streams - - To send RTP/RTCP packets over QUIC streams, a sender MUST open at - least one new unidirectional QUIC stream. RoQ uses unidirectional - streams, because there is no synchronous relationship between sent - and received RTP/RTCP packets. A peer that receives a bidirectional - stream with a flow identifier that is associated with an RTP or RTCP - stream, SHOULD stop reading from the stream and send a STOP_SENDING - frame with the application protocol error code set to - ROQ_STREAM_CREATION_ERROR. - - A RoQ sender MAY open new QUIC streams for different packets using - the same flow identifier, for example, to avoid head-of-line - blocking. - - Because a sender can continue sending on a lower stream number after - starting packet transmission on a higher stream number, a RoQ - receiver MUST be prepared to receive RoQ packets on any number of - QUIC streams (subject to its limit on parallel open streams) and MUST - not make assumptions about which RTP sequence numbers are carried in - which streams. - -5.2.1. Stream Encapsulation - - Figure 1 shows the encapsulation format for RoQ Streams. - - Payload { - Flow Identifier (i), - RTP/RTCP Payload(..) ..., - } - - Figure 1: RoQ Streams Payload Format - - Flow Identifier: Flow identifier to demultiplex different data flows - on the same QUIC connection. - - RTP/RTCP Payload: Contains the RTP/RTCP payload; see Figure 2 - - The payload in a QUIC stream starts with the flow identifier followed - by one or more RTP/RTCP payloads. All RTP/RTCP payloads sent on a - stream MUST belong to the RTP session with the same flow identifier. - - Each payload begins with a length field indicating the length of the - RTP/RTCP packet, followed by the packet itself, see Figure 2. - - RTP/RTCP Payload { - Length(i), - RTP/RTCP Packet(..), - } - - Figure 2: RTP/RTCP payload for QUIC streams - - Length: A QUIC variable length integer (see Section 16 of [RFC9000]) - describing the length of the following RTP/RTCP packets in bytes. - - RTP/RTCP Packet: The RTP/RTCP packet to transmit. - -5.2.2. Media Frame Cancellation - - QUIC uses RESET_STREAM and STOP_SENDING frames to terminate the - sending part of a stream and to request termination of an incoming - stream by the sending peer respectively. - - A RoQ sender MAY use RESET_STREAM if it knows that a packet, which - was not yet successfully and completely transmitted, is no longer - needed. - - A RoQ receiver that is no longer interested in reading a certain - partition of the media stream MAY signal this to the sending peer - using a STOP_SENDING frame. - - In both cases, the error code of the RESET_STREAM frame or the - STOP_SENDING frame MUST be set to ROQ_FRAME_CANCELLED. - - STOP_SENDING is not a request to the sender to stop sending the RTP - media stream, only an indication that a receiver stopped reading the - QUIC stream being used. A sender with additional media frames to - send SHOULD continue sending them on another QUIC stream. - Alternatively, new media frames can be sent as QUIC datagrams (see - Section 5.3). - - Any media frame that has already been sent on the QUIC stream that - received the STOP_SENDING frame, MUST NOT be sent again on the new - QUIC stream(s) or datagrams. - - Note that an RTP receiver cannot request a reset of only a particular - media frame because the sending QUIC implementation might already - have sent data for the following frame on the same stream. In that - case, STOP_SENDING and the following RESET_STREAM would also drop the - following media frame and thus lead to unintentionally skipping one - or more frames. - - *Editor's note:* A receiver cannot cancel a certain frame but - still receive retransmissions for a frame the was following on the - same stream using STOP_SENDING, because STOP_SENDING does not - include an offset which would allow signaling where - retransmissions should continue. - - A translator that translates between two endpoints, both connected - via QUIC, MUST forward RESET_STREAM frames received from one end to - the other unless it forwards the RTP packets on QUIC datagrams. - - Large RTP packets sent on a stream will be fragmented into smaller - QUIC frames. The QUIC frames are transmitted reliably and in order - such that a receiving application can read a complete RTP packet from - the stream as long as the stream is not closed with a RESET_STREAM - frame. No retransmission has to be implemented by the application - since QUIC frames lost in transit are retransmitted by QUIC. - -5.2.3. Flow control and MAX_STREAMS - - In order to permit QUIC streams to open, a RoQ sender SHOULD - configure non-zero minimum values for the number of permitted streams - and the initial stream flow-control window, based on the number of - parallel, or simultaneously active, RTP/RTCP flows. Endpoints that - excessively restrict the number of streams or the flow-control window - of these streams will increase the chance that the remote peer - reaches the limit early and becomes blocked. - - Opening new streams for new packets MAY implicitly limit the number - of packets concurrently in transit because the QUIC receiver provides - an upper bound of parallel streams, which it can update using QUIC - MAX_STREAMS frames. The number of packets that have to be - transmitted concurrently depends on several factors, such as the - number of RTP streams within a QUIC connection, the bitrate of the - media streams, and the maximum acceptable transmission delay of a - given packet. Receivers are responsible for providing senders enough - credit to open new streams for new packets anytime. - - As an example, consider a conference scenario with 20 participants. - Each participant receives audio and video streams of every other - participant from a central server. If the sender opens a new QUIC - stream for every frame at 30 frames per second video and 50 frames - per second audio, it will open 1520 new QUIC streams per second. A - receiver must provide at least that many credits for opening new - unidirectional streams to the server every second. - - In addition, the receiver should also consider the requirements of - protocols into account that are multiplexed with RTP, including RTCP - and data streams. These considerations may also be relevant when - implementing signaling since it may be necessary to inform the - receiver about how fast and how many stream credits it will have to - provide to the media-sending peer. - -5.3. QUIC Datagrams - - Senders can also transmit RTP packets in QUIC datagrams. QUIC - datagrams are an extension to QUIC described in [RFC9221]. QUIC - datagrams can only be used if the use of the datagram extension was - successfully negotiated during the QUIC handshake. If the QUIC - extension was signaled using a signaling protocol, but that extension - was not negotiated during the QUIC handshake, a peer MAY close the - connection with the ROQ_EXPECTATION_UNMET error code. - - QUIC datagrams preserve frame boundaries. Thus, a single RTP packet - can be mapped to a single QUIC datagram without additional framing. - Senders SHOULD consider the header overhead associated with QUIC - datagrams and ensure that the RTP/RTCP packets, including their - payloads, flow identifier, QUIC, and IP headers, will fit into path - MTU. - - Figure 3 shows the encapsulation format for RoQ Datagrams. - - Payload { - Flow Identifier (i), - RTP/RTCP Packet (..), - } - - Figure 3: RoQ Datagram Payload Format - - Flow Identifier: Flow identifier to demultiplex different data flows - on the same QUIC connection. - - RTP/RTCP Packet: The RTP/RTCP packet to transmit. - - RoQ senders need to be aware that QUIC uses the concept of QUIC - frames. Different kinds of QUIC frames are used for different - application and control data types. A single QUIC packet can contain - more than one QUIC frame, including, for example, QUIC stream or - datagram frames carrying application data and acknowledgement frames - carrying QUIC acknowledgements, as long as the overall size fits into - the MTU. One implication is that the number of packets a QUIC stack - transmits depends on whether it can fit acknowledgement and datagram - frames in the same QUIC packet. Suppose the application creates many - datagram frames that fill up the QUIC packet. In that case, the QUIC - stack might have to create additional packets for acknowledgement- - (and possibly other control-) frames. The additional overhead could, - in some cases, be reduced if the application creates smaller RTP - packets, such that the resulting datagram frame can fit into a QUIC - packet that can also carry acknowledgement frames. - - Since QUIC datagrams are not retransmitted on loss (see also - Section 8.4 for loss signaling), if an application wishes to - retransmit lost RTP packets, the retransmission has to be implemented - by the application. RTP retransmissions can be done in the same RTP - session or a separate RTP session [RFC4588] and the flow identifier - MUST be set to the flow identifier of the RTP session in which the - retransmission happens. - -6. Connection Shutdown - - Either peers MAY close the connection for variety of reasons. If one - of the peers wants to close the RoQ connection, the peer can use a - QUIC CONNECTION_CLOSE frame with one of the error codes defined in - Section 9. - -7. Congestion Control and Rate Adaptation - - 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. - - This document discusses aspects of transport level congestion control - in Section 7.1 and application layer rate control in Section 7.2. It - does not mandate any specific congestion control algorithm for QUIC - or rate adaptation algorithm for RTP. - - This document also gives guidance about avoiding problems with - _nested_ congestion controllers in Section 7.2. - - This document also discusses congestion control implications of using - shared or multiple separate QUIC connections to send and receive - multiple independent data streams in Section 7.3. - -7.1. Congestion Control at the Transport Layer - - 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. - - 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 3.1. - - 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 - Appendix A. 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 Section 7.2. - - It is assumed that the congestion controller in use provides a pacing - mechanism to determine when a packet can be sent to avoid bursts and - minimize variation in inter-packet arrival times. 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. - -7.2. Rate Adaptation at the 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. - - 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 - being 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 Section 8 and Section 10. - -7.3. Sharing QUIC connections - - Two endpoints may establish channels in order to exchange more than - one type of data simultaneously. The channels can be intended to - carry real-time RTP data or other non-real-time data. This can be - realized in different ways. - - * One straightforward solution is to establish multiple QUIC - connections, one for each channel, whether the channel is used for - real-time media or non-real-time data. This is a straightforward - solution, but has the 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. - - In both cases, the congestion controllers can be chosen to match the - demands of the respective channels and the different QUIC connections - will compete for the same resources in the network. No local - prioritization of data across the different (types of) channels would - be necessary. - - Although it is possible to multiplex (all or a subset of) real-time - and non-real-time channels onto a single, shared QUIC connection, - which can be done by using the flow identifier described in - Section 5.1, the underlying QUIC implementation will likely use the - same congestion controller for all channels in the shared QUIC - connection. For this reason, applications multiplexing multiple - streams in one connection SHOULD implement some form of stream - prioritization or bandwidth allocation. - -8. Replacing RTCP and RTP Header Extensions with QUIC Feedback - - Because RTP has so often used UDP as its underlying transport - protocol, and receiving little or no feedback from UDP, RTP - implementations rely on feedback from the RTP Control Protocol (RTCP) - so that RTP senders and receivers can exchange control information to - monitor connection statistics and to identify and synchronize - streams. - - Because QUIC provides transport-level feedback, it can replace at - least some RTP transport-level feedback with current QUIC feedback - [RFC9000]. In addition, RTP-level feedback that is not available in - QUIC by default can potentially be replaced with generally useful - QUIC extensions in the future as described in Appendix B.6. - - When statistics contained in RTCP packets are also available from - QUIC or can be derived from statistics available from QUIC, it is - desirable to provide these statistics at only one protocol layer. - This avoids consumption of bandwidth to deliver equivalent control - information at more than one level of the protocol stack. QUIC and - RTCP both have rules describing when certain signals have to be sent. - This document does not change any of the rules described by either - protocol, but specifies a baseline for replacing some of the RTCP - packet types by mapping the contents to QUIC connection statistics, - and reducing the transmission frequency and bandwidth requirements - for some RTCP packet types that must be transmitted periodically. - Future documents can extend this mapping for other RTCP format types, - and can make use of new QUIC extensions that become available over - time. The mechanisms described in this section can enhance the - statistics provided by RTCP and reduce the bandwidth overhead - required by certain RTCP packets. Applications using RoQ need to - adhere to the rules for RTCP feedback given by [RFC3550] and the RTP - profiles in use. - - Most statements about "QUIC" in Section 8 are applicable to both RTP - encapsulated in QUIC streams and RTP encapsulated in QUIC datagrams. - The differences are described in Section 8.1 and Section 8.2. - - *Editor's Note:* Additional discussion of bandwidth minimization - could go in this section, or in an earlier proposed section on - motivations for defining and deploying RoQ. - - While RoQ places no restrictions on applications sending RTCP, this - document assumes that the reason an implementor chooses to support - RoQ is to obtain benefits beyond what's available when RTP uses UDP - as its underlying transport layer. It is RECOMMENDED to expose - relevant information from the QUIC layer to the application instead - of exchanging additional RTCP packets, where applicable. - - Section 8.4 discusses what information can be exposed from the QUIC - connection layer to reduce the RTCP overhead. - -8.1. RoQ Datagrams - - QUIC Datagrams are ack-eliciting packets, which means that an - acknowledgment is triggered when a datagram frame is received. Thus, - a sender can assume that an RTP packet arrived at the receiver or was - lost in transit, using the QUIC acknowledgments of QUIC Datagram - frames. In the following, an RTP packet is regarded as acknowledged - when the QUIC Datagram frame that carried the RTP packet was - acknowledged. - -8.2. RoQ Streams - - For RTP packets that are sent over QUIC streams, an RTP packet is - considered acknowledged after all frames that carried fragments of - the RTP packet were acknowledged. - - When QUIC Streams are used, the application should be aware that the - direct mapping proposed below may not reflect the real - characteristics of the network. RTP packet loss can seem lower than - actual packet loss due to QUIC's automatic retransmissions. - Similarly, timing information might be incorrect due to - retransmissions. - -8.3. Multihop Topologies - - In some topologies, RoQ may be used on only some of the links between - multiple session participants. Other links may be using RTP over - UDP, or over some other supported RTP encapsulation protocol, and - some participants might be using implementations that don't support - RoQ at all. These participants will not be able to infer feedback - from QUIC, and they may receive less RTCP feedback than expected. On - the other hand, participants using RoQ might not be aware that other - participants are not using RoQ and send as little RTCP as possible - since they assume their RoQ peer will be able to infer statistics - from QUIC. There are two ways to solve this problem: if the - middlebox translating between RoQ and RTP over other RTP transport - protocols such as UDP or TCP provides Back-to-Back RTP sessions as - described in Section 3.2.2 of [RFC7667], this middlebox can add RTCP - packets for the participants not using RoQ by using the statistics - the middlebox gets from QUIC and the mappings described in the - following sections. If the middlebox does not provide Back-to-Back - RTP sessions, participants may use additional signalling to let the - RoQ participants know what RTCP is required. - -8.4. Feedback Mappings - - This section explains how some of the RTCP packet types that are used - to signal reception statistics can be replaced by equivalent - statistics that are already collected by QUIC. The following list - explains how this mapping can be achieved for the individual fields - of different RTCP packet types. - - The list of RTCP packets in this section is not exhaustive, and - similar considerations SHOULD be taken into account before exchanging - any other type of RTCP control packets using RoQ. - - A more thorough analysis of RTCP Control Packet Types (in - Appendix B.1), Generic RTP Feedback (RTPFB) (in Appendix B.3), - Payload-specific RTP Feedback (PSFB) (in Appendix B.4), Extended - Reports (in Appendix B.2), and RTP Header Extensions (in - Appendix B.5), including the information that cannot be mapped from - QUIC. - -8.4.1. Negative Acknowledgments ("NACK") - - Generic _Negative Acknowledgments_ (PT=205, FMT=1, Name=Generic NACK, - [RFC4585]) contain information about RTP packets which the receiver - considered lost. Section 6.2.1. of [RFC4585] recommends using this - feature only if the underlying protocol cannot provide similar - feedback. QUIC does not provide negative acknowledgments but can - detect lost packets based on the Gap numbers contained in QUIC ACK - frames (Section 6 of [RFC9002]). - -8.4.2. ECN Feedback ("ECN") - - _ECN Feedback_ (PT=205, FMT=8, Name=RTCP-ECN-FB, [RFC6679]) packets - report the count of observed ECN-CE marks. [RFC6679] defines two - RTCP reports, one packet type (with PT=205 and FMT=8), and a new - report block for the extended reports, which are listed above. QUIC - supports ECN reporting through acknowledgments. If the QUIC - connection supports ECN, the reporting of ECN counts SHOULD be done - using QUIC acknowledgments rather than RTCP ECN feedback reports. - -8.4.3. Goodbye Packets ("BYE") - - RTP session participants can use _Goodbye_ RTCP packets (PT=203, - Name=BYE, [RFC3550]), to indicate that a source is no longer active. - If the participant is also going to close the QUIC connection, the - _BYE_ packet can be replaced by a QUIC CONNECTION_CLOSE frame. In - this case, the reason for leaving can be transmitted in QUIC's - CONNECTION_CLOSE _Reason Phrase_. However, if the participant wishes - to use this QUIC connection for any other multiplexed traffic, the - participant has to use the BYE packet because the QUIC - CONNECTION_CLOSE would close the entire QUIC connection for all other - QUIC streams and datagrams. - -9. Error Handling - - The following error codes are defined for use when abruptly - terminating streams, aborting reading of streams, or immediately - closing RoQ connections. - - ROQ_NO_ERROR (0x00): No error. This is used when the connection or - stream needs to be closed, but there is no error to signal. - - ROQ_GENERAL_ERROR (0x01): An error that does not match a more - specific error code occured. - - ROQ_INTERNAL_ERROR (0x02): An internal error has occured in the RoQ - stack. - - ROQ_PACKET_ERROR (0x03): Invalid payload format, e.g., length does - not match packet, invalid flow id encoding, non-RTP on RTP-flow - ID, etc. - - ROQ_STREAM_CREATION_ERROR (0x04): The endpoint detected that its - peer created a stream that violates the ROQ protocol. - - ROQ_FRAME_CANCELLED (0x05): A receiving endpoint is using - STOP_SENDING on the current stream to request new frames be sent - on new streams. Similarly, a sender notifies a receiver that - retransmissions of a frame were stopped using RESET_STREAM and new - frames will be sent on new streams. - - ROQ_UNKNOWN_FLOW_ID (0x06): An endpoint was unable to handle a flow - identifier, e.g., because it was not signalled or because the - endpoint does not support multiplexing using arbitrary flow - identifiers. - - ROQ_EXPECTATION_UNMET (0x07): Expectiations of the QUIC transport - set by RoQ out-of-band signalling were not met by the QUIC - connection. - -10. API Considerations - - The mapping described in the previous sections poses some interface - requirements for the QUIC implementation. Although RoQ works without - these requirements, some optimizations regarding rate adaptation and - RTCP mapping require certain functionalities to be exposed to the - application. - - Each item in the following list can be considered individually. Any - exposed information or function can be used by RoQ regardless of - whether the other items are available. Thus, RoQ does not depend on - the availability of all of the listed features but can apply - different optimizations depending on the functionality exposed by the - QUIC implementation. - - * _Maximum Datagram Size_: The maximum datagram size that the QUIC - connection can transmit on the network path to the QUIC receiver. - If a RoQ sender using datagrams does not know the maximum datagram - size for the path to the RoQ receiver, there are only two choices - - either use heuristics to limit the size of RoQ messages, or be - prepared to lose RoQ messages that were too large to be carried - through the network path and delivered to the RoQ receiver. - - * _Datagram Acknowledgment and Loss_: Section 5.2 of [RFC9221] - allows QUIC implementations to notify the application that a QUIC - Datagram was acknowledged or that it believes a datagram was lost. - Given the datagram acknowledgments and losses, the application can - deduce which RTP packets arrived at the receiver and which were - lost (see also Section 8.1). - - * _Stream States_: The stream states include which parts of the data - sent on a stream were successfully delivered and which are still - outstanding to be sent or retransmitted. If an application keeps - track of the RTP packets sent on a stream, their respective sizes, - and in which order they were transmitted, it can infer which RTP - packets were acknowledged according to the definition in - Section 8.2. - - * _Arrival timestamps_: If the QUIC connection uses a timestamp - extension like [I-D.draft-smith-quic-receive-ts] or - [I-D.draft-huitema-quic-ts], the arrival timestamps or one-way - delays can support the application as described in Section 8 and - Section 7. - - * _Bandwidth Estimation_: If a bandwidth estimation is available in - the QUIC implementation, exposing it avoids the implementation of - an additional bandwidth estimation algorithm in the application. - - * _ECN_: If ECN marks are available, they can support the bandwidth - estimation of the application if necessary. - -11. Discussion - -11.1. Impact of Connection Migration - - RTP sessions are characterized by a continuous flow of packets into - either or both directions. A connection migration may lead to - pausing media transmission until reachability of the peer under the - new address is validated. This may lead to short breaks in media - delivery in the order of RTT and, if RTCP is used for RTT - measurements, may cause spikes in observed delays. Application layer - congestion control mechanisms (and also packet repair schemes such as - retransmissions) need to be prepared to cope with such spikes. - - If a QUIC connection is established via a signaling channel, this - signaling may have involved Interactive Connectivity Establishment - (ICE) exchanges to determine and choose suitable (IP address, port - number) pairs for the QUIC connection. Subsequent address change - events may be noticed by QUIC via its connection migration handling - and/or at the ICE or other application layer, e.g., by noticing - changing IP addresses at the network interface. This may imply that - the two signaling and data "layers" get (temporarily) out of sync. - - *Editor's Note:* It may be desirable that the API provides an - indication of connection migration event for either case. - -11.2. 0-RTT considerations - - For repeated connections between peers, the initiator of a QUIC - connection can use 0-RTT data for both QUIC streams and datagrams. - As such packets are subject to replay attacks, applications shall - carefully specify which data types and operations are allowed. 0-RTT - data may be beneficial for use with RoQ to reduce the risk of media - clipping, e.g., at the beginning of a conversation. - - This specification defines carrying RTP on top of QUIC and thus does - not finally define what the actual application data are going to be. - RTP typically carries ephemeral media contents that is rendered and - possibly recorded but otherwise causes no side effects. Moreover, - the amount of data that can be carried as 0-RTT data is rather - limited. But it is the responsibility of the respective application - to determine if 0-RTT data is permissible. - - *Editor's Note:* Since the QUIC connection will often be created - in the context of an existing signaling relationship (e.g., using - WebRTC or SIP), specific 0-RTT keying material could be exchanged - to prevent replays across sessions. Within the same connection, - replayed media packets would be discarded as duplicates by the - receiver. - -12. Security Considerations - - RoQ is subject to the security considerations of RTP described in - Section 9 of [RFC3550] and the security considerations of any RTP - profile in use. - - The security considerations for the QUIC protocol and datagram - extension described in Section 21 of [RFC9000], Section 9 of - [RFC9001], Section 8 of [RFC9002] and Section 6 of [RFC9221] also - apply to RoQ. - - Note that RoQ provides mandatory security, and other RTP transports - do not. In order to prevent the inadvertent disclosure of RTP - sessions to unintended third parties, RTP topologies described in - Section 3.2 that include middleboxes supporting both RoQ and non-RoQ - paths MUST forward RTP packets on non-RoQ paths using a secure AVP - profile ([RFC3711], [RFC4585], or another AVP profile providing - equivalent RTP-level security), whether or not RoQ senders are using - a secure AVP profile for those RTP packets. - -13. IANA Considerations - - This document registers a new ALPN protocol ID (in Section 13.1) and - creates a new registry that manages the assignment of error code - points in RoQ (in Section 13.2). - -13.1. Registration of a RoQ Identification String - - This document creates a new registration for the identification of - RoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) - Protocol IDs" registry [RFC7301]. - - The "rtp-mux-quic" string identifies RoQ: - - Protocol: RTP over QUIC (RoQ) - - Identification Sequence: 0x72 0x74 0x70 0x2D 0x6F 0x76 0x65 0x72 - 0x2D 0x71 0x75 0x69 0x63 ("rtp-mux-quic") - - Specification: This document - -13.2. RoQ Error Codes Registry - - This document establishes a registry for RoQ error codes. The "RTP - over QUIC (RoQ) Error Codes" registry manages a 62-bit space and is - listed under the "Real-Time Transport Protocol (RTP) Parameters" - heading. - - The new error codes registry created in this document operates under - the QUIC registration policy documented in Section 22.1 of [RFC9000]. - This registry includes the common set of fields listed in - Section 22.1.1 of [RFC9000]. - - Permanent registrations in this registry are assigned using the - Specification Required policy ([RFC8126]), except for values between - 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using - Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 - of [RFC8126]. - - Registrations for error codes are required to include a description - of the error code. An expert reviewer is advised to examine new - registrations for possible duplication or interaction with existing - error codes. - - In addition to common fields as described in Section Section 22.1 of - [RFC9000], this registry includes two additional fields. Permanent - registrations in this registry MUST include the following fields: - - Name: A name for the error code. - - Description: A brief description of the error code semantics, which - MAY be a summary if a specification reference is provided. - - The initial allocations in this registry are all assigned permanent - status and list a change controller of the IETF and a contact of the - AVTCORE working group (avt@ietf.org). - - The entries in Table 2 are registered by this document. - - +=======+===========================+=============+===============+ - | Value | Name | Description | Specification | - +=======+===========================+=============+===============+ - | 0x00 | ROQ_NO_ERROR | No Error | Section 9 | - +-------+---------------------------+-------------+---------------+ - | 0x01 | ROQ_GENERAL_ERROR | General | Section 9 | - | | | error | | - +-------+---------------------------+-------------+---------------+ - | 0x02 | ROQ_INTERNAL_ERROR | Internal | Section 9 | - | | | Error | | - +-------+---------------------------+-------------+---------------+ - | 0x03 | ROQ_PACKET_ERROR | Invalid | Section 9 | - | | | payload | | - | | | format | | - +-------+---------------------------+-------------+---------------+ - | 0x04 | ROQ_STREAM_CREATION_ERROR | Invalid | Section 9 | - | | | stream type | | - +-------+---------------------------+-------------+---------------+ - | 0x05 | ROQ_FRAME_CANCELLED | Frame | Section 9 | - | | | cancelled | | - +-------+---------------------------+-------------+---------------+ - | 0x06 | ROQ_UNKNOWN_FLOW_ID | Unknown | Section 9 | - | | | Flow ID | | - +-------+---------------------------+-------------+---------------+ - | 0x07 | ROQ_EXPECTATION_UNMET | Externally | Section 9 | - | | | signalled | | - | | | requirement | | - | | | unmet | | - +-------+---------------------------+-------------+---------------+ - - Table 2: Initial RoQ Error Codes - -14. References - -14.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. - Jacobson, "RTP: A Transport Protocol for Real-Time - Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, - July 2003, . - - [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and - Video Conferences with Minimal Control", STD 65, RFC 3551, - DOI 10.17487/RFC3551, July 2003, - . - - [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., - "RTP Control Protocol Extended Reports (RTCP XR)", - RFC 3611, DOI 10.17487/RFC3611, November 2003, - . - - [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, - "Extended RTP Profile for Real-time Transport Control - Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, - DOI 10.17487/RFC4585, July 2006, - . - - [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. - Hakenberg, "RTP Retransmission Payload Format", RFC 4588, - DOI 10.17487/RFC4588, July 2006, - . - - [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., - and K. Carlberg, "Explicit Congestion Notification (ECN) - for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August - 2012, . - - [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, - "Transport Layer Security (TLS) Application-Layer Protocol - Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, - July 2014, . - - [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, - DOI 10.17487/RFC7667, November 2015, - . - - [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - DOI 10.17487/RFC0768, August 1980, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation - for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December - 2017, . - - [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- - Assisted Dynamic Adaptation (NADA): A Unified Congestion - Control Scheme for Real-Time Media", RFC 8698, - DOI 10.17487/RFC8698, February 2020, - . - - [RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control - Requirements for Interactive Real-Time Media", RFC 8836, - DOI 10.17487/RFC8836, January 2021, - . - - [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP - Control Protocol (RTCP) Feedback for Congestion Control", - RFC 8888, DOI 10.17487/RFC8888, January 2021, - . - - [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", - RFC 8999, DOI 10.17487/RFC8999, May 2021, - . - - [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based - Multiplexed and Secure Transport", RFC 9000, - DOI 10.17487/RFC9000, May 2021, - . - - [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure - QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, - . - - [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection - and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, - May 2021, . - - [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable - Datagram Extension to QUIC", RFC 9221, - DOI 10.17487/RFC9221, March 2022, - . - -14.2. Informative References - - [I-D.draft-dawkins-avtcore-sdp-rtp-quic] - Dawkins, S., "SDP Offer/Answer for RTP using QUIC as - Transport", Work in Progress, Internet-Draft, draft- - dawkins-avtcore-sdp-rtp-quic-00, 28 January 2022, - . - - [I-D.draft-huitema-quic-ts] - Huitema, C., "Quic Timestamps For Measuring One-Way - Delays", Work in Progress, Internet-Draft, draft-huitema- - quic-ts-08, 28 August 2022, - . - - [I-D.draft-hurst-quic-rtp-tunnelling] - Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, - Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, 28 - January 2021, . - - [I-D.draft-ietf-avtcore-rtcp-green-metadata] - He, Y., Herglotz, C., and E. Francois, "RTP Control - Protocol (RTCP) Messages for Temporal-Spatial Resolution", - Work in Progress, Internet-Draft, draft-ietf-avtcore-rtcp- - green-metadata-02, 12 October 2023, - . - - [I-D.draft-ietf-avtext-lrr-07] - Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. - Flodman, "The Layer Refresh Request (LRR) RTCP Feedback - Message", Work in Progress, Internet-Draft, draft-ietf- - avtext-lrr-07, 2 July 2017, - . - - [I-D.draft-ietf-masque-h3-datagram] - Schinazi, D. and L. Pardue, "HTTP Datagrams and the - Capsule Protocol", Work in Progress, Internet-Draft, - draft-ietf-masque-h3-datagram-11, 17 June 2022, - . - - [I-D.draft-ietf-quic-ack-frequency] - Iyengar, J., Swett, I., and M. Kühlewind, "QUIC - Acknowledgement Frequency", Work in Progress, Internet- - Draft, draft-ietf-quic-ack-frequency-07, 27 October 2023, - . - - [I-D.draft-ietf-quic-multipath] - Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, - C., and M. Kühlewind, "Multipath Extension for QUIC", Work - in Progress, Internet-Draft, draft-ietf-quic-multipath-06, - 23 October 2023, . - - [I-D.draft-ietf-quic-reliable-stream-reset] - Seemann, M. and K. Oku, "Reliable QUIC Stream Resets", - Work in Progress, Internet-Draft, draft-ietf-quic- - reliable-stream-reset-05, 23 January 2024, - . - - [I-D.draft-ietf-rmcat-gcc] - Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. - Mascolo, "A Google Congestion Control Algorithm for Real- - Time Communication", Work in Progress, Internet-Draft, - draft-ietf-rmcat-gcc-02, 8 July 2016, - . - - [I-D.draft-ietf-wish-whip] - Murillo, S. G. and A. Gouaillard, "WebRTC-HTTP ingestion - protocol (WHIP)", Work in Progress, Internet-Draft, draft- - ietf-wish-whip-12, 26 January 2024, - . - - [I-D.draft-smith-quic-receive-ts] - Smith, C. and I. Swett, "QUIC Extension for Reporting - Packet Receive Timestamps", Work in Progress, Internet- - Draft, draft-smith-quic-receive-ts-00, 25 October 2021, - . - - [I-D.draft-thomson-quic-enough] - Thomson, M., "Signaling That a QUIC Receiver Has Enough - Stream Data", Work in Progress, Internet-Draft, draft- - thomson-quic-enough-00, 30 March 2023, - . - - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, - DOI 10.17487/RFC1122, October 1989, - . - - [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, - DOI 10.17487/RFC1191, November 1990, - . - - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", - RFC 3168, DOI 10.17487/RFC3168, September 2001, - . - - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, - A., Peterson, J., Sparks, R., Handley, M., and E. - Schooler, "SIP: Session Initiation Protocol", RFC 3261, - DOI 10.17487/RFC3261, June 2002, - . - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC5093] Hunt, G., "BT's eXtended Network Quality RTP Control - Protocol Extended Reports (RTCP XR XNQ)", RFC 5093, - DOI 10.17487/RFC5093, December 2007, - . - - [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, - "Codec Control Messages in the RTP Audio-Visual Profile - with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, - February 2008, . - - [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in - RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, - . - - [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", - RFC 5484, DOI 10.17487/RFC5484, March 2009, - . - - [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE - Report Block Type for RTP Control Protocol (RTCP) Extended - Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February - 2010, . - - [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control - Protocol (RTCP) Extensions for Single-Source Multicast - Sessions with Unicast Feedback", RFC 5760, - DOI 10.17487/RFC5760, February 2010, - . - - [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and - Control Packets on a Single Port", RFC 5761, - DOI 10.17487/RFC5761, April 2010, - . - - [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP - Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, - . - - [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping - between Unicast and Multicast RTP Sessions", RFC 6284, - DOI 10.17487/RFC6284, June 2011, - . - - [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, - "Unicast-Based Rapid Acquisition of Multicast RTP - Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, - . - - [RFC6332] Begen, A. and E. Friedrich, "Multicast Acquisition Report - Block Type for RTP Control Protocol (RTCP) Extended - Reports (XRs)", RFC 6332, DOI 10.17487/RFC6332, July 2011, - . - - [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time - Transport Protocol (RTP) Header Extension for Client-to- - Mixer Audio Level Indication", RFC 6464, - DOI 10.17487/RFC6464, December 2011, - . - - [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- - time Transport Protocol (RTP) Header Extension for Mixer- - to-Client Audio Level Indication", RFC 6465, - DOI 10.17487/RFC6465, December 2011, - . - - [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The - NewReno Modification to TCP's Fast Recovery Algorithm", - RFC 6582, DOI 10.17487/RFC6582, April 2012, - . - - [RFC6642] Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol - (RTCP) Extension for a Third-Party Loss Report", RFC 6642, - DOI 10.17487/RFC6642, June 2012, - . - - [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information - Reporting Using a Source Description (SDES) Item and an - RTCP Extended Report (XR) Block", RFC 6776, - DOI 10.17487/RFC6776, October 2012, - . - - [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended - Report (XR) Block for Packet Delay Variation Metric - Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, - . - - [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for Delay Metric - Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, - . - - [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure - Real-time Transport Protocol (SRTP)", RFC 6904, - DOI 10.17487/RFC6904, April 2013, - . - - [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP - Control Protocol (RTCP) Extended Report (XR) Block for - Burst/Gap Loss Metric Reporting", RFC 6958, - DOI 10.17487/RFC6958, May 2013, - . - - [RFC6990] Huang, R., Wu, Q., Asaeda, H., and G. Zorn, "RTP Control - Protocol (RTCP) Extended Report (XR) Block for MPEG-2 - Transport Stream (TS) Program Specific Information (PSI) - Independent Decodability Statistics Metrics Reporting", - RFC 6990, DOI 10.17487/RFC6990, August 2013, - . - - [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for Discard Count Metric - Reporting", RFC 7002, DOI 10.17487/RFC7002, September - 2013, . - - [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control - Protocol (RTCP) Extended Report (XR) Block for Burst/Gap - Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, - September 2013, . - - [RFC7004] Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP - Control Protocol (RTCP) Extended Report (XR) Blocks for - Summary Statistics Metrics Reporting", RFC 7004, - DOI 10.17487/RFC7004, September 2013, - . - - [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for De-Jitter Buffer - Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, - September 2013, . - - [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control - Protocol (RTCP) Extended Report (XR) for RLE of Discarded - Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, - . - - [RFC7243] Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control - Protocol (RTCP) Extended Report (XR) Block for the Bytes - Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, May - 2014, . - - [RFC7244] Asaeda, H., Wu, Q., and R. Huang, "RTP Control Protocol - (RTCP) Extended Report (XR) Blocks for Synchronization - Delay and Offset Metrics Reporting", RFC 7244, - DOI 10.17487/RFC7244, May 2014, - . - - [RFC7266] Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control - Protocol (RTCP) Extended Report (XR) Blocks for Mean - Opinion Score (MOS) Metric Reporting", RFC 7266, - DOI 10.17487/RFC7266, June 2014, - . - - [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., - Boronat, F., Montagud, M., and K. Gross, "Inter- - Destination Media Synchronization (IDMS) Using the RTP - Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, - June 2014, . - - [RFC7294] Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control - Protocol (RTCP) Extended Report (XR) Blocks for - Concealment Metrics Reporting on Audio Applications", - RFC 7294, DOI 10.17487/RFC7294, July 2014, - . - - [RFC7380] Tong, J., Bi, C., Ed., Even, R., Wu, Q., Ed., and R. - Huang, "RTP Control Protocol (RTCP) Extended Report (XR) - Block for MPEG2 Transport Stream (TS) Program Specific - Information (PSI) Decodability Statistics Metrics - Reporting", RFC 7380, DOI 10.17487/RFC7380, November 2014, - . - - [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) - Extended Report (XR) for Post-Repair Loss Count Metrics", - RFC 7509, DOI 10.17487/RFC7509, May 2015, - . - - [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP - Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, - February 2016, . - - [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., - and M. Stiemerling, Ed., "Real-Time Streaming Protocol - Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December - 2016, . - - [RFC7867] Huang, R., "RTP Control Protocol (RTCP) Extended Report - (XR) Block for Loss Concealment Metrics for Video - Applications", RFC 7867, DOI 10.17487/RFC7867, July 2016, - . - - [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP - Header Extension for the RTP Control Protocol (RTCP) - Source Description Items", RFC 7941, DOI 10.17487/RFC7941, - August 2016, . - - [RFC8015] Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP - Control Protocol (RTCP) Extended Report (XR) Block for - Independent Reporting of Burst/Gap Discard Metrics", - RFC 8015, DOI 10.17487/RFC8015, November 2016, - . - - [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: - Circuit Breakers for Unicast RTP Sessions", RFC 8083, - DOI 10.17487/RFC8083, March 2017, - . - - [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage - Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, - March 2017, . - - [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., - "Path MTU Discovery for IP version 6", STD 87, RFC 8201, - DOI 10.17487/RFC8201, July 2017, - . - - [RFC8286] Xia, J., Even, R., Huang, R., and L. Deng, "RTP/RTCP - Extension for RTP Splicing Notification", RFC 8286, - DOI 10.17487/RFC8286, October 2017, - . - - [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for - Browser-Based Applications", RFC 8825, - DOI 10.17487/RFC8825, January 2021, - . - - [RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to - Controlling Multiple Streams for Telepresence (CLUE) Media - Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021, - . - - [RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream - Identifier Source Description (SDES)", RFC 8852, - DOI 10.17487/RFC8852, January 2021, - . - - [RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending - Multiple Types of Media in a Single RTP Session", - RFC 8860, DOI 10.17487/RFC8860, January 2021, - . - - [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, - "Sending Multiple RTP Streams in a Single RTP Session: - Grouping RTP Control Protocol (RTCP) Reception Statistics - and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, - January 2021, . - - [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. - Völker, "Packetization Layer Path MTU Discovery for - Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, - September 2020, . - - [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, - June 2022, . - - [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, - "Negotiating Media Multiplexing Using the Session - Description Protocol (SDP)", RFC 9143, - DOI 10.17487/RFC9143, February 2022, - . - - [RFC9308] Kühlewind, M. and B. Trammell, "Applicability of the QUIC - Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, - September 2022, . - - [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. - White, "Low Latency, Low Loss, and Scalable Throughput - (L4S) Internet Service: Architecture", RFC 9330, - DOI 10.17487/RFC9330, January 2023, - . - - [RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely - Encrypting RTP Header Extensions and Contributing - Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, - . - - [VJMK88] "Congestion Avoidance and Control", November 1988, - . - - [_3GPP-TS-26.114] - "IP Multimedia Subsystem (IMS); Multimedia telephony; - Media handling and interaction", 5 January 2023, - . - -Appendix A. List of optional QUIC Extensions - - The following is a list of QUIC protocol extensions that might be - beneficial for RoQ, but are not required by RoQ. - - * _An Unreliable Datagram Extension to QUIC_ [RFC9221]. Without - support for unreliable datagrams, RoQ cannot use the encapsulation - specified in Section 5.3, but can still use QUIC streams as - specified in Section 5.2. - - * A version of QUIC receive timestamps can be helpful for improved - jitter calculations and congestion control. If the QUIC - connection uses a timestamp extension like, the arrival timestamps - or one-way delays could be exposed to the application for improved - bandwidth estimation or RTCP mappings as described in Section 8 - and Appendix B. - - - _Quic Timestamps For Measuring One-Way Delays_ - [I-D.draft-huitema-quic-ts] - - - _QUIC Extension for Reporting Packet Receive Timestamps_ - [I-D.draft-smith-quic-receive-ts] - - * _QUIC Acknowledgement Frequency_ - [I-D.draft-ietf-quic-ack-frequency] can be used by a sender to - optimize the acknowledgement behaviour of the receiver, e.g., to - optimize congestion control. - - * _Signaling That a QUIC Receiver Has Enough Stream Data_ - [I-D.draft-thomson-quic-enough] and _Reliable QUIC Stream Resets_ - [I-D.draft-ietf-quic-reliable-stream-reset] would allow RoQ - senders and receivers to use versions of CLOSE_STREAM and - STOP_SENDING that contain offsets. The offset could be used to - reliably retransmit all frames up to a certain frame that should - be cancelled before resuming transmission of further frames on new - QUIC streams. - -Appendix B. Considered RTCP Packet Types and RTP Header Extensions - - This section lists all the RTCP packet types and RTP header - extensions that were considered in the analysis described in - Section 8. - - Several but not all of these control packets and their attributes can - be mapped from QUIC, as described in Section 8.4. _Mappable from - QUIC_ has one of four values: _yes_, _partly_, _QUIC extension - needed_, and _no_. _Partly_ is used for packet types for which some - fields can be mapped from QUIC, but not all. _QUIC extension needed_ - describes packet types which could be mapped with help from one or - more QUIC extensions. - - Examples of how certain packet types could be mapped with the help of - QUIC extensions follow in Appendix B.6. - -B.1. RTCP Control Packet Types - - +==============+========+===+===========+===========+===============+ - | Name |Shortcut|PT | Defining | Mappable | Comments | - | | | | Document | from QUIC | | - +==============+========+===+===========+===========+===============+ - | SMPTE time- |SMPTETC |194| [RFC5484] | no | | - | code mapping | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Extended |IJ |195| [RFC5450] | no | Would | - | inter- | | | | | require | - | arrival | | | | | send- | - | jitter | | | | | timestamps, | - | report | | | | | which are | - | | | | | | not provided | - | | | | | | by any QUIC | - | | | | | | extension | - | | | | | | today | - +--------------+--------+---+-----------+-----------+---------------+ - | Sender |SR |200| [RFC3550] | QUIC | see Appendix | - | Reports | | | | extension | B.6.4 and | - | | | | | needed / | Appendix | - | | | | | partly | B.6.1 | - +--------------+--------+---+-----------+-----------+---------------+ - | Receiver |RR |201| [RFC3550] | QUIC | see Appendix | - | Reports | | | | extension | B.6.1 | - | | | | | needed | | - +--------------+--------+---+-----------+-----------+---------------+ - | Source |SDES |202| [RFC3550] | no | | - | description | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Goodbye |BYE |203| [RFC3550] | partly | see Section | - | | | | | | 8.4.3 | - +--------------+--------+---+-----------+-----------+---------------+ - | Application- |APP |204| [RFC3550] | no | | - | defined | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Generic RTP |RTPFB |205| [RFC4585] | partly | see | - | Feedback | | | | | Appendix B.3 | - +--------------+--------+---+-----------+-----------+---------------+ - | Payload- |PSFB |205| [RFC4585] | partly | see | - | specific | | | | | Appendix B.4 | - +--------------+--------+---+-----------+-----------+---------------+ - | extended |XR |207| [RFC3611] | partly | see | - | report | | | | | Appendix B.2 | - +--------------+--------+---+-----------+-----------+---------------+ - | AVB RTCP |AVB | | | | | - | packet | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Receiver |RSI |209| [RFC5760] | | | - | Summary | | | | | | - | Information | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Port Mapping |TOKEN |210| [RFC6284] | no | | - +--------------+--------+---+-----------+-----------+---------------+ - | IDMS |IDMS |211| [RFC7272] | no | | - | Settings | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Reporting |RGRS |212| [RFC8861] | | | - | Group | | | | | | - | Reporting | | | | | | - | Sources | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Splicing |SNM |213| [RFC8286] | no | | - | Notification | | | | | | - | Message | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - - Table 3 - -B.2. Extended Reports (XR) - - +===============+==========+=========+==================================+ - |Name |Document |Mappable |Comments | - | | |from QUIC| | - +===============+==========+=========+==================================+ - |Loss RLE Report|[RFC3611] |yes |If only used for acknowledgment, | - |Block | | |could be replaced by QUIC | - | | | |acknowledgments, see Section 8.1 | - | | | |and Section 8.2 | - +---------------+----------+---------+----------------------------------+ - |Duplicate RLE |[RFC3611] |no | | - |Report Block | | | | - +---------------+----------+---------+----------------------------------+ - |Packet Receipt |[RFC3611] |QUIC |QUIC could provide packet receive | - |Times Report | |extension|timestamps when using a timestamp | - |Block | |needed / |extension that reports timestamp | - | | |partly |for every received packet, such as| - | | | |[I-D.draft-smith-quic-receive-ts].| - | | | |However, QUIC does not provide | - | | | |feedback in RTP timestamp format. | - +---------------+----------+---------+----------------------------------+ - |Receiver |[RFC3611] |QUIC |Used together with DLRR Report | - |Reference Time | |extension|Blocks to calculate RTTs of non- | - |Report Block | |needed |senders. RTT measurements can | - | | | |natively be provided by QUIC. | - +---------------+----------+---------+----------------------------------+ - |DLRR Report |[RFC3611] |QUIC |Used together with Receiver | - |Block | |extension|Reference Time Report Blocks to | - | | |needed |calculate RTTs of non-senders. | - | | | |RTT can natively be provided by | - | | | |QUIC. | - +---------------+----------+---------+----------------------------------+ - |Statistics |[RFC3611] |QUIC |Packet loss and jitter can be | - |Summary Report | |extension|inferred from QUIC | - |Block | |needed / |acknowledgments, if a timestamp | - | | |partly |extension is used (see | - | | | |[I-D.draft-smith-quic-receive-ts] | - | | | |or [I-D.draft-huitema-quic-ts]). | - | | | |The remaining fields cannot be | - | | | |mapped to QUIC. | - +---------------+----------+---------+----------------------------------+ - |VoIP Metrics |[RFC3611] |no |as in other reports above, only | - |Report Block | | |loss and RTT available | - +---------------+----------+---------+----------------------------------+ - |RTCP XR |[RFC5093] |no | | - +---------------+----------+---------+----------------------------------+ - |Texas | | | | - |Instruments | | | | - |Extended VoIP | | | | - |Quality Block | | | | - +---------------+----------+---------+----------------------------------+ - |Post-repair |[RFC5725] |no | | - |Loss RLE Report| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Multicast |[RFC6332] |no | | - |Acquisition | | | | - |Report Block | | | | - +---------------+----------+---------+----------------------------------+ - |IDMS Report |[RFC7272] |no | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |ECN Summary |[RFC6679] |partly |see Section 8.4.2 | - |Report | | | | - +---------------+----------+---------+----------------------------------+ - |Measurement |[RFC6776] |no | | - |Information | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Packet Delay |[RFC6798] |no |QUIC timestamps may be used to | - |Variation | | |achieve the same goal? | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Delay Metrics |[RFC6843] |no |QUIC has RTT and can provide | - |Block | | |timestamps for one-way delay, but | - | | | |no way of informing peers about | - | | | |end-to-end statistics when QUIC is| - | | | |only used on one segment of the | - | | | |path. | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap Loss |[RFC7004] | |QUIC ACKs? | - |Summary | | | | - |Statistics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap |[RFC7004] |no | | - |Discard Summary| | | | - |Statistics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Frame |[RFC7004] |no | | - |Impairment | | | | - |Statistics | | | | - |Summary | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap Loss |[RFC6958] | |QUIC ACKs? | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap |[RFC7003] |no | | - |Discard Metrics| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |MPEG2 Transport|[RFC6990] |no | | - |Stream PSI- | | | | - |Independent | | | | - |Decodability | | | | - |Statistics | | | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |De-Jitter |[RFC7005] |no | | - |Buffer Metrics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Discard Count |[RFC7002] |no | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |DRLE (Discard |[RFC7097] |no | | - |RLE Report) | | | | - +---------------+----------+---------+----------------------------------+ - |BDR (Bytes |[RFC7243] |no | | - |Discarded | | | | - |Report) | | | | - +---------------+----------+---------+----------------------------------+ - |RFISD (RTP |[RFC7244] |no | | - |Flows Initial | | | | - |Synchronization| | | | - |Delay) | | | | - +---------------+----------+---------+----------------------------------+ - |RFSO (RTP Flows|[RFC7244] |no | | - |Synchronization| | | | - |Offset Metrics | | | | - |Block) | | | | - +---------------+----------+---------+----------------------------------+ - |MOS Metrics |[RFC7266] |no | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |LCB (Loss |[RFC7294],|no | | - |Concealment |Section | | | - |Metrics Block) |4.1 | | | - +---------------+----------+---------+----------------------------------+ - |CSB (Concealed |[RFC7294],|no | | - |Seconds Metrics|Section | | | - |Block) |4.1 | | | - +---------------+----------+---------+----------------------------------+ - |MPEG2 Transport|[RFC7380] |no | | - |Stream PSI | | | | - |Decodability | | | | - |Statistics | | | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Post-Repair |[RFC7509] |no | | - |Loss Count | | | | - |Metrics Report | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Video Loss |[RFC7867] |no | | - |Concealment | | | | - |Metric Report | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Independent |[RFC8015] |no | | - |Burst/Gap | | | | - |Discard Metrics| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - - Table 4: Extended Report Blocks - -B.3. Generic RTP Feedback (RTPFB) - - +=======+=================+=================+=========+================+ - |Name |Long Name |Document |Mappable |Comments | - | | | |from QUIC| | - +=======+=================+=================+=========+================+ - |Generic|Generic negative |[RFC4585] |partly |see | - |NACK |acknowledgement | | |Section 8.4.1 | - +-------+-----------------+-----------------+---------+----------------+ - |TMMBR |Temporary Maximum|[RFC5104] |no | | - | |Media Stream Bit | | | | - | |Rate Request | | | | - +-------+-----------------+-----------------+---------+----------------+ - |TMMBN |Temporary Maximum|[RFC5104] |no | | - | |Media Stream Bit | | | | - | |Rate Notification| | | | - +-------+-----------------+-----------------+---------+----------------+ - |RTCP- |RTCP Rapid |[RFC6051] |no | | - |SR-REQ |Resynchronisation| | | | - | |Request | | | | - +-------+-----------------+-----------------+---------+----------------+ - |RAMS |Rapid Acquisition|[RFC6285] |no | | - | |of Multicast | | | | - | |Sessions | | | | - +-------+-----------------+-----------------+---------+----------------+ - |TLLEI |Transport-Layer |[RFC6642] |no? |no way of | - | |Third-Party Loss | | |telling QUIC | - | |Early Indication | | |peer "don't ask | - | | | | |for | - | | | | |retransmission",| - | | | | |but QUIC would | - | | | | |not ask that | - | | | | |anyway, only | - | | | | |RTCP NACK? | - +-------+-----------------+-----------------+---------+----------------+ - |RTCP- |RTCP ECN Feedback|[RFC6679] |partly |see | - |ECN-FB | | | |Section 8.4.2 | - +-------+-----------------+-----------------+---------+----------------+ - |PAUSE- |Media Pause/ |[RFC7728] |no | | - |RESUME |Resume | | | | - +-------+-----------------+-----------------+---------+----------------+ - |DBI |Delay Budget |[_3GPP-TS-26.114]| | | - | |Information (DBI)| | | | - +-------+-----------------+-----------------+---------+----------------+ - |CCFB |RTP Congestion |[RFC8888] |QUIC |see | - | |Control Feedback | |extension|Appendix B.6.2 | - | | | |needed | | - +-------+-----------------+-----------------+---------+----------------+ - - Table 5 - -B.4. Payload-specific RTP Feedback (PSFB) - - Because QUIC is a generic transport protocol, QUIC feedback cannot - replace the following Payload-specific RTP Feedback (PSFB) feedback. - - +=====+============+==============================================+ - |Name |Long Name | Document | - +=====+============+==============================================+ - |PLI |Picture Loss| [RFC4585] | - | |Indication | | - +-----+------------+----------------------------------------------+ - |SLI |Slice Loss | [RFC4585] | - | |Indication | | - +-----+------------+----------------------------------------------+ - |RPSI |Reference | [RFC4585] | - | |Picture | | - | |Selection | | - | |Indication | | - +-----+------------+----------------------------------------------+ - |FIR |Full Intra | [RFC5104] | - | |Request | | - | |Command | | - +-----+------------+----------------------------------------------+ - |TSTR |Temporal- | [RFC5104] | - | |Spatial | | - | |Trade-off | | - | |Request | | - +-----+------------+----------------------------------------------+ - |TSTN |Temporal- | [RFC5104] | - | |Spatial | | - | |Trade-off | | - | |Notification| | - +-----+------------+----------------------------------------------+ - |VBCM |Video Back | [RFC5104] | - | |Channel | | - | |Message | | - +-----+------------+----------------------------------------------+ - |PSLEI|Payload- | [RFC6642] | - | |Specific | | - | |Third-Party | | - | |Loss Early | | - | |Indication | | - +-----+------------+----------------------------------------------+ - |ROI |Video | [_3GPP-TS-26.114] | - | |region-of- | | - | |interest | | - | |(ROI) | | - +-----+------------+----------------------------------------------+ - |LRR |Layer | [I-D.draft-ietf-avtext-lrr-07] | - | |Refresh | | - | |Request | | - | |Command | | - +-----+------------+----------------------------------------------+ - |VP |Viewport | [_3GPP-TS-26.114] | - | |(VP) | | - +-----+------------+----------------------------------------------+ - |AFB |Application | [RFC4585] | - | |Layer | | - | |Feedback | | - +-----+------------+----------------------------------------------+ - |TSRR |Temporal- | [I-D.draft-ietf-avtcore-rtcp-green-metadata] | - | |Spatial | | - | |Resolution | | - | |Request | | - +-----+------------+----------------------------------------------+ - |TSRN |Temporal- | [I-D.draft-ietf-avtcore-rtcp-green-metadata] | - | |Spatial | | - | |Resolution | | - | |Notification| | - +-----+------------+----------------------------------------------+ - - Table 6 - -B.5. RTP Header extensions - - Like the payload-specific feedback packets, QUIC cannot directly - replace the control information in the following header extensions. - RoQ does not place restrictions on sending any RTP header extensions. - However, some extensions, such as Transmission Time offsets [RFC5450] - are used to improve network jitter calculation, which can be done in - QUIC if a timestamp extension is used. - -B.5.1. Compact Header Extensions - - +====================+================+=================+===========+ - |Extension URI |Description |Reference |Mappable | - | | | |from QUIC | - +====================+================+=================+===========+ - |urn:ietf:params:rtp-|Transmission |[RFC5450] |no | - |hdrext:toffset |Time offsets | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Audio Level |[RFC6464] |no | - |hdrext:ssrc-audio- | | | | - |level | | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Splicing |[RFC8286] |no | - |hdrext:splicing- |Interval | | | - |interval | | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|SMPTE time-code |[RFC5484] |no | - |hdrext:smpte-tc |mapping | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Reserved as |[RFC7941] |no | - |hdrext:sdes |base URN for | | | - | |RTCP SDES items | | | - | |that are also | | | - | |defined as RTP | | | - | |compact header | | | - | |extensions. | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Synchronisation |[RFC6051] |no | - |hdrext:ntp-64 |metadata: | | | - | |64-bit | | | - | |timestamp | | | - | |format | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Synchronisation |[RFC6051] |no | - |hdrext:ntp-56 |metadata: | | | - | |56-bit | | | - | |timestamp | | | - | |format | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Encrypted |[RFC6904] |no, but | - |hdrext:encrypt |extension | |maybe | - | |header element | |irrelevant?| - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Mixer-to-client |[RFC6465] |no | - |hdrext:csrc-audio- |audio level | | | - |level |indicators | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:video- |Higher |[_3GPP-TS-26.114]|probably | - |orientation:6 |granularity | |not(?) | - | |(6-bit) | | | - | |coordination of | | | - | |video | | | - | |orientation | | | - | |(CVO) feature, | | | - | |see clause | | | - | |6.2.3 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:video- |Coordination of |[_3GPP-TS-26.114]|probably | - |orientation |video | |not(?) | - | |orientation | | | - | |(CVO) feature, | | | - | |see clause | | | - | |6.2.3 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:roi-sent |Signalling of |[_3GPP-TS-26.114]|probably | - | |the arbitrary | |not(?) | - | |region-of- | | | - | |interest (ROI) | | | - | |information for | | | - | |the sent video, | | | - | |see clause | | | - | |6.2.3.4 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:predefined-|Signalling of |[_3GPP-TS-26.114]|probably | - |roi-sent |the predefined | |not(?) | - | |region-of- | | | - | |interest (ROI) | | | - | |information for | | | - | |the sent video, | | | - | |see clause | | | - | |6.2.3.4 | | | - +--------------------+----------------+-----------------+-----------+ - - Table 7 - -B.5.2. SDES Compact Header Extensions - - +=======================+==================+===========+==========+ - | Extension URI | Description | Reference | Mappable | - | | | | from | - | | | | QUIC | - +=======================+==================+===========+==========+ - | urn:ietf:params:rtp- | Source | [RFC7941] | no | - | hdrext:sdes:cname | Description: | | | - | | Canonical End- | | | - | | Point Identifier | | | - | | (SDES CNAME) | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | RTP Stream | [RFC8852] | no | - | hdrext:sdes:rtp- | Identifier | | | - | stream-id | | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | RTP Repaired | [RFC8852] | no | - | hdrext:sdes:repaired- | Stream | | | - | rtp-stream-id | Identifier | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | CLUE CaptId | [RFC8849] | no | - | hdrext:sdes:CaptId | | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | Media | [RFC9143] | no | - | hdrext:sdes:mid | identification | | | - +-----------------------+------------------+-----------+----------+ - - Table 8 - -B.6. Examples - -B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") - - Considerations for mapping QUIC feedback into _Receiver Reports_ - (PT=201, Name=RR, [RFC3550]) are: - - * _Fraction lost_: When RTP packets are carried in QUIC datagrams, - the fraction of lost packets can be directly inferred from QUIC's - acknowledgments. The calculation SHOULD include all packets up to - the acknowledged RTP packet with the highest RTP sequence number. - Later packets SHOULD be ignored since they may still be in flight - unless other QUIC packets that were sent after the RTP packet were - already acknowledged. - - * _Cumulative lost_: Similar to the fraction of lost packets, the - cumulative loss can be inferred from QUIC's acknowledgments, - including all packets up to the latest acknowledged packet. - - * _Highest Sequence Number received_: In RTCP, this field is a - 32-bit field that contains the highest sequence number a receiver - received in an RTP packet and the count of sequence number cycles - the receiver has observed. A sender sends RTP packets in QUIC - packets and receives acknowledgments for the QUIC packets. By - keeping a mapping from a QUIC packet to the RTP packets - encapsulated in that QUIC packet, the sender can infer the highest - sequence number and number of cycles seen by the receiver from - QUIC acknowledgments. - - * _Interarrival jitter_: If QUIC acknowledgments carry timestamps as - described in [I-D.draft-smith-quic-receive-ts], senders can infer - the interarrival jitter from the arrival timestamps in QUIC - acknowledgments. - - * _Last SR_: Similar to lost packets, the NTP timestamp of the last - received sender report can be inferred from QUIC acknowledgments. - - * _Delay since last SR_: This field is not required when the - receiver reports are entirely replaced by QUIC feedback. - -B.6.2. Congestion Control Feedback ("CCFB") - - RTP _Congestion Control Feedback_ (PT=205, FMT=11, Name=CCFB, - [RFC8888]) contains acknowledgments, arrival timestamps, and ECN - notifications for each received packet. Acknowledgments and ECNs can - be inferred from QUIC as described above. Arrival timestamps can be - added through extended acknowledgment frames as described in - [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts]. - -B.6.3. Extended Report ("XR") - - _Extended Reports_ (PT=207, Name=XR, [RFC3611]) offer an extensible - framework for a variety of different control messages. Some of the - statistics that are defined as extended report blocks can be derived - from QUIC, too. Other report blocks need to be evaluated - individually to determine whether the contained information can be - transmitted using QUIC instead. Table 4 in Appendix B.2 lists - considerations for mapping QUIC feedback to some of the _Extended - Reports_. - -B.6.4. Application Layer Repair and other Control Messages - - While Appendix B.6.1 presented some RTCP packets that can be replaced - by QUIC features, QUIC cannot replace all of the defined RTCP packet - types. This mostly affects RTCP packet types, which carry control - information that is to be interpreted by the RTP application layer - rather than the underlying transport protocol itself. - - * _Sender Reports_ (PT=200, Name=SR, [RFC3550]) are similar to - _Receiver Reports_, as described in Appendix B.6.1. They are sent - by media senders and additionally contain an NTP and an RTP - timestamp and the number of packets and octets transmitted by the - sender. The timestamps can be used by a receiver to synchronize - streams. QUIC cannot provide similar control information since it - does not know about RTP timestamps. A QUIC receiver cannot - calculate the packet or octet counts since it does not know about - lost datagrams. Thus, sender reports are required in RoQ to - synchronize streams at the receiver. The sender reports SHOULD - not contain any receiver report blocks if the information can be - inferred from the QUIC transport as explained in Appendix B.6.1. - - In addition to carrying transmission statistics, RTCP packets can - contain application layer control information that cannot directly be - mapped to QUIC. Examples of this information may include: - - * _Source Description_ (PT=202, Name=SDES) and _Application_ - (PT=204, Name=APP) packet types from [RFC3550], or - - * many of the payload-specific feedback messages (PT=206) defined in - [RFC4585], used to control the codec behavior of the sender. - - Since QUIC does not provide any kind of application layer control - messaging, QUIC feedback cannot be mapped into these RTCP packet - types. If the RTP application needs this information, the RTCP - packet types are used in the same way as they would be used over any - other transport protocol. - -Appendix C. Experimental Results - - An experimental implementation of the mapping described in this - document can be found on Github (https://github.com/mengelbart/rtp- - over-quic). The application implements the RoQ Datagrams mapping and - implements SCReAM congestion control at the application layer. It - can optionally disable the builtin QUIC congestion control (NewReno). - The endpoints only use RTCP for congestion control feedback, which - can optionally be disabled and replaced by the QUIC connection - statistics as described in Section 8.4. - - Experimental results of the implementation can be found on Github - (https://github.com/mengelbart/rtp-over-quic-mininet), too. - -Acknowledgments - - Early versions of this document were similar in spirit to - [I-D.draft-hurst-quic-rtp-tunnelling], although many details differ. - The authors would like to thank Sam Hurst for providing his thoughts - about how QUIC could be used to carry RTP. - - The guidance in Section 5.2 about configuring the number of parallel - unidirectional QUIC streams is based on Section 6.2 of [RFC9114], - with obvious substitutions for RTP/RTCP. - - The authors would like to thank Bernard Aboba, David Schinazi, Lucas - Pardue, Sergio Garcia Murillo, Spencer Dawkins, and Vidhi Goel for - their valuable comments and suggestions contributing to this - document. - -Authors' Addresses - - Jörg Ott - Technical University Munich - Email: ott@in.tum.de - - - Mathis Engelbart - Technical University Munich - Email: mathis.engelbart@gmail.com - - - Spencer Dawkins - Tencent America LLC - Email: spencerdawkins.ietf@gmail.com diff --git a/fix-missing-bracket/index.html b/fix-missing-bracket/index.html deleted file mode 100644 index 959c29b..0000000 --- a/fix-missing-bracket/index.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - mengelbart/rtp-over-quic-draft fix-missing-bracket preview - - - - -

Editor's drafts for fix-missing-bracket branch of mengelbart/rtp-over-quic-draft

-

View saved issues, or the latest GitHub issues and pull requests in the repo.

- - - - - - -
RTP over QUIC (RoQ)plain textsame as main
- - - diff --git a/index.html b/index.html index bb6b739..9152877 100644 --- a/index.html +++ b/index.html @@ -113,14 +113,6 @@

Preview for branch issue-160

diff with main -

Preview for branch remove-media-encoder-terminology

- - - - - - -
RTP over QUIC (RoQ)plain textdiff with main

Preview for branch fix

Preview for branch fix/remove-out-of-context-sentence

@@ -178,14 +170,6 @@

Preview for branch fix/84

diff with main
-

Preview for branch fix-missing-bracket

- - - - - - -
RTP over QUIC (RoQ)plain textdiff with main

Preview for branch issue-175

diff --git a/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.html b/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.html deleted file mode 100644 index 2aaffae..0000000 --- a/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.html +++ /dev/null @@ -1,4605 +0,0 @@ - - - - - - -RTP over QUIC (RoQ) - - - - - - - - - - - - - - -
- - - - - - - - - - -
Internet-DraftRTP over QUIC (RoQ)January 2024
Ott, et al.Expires 2 August 2024[Page]
-
-
-
-
Workgroup:
-
Audio/Video Transport Core Maintenance
-
Internet-Draft:
-
draft-ietf-avtcore-rtp-over-quic-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
J. Ott
-
Technical University Munich
-
-
-
M. Engelbart
-
Technical University Munich
-
-
-
S. Dawkins
-
Tencent America LLC
-
-
-
-
-

RTP over QUIC (RoQ)

-
-

Abstract

-

This document specifies a minimal mapping for encapsulating Real-time Transport -Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. -This mapping is called RTP over QUIC (RoQ). -It also discusses how to leverage state from the QUIC implementation in the -endpoints, in order to reduce the need to exchange RTCP packets and how to -implement congestion control and rate adaptation without relying on RTCP -feedback.

-
-
-

-Discussion Venues -

-

This note is to be removed before publishing as an RFC.

-

Discussion of this document takes place on the - Audio/Video Transport Core Maintenance Working Group mailing list (avt@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/avt/.

-

Source for this draft and an issue tracker can be found at - https://github.com/mengelbart/rtp-over-quic-draft.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 2 August 2024.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

This document specifies a minimal mapping for encapsulating Real-time Transport -Protocol (RTP) [RFC3550] and RTP Control Protocol (RTCP) [RFC3550] packets -within the QUIC protocol ([RFC9000]). -This mapping is called RTP over QUIC (RoQ). -It also discusses how to leverage state -from the QUIC implementation in the endpoints, in order to reduce the need to -exchange RTCP packets, and how to implement congestion control and rate -adaptation without relying on RTCP feedback.

-
-
-

-1.1. Background -

-

The Real-time Transport Protocol (RTP) [RFC3550] is generally used to carry -real-time media for conversational media sessions, such as video conferences, -across the Internet. Since RTP requires real-time delivery and is tolerant to -packet losses, the default underlying transport protocol has been UDP, recently -with DTLS on top to secure the media exchange and occasionally TCP (and possibly -TLS) as a fallback.

-

This specification describes an application usage of QUIC ([RFC9308]). -As a baseline, the specification does not expect more than a standard QUIC implementation -as defined in [RFC8999], [RFC9000], [RFC9001], and [RFC9002], -providing a secure end-to-end transport that is also expected to work well through NATs and firewalls. -Beyond this baseline, real-time applications can benefit from QUIC extensions such as unreliable QUIC datagrams -[RFC9221], which provides additional desirable properties for -real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line -blocking).

-
-
-
-
-

-1.2. Motivations -

-

From time to time, someone asks the reasonable question, "why should anyone implement and deploy RoQ"? This reasonable question deserves a better answer than "because we can". Upon reflection, the following motivations seem useful to state.

-

The motivations in this section are in no particular order, and this reflects the reality that not all implementers and deployers would agree on "the most important motivations".

-
-
-

-1.2.1. "Always-On" Transport-level Authentication and Encryption -

-

Although application-level mechanisms to encrypt RTP and RTCP payloads have existed since the introduction of Secure Real-time Transport Protocol (SRTP) [RFC3711], encryption of RTP and RTCP header fields and contributing sources has only been defined recently (in Cryptex [RFC9335], and both SRTP and Cryptex are optional capabilities for RTP.

-

This is in sharp contrast to "always-on" transport-level encryption in the QUIC protocol, using Transport Layer Security (TLS 1.3) as described in [RFC9001]. QUIC implementations always authenticate the entirety of each packet, and encrypt as much of each packet as is practical, even switching from "long headers", which expose more QUIC header fields needed to establish a connection, to "short headers", which only expose the absolute minimum QUIC header fields needed to identify the connection to the receiver, so that the QUIC payload is presented to the right QUIC application [RFC8999].

-
-
-
-
-

-1.2.2. "Always-On" Internet-Safe Congestion Avoidance -

-

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 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 Section 1.2.5, 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.

    -
    • -
-

Taken as a whole,

-
    -
  • -

    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".

    -
    • -
-
-
-
-
-

-1.2.3. RTP Rate Adaptation Based on 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 Section 7 on rate adaptation, and in Section 8 on replacing RTCP and RTP header extensions with QUIC feedback.

-

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.

-
-
-
-
-

-1.2.4. Path MTU Discovery and RTP Media Coalescence -

-

The minimum Path MTU supported by conformant QUIC implementations is 1200 bytes [RFC9000], and in addition, QUIC implementations allow senders to use either DPLPMTUD ([RFC8899]) or PMTUD ([RFC1191], [RFC8201]) to determine the actual MTU size that the receiver and path between sender and receiver support, which can be even larger.

-

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.

-
-
-
-
-

-1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC Connection -

-

In order to conserve ports, especially at NATs and Firewalls, this specification defines a flow identifier, so that multiple RTP flows, RTCP flows, and non-RTP flows can be distinguished even if they are carried on the same QUIC connection. This is described in more detail in Section 5.1.

-
-
-
-
-

-1.2.6. Exploiting Multiple Connections -

-

Although there is much interest in multiplexing flows on a single QUIC connection as described in Section 1.2.5, QUIC also provides the capability of establishing and validating multiple paths for a single QUIC connection [RFC9000]. Once multiple paths have been validated, a sender can migrate from one path to another with no additional signaling, allowing an endpoint to move from one endpoint address to another without interruption, as long as only a single path is in active use at any point in time.

-

Connection migration may be desireable for a number of reasons, but to give one example, this allows a sender to distinguish between more costly cellular paths and less costly WiFi paths, with no action required from the application.

-
-
-
-
-

-1.2.7. Exploiting New QUIC Capabilities -

-

In addition to connection migration as described in Section 1.2.6, the capability of validating multiple paths for simultaneous active use is under active development in the IETF [I-D.draft-ietf-quic-multipath]. We don't discuss Multipath QUIC further in this document, because the specification hasn't been approved yet, but it's one example of ways that RTP, a mature protocol, can exploit new transport capabilities as they become available.

-
-
-
-
-
-
-

-1.3. What's in Scope for this Specification -

-

This document defines a mapping for RTP and RTCP over QUIC, called RoQ, and describes ways to reduce the -amount of RTCP traffic by leveraging state information readily available within -a QUIC endpoint. This document also describes different options for implementing -congestion control and rate adaptation for RoQ.

-

This specification focuses on providing a secure encapsulation of RTP packets -for transmission over QUIC. The expected usage is wherever RTP is used to carry -media packets, allowing QUIC in place of other transport protocols such as TCP, -UDP, SCTP, DTLS, etc. That is, we expect RoQ to be used in contexts in -which a signaling protocol is used to announce or negotiate a media -encapsulation and the associated transport parameters (such as IP address, port -number). RoQ is not intended as a stand-alone media transport, -although QUIC transport parameters could be statically configured.

-

The above implies that RoQ is targeted at peer-to-peer operation; but -it may also be used in client-server-style settings, e.g., when talking to a -conference server as described in RFC 7667 ([RFC7667]), or, if RoQ -is used to replace RTSP ([RFC7826]), to a media server.

-

An appropriate 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 mechanism, so the application can use a rate adaption mechanism of its choice.

-

Moreover, this document describes how a QUIC implementation and its API can be -extended to improve efficiency of the RoQ protocol operation.

-

RoQ does not impact the usage of RTP Audio Video Profiles (AVP) -([RFC3551]), or any RTP-based mechanisms, even though it may render some of -them unnecessary, e.g., Secure Real-Time Transport Prococol (SRTP) -([RFC3711]) might not be needed, because end-to-end security is already -provided by QUIC, and double encryption by QUIC and by SRTP might have more -costs than benefits. Nor does RoQ limit the use of RTCP-based -mechanisms, even though some information or functions obtained by using RTCP -mechanisms may also be available from the underlying QUIC implementation by -other means.

-

Between two (or more) endpoints, RoQ supports multiplexing multiple -RTP-based media streams within a single QUIC connection and thus using a single -(destination IP address, destination port number, source IP address, source port -number, protocol) 5-tuple.. We note that multiple independent QUIC connections -may be established in parallel using the same destination IP address, -destination port number, source IP address, source port number, protocol) -5-tuple., e.g. to carry different media channels. These connections would be -logically independent of one another.

-
-
-
-
-

-1.4. What's Out of Scope for this Specification -

-

This document does not attempt to enhance QUIC for real-time media or define a -replacement for, or evolution of, RTP. Work to map other media transport -protocols to QUIC is under way elsewhere in the IETF.

-

RoQ is designed for use with point-to-point connections, because QUIC -itself is not defined for multicast operation. The scope of this document is -limited to unicast RTP/RTCP, even though nothing would or should prevent its use -in multicast setups once QUIC supports multicast.

-

RoQ does not define congestion control and rate adaptation algorithms -for use with media. However, Section 7 discusses options for how -congestion control and rate adaptation could be performed at the QUIC and/or at -the RTP layer, and how information available at the QUIC layer could be exposed -via an API for the benefit of RTP layer implementation.

-
    -
  • -

    Editor's note: Need to check whether Section 7 will also -describe the QUIC interface that's being exposed, or if that ends up somewhere -else in the document.

    -
    • -
-

RoQ does not define prioritization mechanisms when handling different -media as those would be dependent on the media themselves and their -relationships. Prioritization is left to the application using RoQ.

-

This document does not cover signaling for session setup. SDP for RoQ -is defined in separate documents such as -[I-D.draft-dawkins-avtcore-sdp-rtp-quic], and can be carried in any signaling -protocol that can carry SDP, including the Session Initiation Protocol (SIP) -([RFC3261]), Real-Time Protocols for Browser-Based Applications (RTCWeb) -([RFC8825]), or WebRTC-HTTP Ingestion Protocol (WHIP) -([I-D.draft-ietf-wish-whip]).

-
-
-
-
-
-
-

-2. Terminology and Notation -

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] -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 Section 7.2, 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:
-
-

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 -a sender from overwhelming the capacity of a path between a sender and a -receiver, causing some outstanding data to be discarded before the receiver can -receive the data and acknowledge it to the sender.

-
-
-
Datagram:
-
-

Datagrams exist in UDP as well as in QUIC's unreliable datagram extension. If not explicitly noted -differently, the term datagram in this document refers to a QUIC Datagram as defined in -[RFC9221].

-
-
-
Delay-based or Low-latency congestion control algorithm:
-
-

A congestion control algorithm that aims at keeping queues, and thus the latency, at intermediary network elements as short as possible. Delay-based congestion control algorithms use, for example, an increasing one-way delay as a signal of congestion.

-
-
-
Endpoint:
-
-

A QUIC server or client that participates in an RoQ session.

-
-
-
Frame:
-
-

A QUIC frame as defined in [RFC9000].

-
-
-
Loss-based congestion control algorithm:
-
-

A congestion control algorithm that uses packet loss, or an Explicit Congestion Notification (ECN) that is interpreted as loss (as in [RFC3168]), as a signal for congestion. Loss-based congestion control algorithms allow senders to send data on a path until packets are dropped by intermediary network elements, which the algorithm treats as a signal of congestion.

-
-
-
QUIC congestion controller:
-
-

A software component of an application's QUIC implementation that implements a congestion control algorithm.

-
-
-
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.

-
-
-
Receiver:
-
-

An endpoint that receives media in RTP packets and may send or receive RTCP packets.

-
-
-
RTP congestion controller:
-
-

A software component of an application's RTP implementation that implements a congestion control algorithm.

-
-
-
Sender:
-
-

An endpoint that sends media in RTP packets and may send or receive RTCP packets.

-
-
-
-

Packet diagrams in this document use the format defined in Section 1.3 of [RFC9000] to -illustrate the order and size of fields.

-
-
-
-
-

-3. Protocol Overview -

-

This document introduces a mapping of the Real-time Transport Protocol (RTP) to -the QUIC transport protocol. RoQ allows the use of QUIC streams and -QUIC datagrams to transport real-time data, and thus, the QUIC -implementation MUST support QUIC's datagram extension, if RTP packets -should be sent over QUIC datagrams.

-

[RFC3550] specifies that RTP sessions need to be transmitted on different -transport addresses to allow multiplexing between them. RoQ uses a -different approach to leverage the advantages of QUIC connections without -managing a separate QUIC connection per RTP session. QUIC does not provide -demultiplexing between different flows on datagrams but suggests that an -application implement a demultiplexing mechanism if required. An example of such -a mechanism would be flow identifiers prepended to each datagram frame as described -in Section 2.1 of [I-D.draft-ietf-masque-h3-datagram]. RoQ uses a -flow identifier to replace the network address and port number to multiplex many -RTP sessions over the same QUIC connection.

-

An RTP application is responsible for determining what to send in an encoded media stream, and how to send that encoded media stream within a targeted bitrate.

-

This document does not mandate how an application determines what to send in an encoded media stream, because decisions about what to send within a targeted bitrate, and how to adapt to changes in the targeted bitrate, can be application and codec-specific. For example, adjusting quantization in response to changing network conditions may work well in many cases, but if what's being shared is video that includes text, maintaining readability is important.

-

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.

-

Since QUIC also collects some metrics about the network's performance, these -metrics can be used to generate the required feedback at the sender-side and -provide it to the rate adaptation algorithm to avoid the additional overhead of the -RTCP stream. This is discussed in more detail in Section 8.

-
-
-

-3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both -

-

This document describes the use of both QUIC streams and QUIC datagrams as RTP encapsulations, but does not take a position on which encapsulation an application should use. Indeed, an application can use both QUIC streams and QUIC datagram encapsulations. The choice of which encapsulation is used is up to the application developer, but it is worth noting the differences.

-

QUIC [RFC9000] was initially designed to carry HTTP [RFC9114] in QUIC streams, and QUIC streams provide what HTTP application developers require - for example, QUIC streams provide a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC streams can be multiplexed over a single QUIC connection, using stream IDs to demultiplex incoming messages.

-

QUIC Datagrams [RFC9221] were developed as a QUIC extension, intended to support applications that do not require reliable delivery of application data. This extension defines two QUIC DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC STREAM frames within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context.

-

There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC streams. The implementation likely presents an API to allow appplications to assign relative priorities, but this is not mandated by the standard and may not be present in all implementations.

-

Because QUIC datagrams are an extension to QUIC, they inherit a great deal of functionality from QUIC (much of which is described in Section 1.2); so much so that it is easier to explain what datagrams do NOT inherit.

-
    -
  • -

    DATAGRAM frames do not provide any explicit flow control signaling. This means that a QUIC receiver may not be able to commit the necessary resources to process incoming frames, but the purpose for DATAGRAM frames is to carry application-level information that can be lost and will not be retransmitted,

    -
    • -
  • -

    DATAGRAM frames do inherit the QUIC connection's congestion controller. This means that although there is no frame-level flow control, DATAGRAM frames may be delayed until the controller allows them to be sent, or dropped (with an optional notification to the sending application). Implementations can also delay sending DATAGRAM frames to maintain consistent packet pacing (as described in Section 7.7 of [RFC9002]), and can allow an application to specify a sending expiration time, but these capabilities are not mandated by the standard and may not be present in all implementations.

    -
    • -
  • -

    DATAGRAM frames cannot be fragmented. They are limited in size by the max_datagram_frame_size transport parameter, and further limited by the max_udp_payload_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints.

    -
    • -
  • -

    DATAGRAM frames belong to a QUIC connection as a whole. There is no QUIC-level way to multiplex/demultiplex DATAGRAM frames within a single QUIC connection. Any multiplexing identifiers must be added, interpreted, and removed by an application, and they will be sent as part of the payload of the DATAGRAM frame itself.

    -
    • -
-

Because QUIC datagrams are an extension to QUIC, a RoQ endpoint cannot count on a RoQ peer supporting that extension. The RoQ endpoint may discover that its peer does not support datagrams while using signaling to set up QUIC connections, but may also discover that its peer has not negotiated the use of this extension during the QUIC handshake. When this happens, the RoQ endpoint needs to make a decision about what to do next.

-
    -
  • -

    If the use of QUIC datagrams was critical, the endpoint can simply close the QUIC connection, allowing someone or something to correct this mismatch, so that QUIC datagrams can be used.

    -
    • -
  • -

    If the use of QUIC datagrams was not critical, the endpoint can negotiate the use of QUIC streams instead.

    -
    • -
-
-
-
-
-

-3.2. Supported RTP Topologies -

-

RoQ only supports some of the RTP topologies described in -[RFC7667]. Most notably, due to QUIC [RFC9000] being a purely IP unicast -protocol at the time of writing, RoQ cannot be used as a transport -protocol for any of the paths that rely on IP multicast in several multicast -topologies (e.g., Topo-ASM, Topo-SSM, Topo-SSM-RAMS).

-

Some "multicast topologies" can include IP unicast paths (e.g., Topo-SSM, -Topo-SSM-RAMS). In these cases, the unicast paths can use RoQ.

-

RTP supports different types of translators and mixers. Whenever a middlebox -such as a translator or a mixer needs to access the content of RTP/RTCP-packets, -the QUIC connection has to be terminated at that middlebox.

-

RoQ streams (see Section 5.2) can support much larger RTP -packet sizes than other transport protocols such as UDP can, which can lead to -problems with transport translators which translate from RoQ to RTP -over a different transport protocol. A similar problem can occur if a translator -needs to translate from RTP over UDP to RoQ datagrams, where the MTU -of a QUIC datagram may be smaller than the MTU of a UDP datagram. In both cases, -the translator may need to rewrite the RTP packets to fit into the smaller MTU -of the other protocol. Such a translator may need codec-specific knowledge to -packetize the payload of the incoming RTP packets in smaller RTP packets.

-

Additional details are provided in the following table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 1
RFC 7667 SectionShortcut NameRTP over QUIC?Comments
- 3.1 -Topo-Point-to-Pointyes 
- 3.2.1.1 -Topo-PtP-RelayyesNote-NAT
- 3.2.1.2 -Topo-Trn-TranslatoryesNote-MTU
Note-SEC
- 3.2.1.3 -Topo-Media-TranslatoryesNote-MTU
- 3.2.2 -Topo-Back-To-BackyesNote-SEC
Note-MTU
Note-MCast
- 3.3.1 -Topo-ASMnoNote-MCast
- 3.3.2 -Topo-SSMpartlyNote-MCast
Note-UCast-MCast
- 3.3.3 -Topo-SSM-RAMSpartlyNote-MCast
Note-MCast-UCast
- 3.4 -Topo-MeshyesNote-MCast
- 3.5.1 -Topo-PtM-Trn-TranslatorpossiblyNote-MCast
Note-MTU
Note-Topo-PtM-Trn-Translator
- 3.6 -Topo-MixerpossiblyNote-MCast
Note-Topo-Mixer
- 3.6.1 -Media-Mixing-MixerpartlyNote-Topo-Mixer
- 3.6.2 -Media-Switching-MixerpartlyNote-Topo-Mixer
- 3.7 -Selective Forwarding MiddleboxyesNote-MCast
Note-Topo-Mixer
- 3.8 -Topo-Video-switch-MCUyesNote-MTU
Note-MCast
Note-Topo-Mixer
- 3.9 -Topo-RTCP-terminating-MCUyesNote-MTU
Note-MCast
Note-Topo-Mixer
- 3.10 -Topo-Split-TerminalyesNote-MCast
- 3.11 -Topo-AsymmetricPossiblyNote-Warn,
Note-MCast,
Note-MTU
-
-
Note-NAT:
-
-

QUIC [RFC9000] doesn't support NAT traversal.

-
-
-
Note-MTU:
-
-

Supported, but may require MTU adaptation.

-
-
-
Note-Sec:
-
-

Note that RoQ provides mandatory security, and other RTP transports -do not. Section 12 describes strategies to prevent the inadvertent -disclosure of RTP sessions to unintended third parties.

-
-
-
Note-MCast:
-
-

QUIC [RFC9000] cannot be used for multicast paths.

-
-
-
Note-UCast-MCast:
-
-

The topology refers to a Distribution Source, which receives and relays RTP -from a number of different media senders via unicast before relaying it to the -receivers via multicast. QUIC can be used between the senders and the -Distribution Source.

-
-
-
Note-MCast-UCast:
-
-

The topology refers to a Burst Source or Retransmission Source, which -retransmits RTP to receivers via unicast. QUIC can be used between the -Retransmission Source and the receivers.

-
-
-
Note-Topo-PtM-Trn-Translator:
-
-

Supports unicast paths between RTP sources and translators.

-
-
-
Note-Topo-Mixer:
-
-

Supports unicast paths between RTP senders and mixers.

-
-
-
Note-Warn:
-
-

Quote from [RFC7667]: This topology is so problematic and it is so easy to -get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this -topology.

-
-
-
-
-
-
-
-
-
-

-4. Connection Establishment and ALPN -

-

QUIC requires the use of ALPN [RFC7301] tokens during connection setup. RoQ -uses "rtp-mux-quic" as ALPN token in the TLS handshake (see also -Section 13.

-

Note that the use of a given RTP profile is not reflected in the ALPN token even -though it could be considered part of the application usage. This is simply -because different RTP sessions, which may use different RTP profiles, may be -carried within the same QUIC connection.

-
    -
  • -

    Editor's note: "rtp-mux-quic" indicates that RTP and other protocols may -be multiplexed on the same QUIC connection using a flow identifier as -described in Section 5. Applications are responsible for negotiation -of protocols in use by appropriate use of a signaling protocol such as SDP.

    -
    • -
-
    -
  • -

    Editor's note: This implies that applications cannot use RoQ as -specified in this document over WebTransport.

    -
    • -
-
-
-

-4.1. Draft version identification -

-
    -
  • -

    RFC Editor's note: Please remove this section prior to publication of a -final version of this document.

    -
    • -
-

RoQ uses the token "rtp-mux-quic" to identify itself in ALPN.

-

Only implementations of the final, published RFC can identify themselves as -"rtp-mux-quic". Until such an RFC exists, implementations MUST NOT identify -themselves using this string.

-

Implementations of draft versions of the protocol MUST add the string "-" and -the corresponding draft number to the identifier. For example, -draft-ietf-avtcore-rtp-over-quic-04 is identified using the string -"rtp-mux-quic-04".

-

Non-compatible experiments that are based on these draft versions MUST append -the string "-" and an experiment name to the identifier.

-
-
-
-
-
-
-

-5. Encapsulation -

-

This section describes the encapsulation of RTP/RTCP packets in QUIC.

-

QUIC supports two transport methods: streams [RFC9000] and -datagrams [RFC9221]. This document specifies mappings of RTP to -both of the transport modes. Senders MAY combine both modes by sending some -RTP/RTCP packets over the same or different QUIC streams and others in QUIC -datagrams.

-

Section 5.1 introduces a multiplexing mechanism that supports multiplexing -RTP, RTCP, and, with some constraints, other non-RTP protocols. Section 5.2 -and Section 5.3 explain the specifics of mapping RTP to QUIC streams and -QUIC datagrams, respectively.

-
-
-

-5.1. Multiplexing -

-

RoQ uses flow identifiers to multiplex different RTP, RTCP, and -non-RTP data streams on a single QUIC connection. A flow identifier is a QUIC -variable-length integer as described in Section 16 of [RFC9000]. Each flow -identifier is associated with a stream of RTP packets, RTCP packets, or a data -stream of a non-RTP protocol.

-

In a QUIC connection using the ALPN token defined in Section 4, every QUIC -datagram and every QUIC stream MUST start with a flow identifier. A peer MUST -NOT send any data in a datagram or stream that is not associated with the flow -identifier which started the datagram or stream.

-

RTP and RTCP packets of different RTP sessions MUST use distinct flow -identifiers. If peers wish to send multiple types of media in a single RTP -session, they MAY do so by following [RFC8860].

-

A single RTP session MAY be associated with one or two flow identifiers. Thus, -it is possible to send RTP and RTCP packets belonging to the same session using -different flow identifiers. RTP and RTCP packets of a single RTP session MAY use -the same flow identifier (following the procedures defined in [RFC5761], or -they MAY use different flow identifiers.

-

The association between flow identifiers and data streams MUST be negotiated -using appropriate signaling. Applications MAY send data using flow identifiers -not associated with any RTP or RTCP stream. If a receiver cannot associate a -flow identifier with any RTP/RTCP or non-RTP flow, it MAY drop the data flow. If -the data flow was sent on a QUIC stream, the receiver SHOULD send a -STOP_SENDING frame with the application error code set to -ROQ_UNKNOWN_FLOW_ID.

-

There are different use cases for sharing the same QUIC connection between RTP -and non-RTP data streams. Peers might use the same connection to exchange -signaling messages or exchange data while sending and receiving media streams. -The semantics of non-RTP datagrams or streams are not in the scope of this -document. Peers MAY use any protocol on top of the encapsulation described in -this document.

-

Flow identifiers introduce some overhead in addition to the header overhead of -RTP/RTCP and QUIC. QUIC variable-length integers require between one and eight -bytes depending on the number expressed. Thus, it is advisable to use low -numbers first and only use higher ones if necessary due to an increased number -of flows.

-
-
-
-
-

-5.2. QUIC Streams -

-

To send RTP/RTCP packets over QUIC streams, a sender MUST open at least one new unidirectional QUIC stream. -RoQ uses unidirectional streams, because there is no -synchronous relationship between sent and received RTP/RTCP packets. A peer that -receives a bidirectional stream with a flow identifier that is associated with -an RTP or RTCP stream, SHOULD stop reading from the stream and send a -STOP_SENDING frame with the application protocol error code set to -ROQ_STREAM_CREATION_ERROR.

-

A RoQ sender MAY open new QUIC streams for different packets using the same flow -identifier, for example, to avoid head-of-line blocking.

-

Because a sender can continue sending on a lower stream number after starting packet transmission on a higher stream number, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and MUST not make assumptions about which RTP sequence numbers are carried in which streams.

-
-
-

-5.2.1. Stream Encapsulation -

-

Figure 1 shows the encapsulation format for RoQ Streams.

-
-
-
-
-Payload {
-  Flow Identifier (i),
-  RTP/RTCP Payload(..) ...,
-}
-
-
-
Figure 1: -RoQ Streams Payload Format -
-
-
-
Flow Identifier:
-
-

Flow identifier to demultiplex different data flows on the same QUIC -connection.

-
-
-
RTP/RTCP Payload:
-
-

Contains the RTP/RTCP payload; see Figure 2

-
-
-
-

The payload in a QUIC stream starts with the flow identifier followed by one or -more RTP/RTCP payloads. All RTP/RTCP payloads sent on a stream MUST belong to -the RTP session with the same flow identifier.

-

Each payload begins with a length field indicating the length of the RTP/RTCP -packet, followed by the packet itself, see Figure 2.

-
-
-
-
-RTP/RTCP Payload {
-  Length(i),
-  RTP/RTCP Packet(..),
-}
-
-
-
Figure 2: -RTP/RTCP payload for QUIC streams -
-
-
-
Length:
-
-

A QUIC variable length integer (see Section 16 of [RFC9000]) describing the -length of the following RTP/RTCP packets in bytes.

-
-
-
RTP/RTCP Packet:
-
-

The RTP/RTCP packet to transmit.

-
-
-
-
-
-
-
-

-5.2.2. Media Frame Cancellation -

-

QUIC uses RESET_STREAM and STOP_SENDING frames to terminate the sending part -of a stream and to request termination of an incoming stream by the sending -peer respectively.

-

A RoQ sender MAY use RESET_STREAM if it knows that a packet, which was not yet -successfully and completely transmitted, is no longer needed.

-

A RoQ receiver that is no longer interested in reading a certain partition of -the media stream MAY signal this to the sending peer using a STOP_SENDING -frame.

-

In both cases, the error code of the RESET_STREAM frame or the STOP_SENDING -frame MUST be set to ROQ_FRAME_CANCELLED.

-

STOP_SENDING is not a request to the sender to stop sending the RTP media -stream, only an indication that a receiver stopped reading the QUIC stream being -used. A sender with additional media frames to send SHOULD continue sending them -on another QUIC stream. Alternatively, new media frames can be sent as QUIC -datagrams (see Section 5.3).

-

Any media frame that has already been sent on the QUIC stream that received the -STOP_SENDING frame, MUST NOT be sent again on the new QUIC stream(s) or -datagrams.

-

Note that an RTP receiver cannot request a reset of only a particular media -frame because the sending QUIC implementation might already have sent data for -the following frame on the same stream. In that case, STOP_SENDING and the -following RESET_STREAM would also drop the following media frame and thus lead -to unintentionally skipping one or more frames.

-
    -
  • -

    Editor's note: A receiver cannot cancel a certain frame but still receive -retransmissions for a frame the was following on the same stream using -STOP_SENDING, because STOP_SENDING does not include an offset which would -allow signaling where retransmissions should continue.

    -
    • -
-

A translator that translates between two endpoints, both connected via QUIC, -MUST forward RESET_STREAM frames received from one end to the other unless it -forwards the RTP packets on QUIC datagrams.

-

Large RTP packets sent on a stream will be fragmented into smaller QUIC frames. -The QUIC frames are transmitted reliably and in order such that a receiving -application can read a complete RTP packet from the stream as long as the stream -is not closed with a RESET_STREAM frame. No retransmission has to be -implemented by the application since QUIC frames lost in transit are -retransmitted by QUIC.

-
-
-
-
-

-5.2.3. Flow control and MAX_STREAMS -

-

In order to permit QUIC streams to open, a RoQ sender SHOULD configure non-zero minimum values for the number of permitted streams and the initial stream flow-control window, based on the number of parallel, or simultaneously active, RTP/RTCP flows. -Endpoints that excessively restrict the number of streams or the flow-control window of these streams will increase the chance that the remote peer reaches the limit early and becomes blocked.

-

Opening new streams for new packets MAY implicitly limit the number of packets -concurrently in transit because the QUIC receiver provides an upper bound of -parallel streams, which it can update using QUIC MAX_STREAMS frames. The number -of packets that have to be transmitted concurrently depends on several factors, -such as the number of RTP streams within a QUIC connection, the bitrate of the -media streams, and the maximum acceptable transmission delay of a given packet. -Receivers are responsible for providing senders enough credit to open new -streams for new packets anytime.

-

As an example, consider a conference scenario -with 20 participants. Each participant receives audio and video streams of every -other participant from a central server. If the sender opens a new QUIC stream -for every frame at 30 frames per second video and 50 frames per second audio, it -will open 1520 new QUIC streams per second. A receiver must provide at least -that many credits for opening new unidirectional streams to the server every -second.

-

In addition, the receiver should also consider the requirements of -protocols into account that are multiplexed with RTP, including RTCP and data -streams. These considerations may also be relevant when implementing signaling -since it may be necessary to inform the receiver about how fast and how many -stream credits it will have to provide to the media-sending peer.

-
-
-
-
-
-
-

-5.3. QUIC Datagrams -

-

Senders can also transmit RTP packets in QUIC datagrams. QUIC datagrams are an -extension to QUIC described in [RFC9221]. QUIC datagrams can only be used if -the use of the datagram extension was successfully negotiated during the QUIC handshake. -If the QUIC extension was signaled using a signaling protocol, but that -extension was not negotiated during the QUIC handshake, a peer MAY close the -connection with the ROQ_EXPECTATION_UNMET error code.

-

QUIC datagrams preserve frame boundaries. Thus, a single RTP packet can be -mapped to a single QUIC datagram without additional framing. Senders SHOULD -consider the header overhead associated with QUIC datagrams and ensure that the -RTP/RTCP packets, including their payloads, flow identifier, QUIC, and IP -headers, will fit into path MTU.

-

Figure 3 shows the encapsulation format for RoQ -Datagrams.

-
-
-
-
-Payload {
-  Flow Identifier (i),
-  RTP/RTCP Packet (..),
-}
-
-
-
Figure 3: -RoQ Datagram Payload Format -
-
-
-
Flow Identifier:
-
-

Flow identifier to demultiplex different data flows on the same QUIC -connection.

-
-
-
RTP/RTCP Packet:
-
-

The RTP/RTCP packet to transmit.

-
-
-
-

RoQ senders need to be aware that QUIC uses the concept of QUIC frames. -Different kinds of QUIC frames are used for different application and control -data types. A single QUIC packet can contain more than one QUIC frame, -including, for example, QUIC stream or datagram frames carrying application data -and acknowledgement frames carrying QUIC acknowledgements, as long as the -overall size fits into the MTU. One implication is that the number of packets a -QUIC stack transmits depends on whether it can fit acknowledgement and datagram -frames in the same QUIC packet. Suppose the application creates many datagram -frames that fill up the QUIC packet. In that case, the QUIC stack might have to -create additional packets for acknowledgement- (and possibly other control-) -frames. The additional overhead could, in some cases, be reduced if the -application creates smaller RTP packets, such that the resulting datagram frame -can fit into a QUIC packet that can also carry acknowledgement frames.

-

Since QUIC datagrams are not retransmitted on loss (see also -Section 8.4 for loss signaling), if an application wishes to -retransmit lost RTP packets, the retransmission has to be implemented by the -application. RTP retransmissions can be done in the same RTP session or a -separate RTP session [RFC4588] and the flow identifier MUST be set to the -flow identifier of the RTP session in which the retransmission happens.

-
-
-
-
-
-
-

-6. Connection Shutdown -

-

Either peers MAY close the connection for variety of reasons. If one of the -peers wants to close the RoQ connection, the peer can use a QUIC -CONNECTION_CLOSE frame with one of the error codes defined in -Section 9.

-
-
-
-
-

-7. Congestion Control and Rate Adaptation -

-

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.

-

This document discusses aspects of transport level congestion control in -Section 7.1 and application layer rate control in -Section 7.2. It does not mandate any specific -congestion control algorithm for QUIC or rate adaptation algorithm for RTP.

-

This document also gives guidance about avoiding problems with nested -congestion controllers in Section 7.2.

-

This document also discusses congestion control implications of using shared or -multiple separate QUIC connections to send and receive multiple independent data -streams in Section 7.3.

-
-
-

-7.1. Congestion Control at the Transport Layer -

-

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.

-

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 3.1.

-

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 Appendix A. 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 Section 7.2.

-

It is assumed that the congestion controller in use provides a pacing mechanism -to determine when a packet can be sent to avoid bursts and minimize variation in -inter-packet arrival times. 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.

-
-
-
-
-

-7.2. Rate Adaptation at the 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.

-

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 being 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 Section 8 and Section 10.

-
-
-
-
-

-7.3. Sharing QUIC connections -

-

Two endpoints may establish channels in order to exchange more than one type of -data simultaneously. The channels can be intended to carry real-time RTP data or -other non-real-time data. This can be realized in different ways.

-
    -
  • -

    One straightforward solution is to establish multiple QUIC connections, one -for each channel, whether the channel is used for real-time media or -non-real-time data. This is a straightforward solution, but has the -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.

    -
    • -
-

In both cases, the congestion controllers can be chosen to match the demands of -the respective channels and the different QUIC connections will compete for the -same resources in the network. No local prioritization of data across the -different (types of) channels would be necessary.

-

Although it is possible to multiplex (all or a subset of) real-time and -non-real-time channels onto a single, shared QUIC connection, which can be done -by using the flow identifier described in Section 5.1, the underlying QUIC -implementation will likely use the same congestion controller for all channels -in the shared QUIC connection. For this reason, applications multiplexing -multiple streams in one connection SHOULD implement some form of stream -prioritization or bandwidth allocation.

-
-
-
-
-
-
-

-8. Replacing RTCP and RTP Header Extensions with QUIC Feedback -

-

Because RTP has so often used UDP as its underlying transport protocol, and -receiving little or no feedback from UDP, RTP implementations rely on feedback -from the RTP Control Protocol (RTCP) so that RTP senders and receivers can -exchange control information to monitor connection statistics and to identify -and synchronize streams.

-

Because QUIC provides transport-level feedback, it can replace at least some RTP -transport-level feedback with current QUIC feedback [RFC9000]. In addition, -RTP-level feedback that is not available in QUIC by default can potentially be -replaced with generally useful QUIC extensions in the future as described in -Appendix B.6.

-

When statistics contained in RTCP packets are also available from QUIC or can be -derived from statistics available from QUIC, it is desirable to provide these -statistics at only one protocol layer. This avoids consumption of bandwidth to -deliver equivalent control information at more than one level of the protocol -stack. QUIC and RTCP both have rules describing when certain signals have to be -sent. This document does not change any of the rules described by either -protocol, but specifies a baseline for replacing some of the RTCP packet types -by mapping the contents to QUIC connection statistics, and reducing the -transmission frequency and bandwidth requirements for some RTCP packet types -that must be transmitted periodically. Future documents can extend this mapping -for other RTCP format types, and can make use of new QUIC extensions that become -available over time. The mechanisms described in this section can enhance the -statistics provided by RTCP and reduce the bandwidth overhead required by -certain RTCP packets. Applications using RoQ need to adhere to the rules for -RTCP feedback given by [RFC3550] and the RTP profiles in use.

-

Most statements about "QUIC" in Section 8 are applicable to both RTP -encapsulated in QUIC streams and RTP encapsulated in QUIC datagrams. The -differences are described in Section 8.1 and Section 8.2.

-
    -
  • -

    Editor's Note: Additional discussion of bandwidth minimization could go in -this section, or in an earlier proposed section on motivations for defining -and deploying RoQ.

    -
    • -
-

While RoQ places no restrictions on applications sending RTCP, this document -assumes that the reason an implementor chooses to support RoQ is to obtain -benefits beyond what's available when RTP uses UDP as its underlying transport -layer. It is RECOMMENDED to expose relevant information from the QUIC layer to -the application instead of exchanging additional RTCP packets, where applicable.

-

Section 8.4 discusses what information can be exposed from the -QUIC connection layer to reduce the RTCP overhead.

-
-
-

-8.1. RoQ Datagrams -

-

QUIC Datagrams are ack-eliciting packets, which means that an acknowledgment is -triggered when a datagram frame is received. Thus, a sender can assume that an -RTP packet arrived at the receiver or was lost in transit, using the QUIC -acknowledgments of QUIC Datagram frames. In the following, an RTP packet is -regarded as acknowledged when the QUIC Datagram frame that carried the RTP -packet was acknowledged.

-
-
-
-
-

-8.2. RoQ Streams -

-

For RTP packets that are sent over QUIC streams, an RTP packet is considered -acknowledged after all frames that carried fragments of the RTP packet were -acknowledged.

-

When QUIC Streams are used, the application should be aware that the direct -mapping proposed below may not reflect the real characteristics of the network. -RTP packet loss can seem lower than actual packet loss due to QUIC's automatic -retransmissions. Similarly, timing information might be incorrect due to -retransmissions.

-
-
-
-
-

-8.3. Multihop Topologies -

-

In some topologies, RoQ may be used on only some of the links between multiple -session participants. Other links may be using RTP over UDP, or over some other -supported RTP encapsulation protocol, and some participants might be using -implementations that don't support RoQ at all. These participants will not be -able to infer feedback from QUIC, and they may receive less RTCP feedback than -expected. On the other hand, participants using RoQ might not be aware that -other participants are not using RoQ and send as little RTCP as possible since -they assume their RoQ peer will be able to infer statistics from QUIC. There are -two ways to solve this problem: if the middlebox translating between RoQ and RTP -over other RTP transport protocols such as UDP or TCP provides Back-to-Back RTP -sessions as described in Section 3.2.2 of [RFC7667], this middlebox can add -RTCP packets for the participants not using RoQ by using the statistics the -middlebox gets from QUIC and the mappings described in the following sections. -If the middlebox does not provide Back-to-Back RTP sessions, participants may -use additional signalling to let the RoQ participants know what RTCP is -required.

-
-
-
-
-

-8.4. Feedback Mappings -

-

This section explains how some of the RTCP packet types that are used to signal -reception statistics can be replaced by equivalent statistics that are already -collected by QUIC. The following list explains how this mapping can be achieved -for the individual fields of different RTCP packet types.

-

The list of RTCP packets in this section is not exhaustive, and similar -considerations SHOULD be taken into account before exchanging any other type of -RTCP control packets using RoQ.

-

A more thorough analysis of RTCP Control Packet Types (in Appendix B.1), -Generic RTP Feedback (RTPFB) (in Appendix B.3), Payload-specific RTP -Feedback (PSFB) (in Appendix B.4), Extended Reports (in -Appendix B.2), and RTP Header Extensions (in Appendix B.5), -including the information that cannot be mapped from QUIC.

-
-
-

-8.4.1. Negative Acknowledgments ("NACK") -

-

Generic Negative Acknowledgments (PT=205, FMT=1, Name=Generic NACK, -[RFC4585]) contain information about RTP packets which the receiver -considered lost. Section 6.2.1. of [RFC4585] recommends using this feature -only if the underlying protocol cannot provide similar feedback. QUIC does not -provide negative acknowledgments but can detect lost packets based on the Gap -numbers contained in QUIC ACK frames (Section 6 of [RFC9002]).

-
-
-
-
-

-8.4.2. ECN Feedback ("ECN") -

-

ECN Feedback (PT=205, FMT=8, Name=RTCP-ECN-FB, [RFC6679]) packets -report the count of observed ECN-CE marks. [RFC6679] defines two RTCP -reports, one packet type (with PT=205 and FMT=8), and a new report block for -the extended reports, which are listed above. QUIC supports ECN reporting -through acknowledgments. If the QUIC connection supports ECN, the reporting of -ECN counts SHOULD be done using QUIC acknowledgments rather than RTCP ECN -feedback reports.

-
-
-
-
-

-8.4.3. Goodbye Packets ("BYE") -

-

RTP session participants can use Goodbye RTCP packets (PT=203, Name=BYE, -[RFC3550]), to indicate that a source is no longer active. If the participant -is also going to close the QUIC connection, the BYE packet can be replaced by -a QUIC CONNECTION_CLOSE frame. In this case, the reason for leaving can be -transmitted in QUIC's CONNECTION_CLOSE Reason Phrase. However, if the -participant wishes to use this QUIC connection for any other multiplexed -traffic, the participant has to use the BYE packet because the QUIC -CONNECTION_CLOSE would close the entire QUIC connection for all other QUIC -streams and datagrams.

-
-
-
-
-
-
-
-
-

-9. Error Handling -

-

The following error codes are defined for use when abruptly terminating streams, -aborting reading of streams, or immediately closing RoQ connections.

-
-
ROQ_NO_ERROR (0x00):
-
-

No error. This is used when the connection or stream needs to be closed, but -there is no error to signal.

-
-
-
ROQ_GENERAL_ERROR (0x01):
-
-

An error that does not match a more specific error code occured.

-
-
-
ROQ_INTERNAL_ERROR (0x02):
-
-

An internal error has occured in the RoQ stack.

-
-
-
ROQ_PACKET_ERROR (0x03):
-
-

Invalid payload format, e.g., length does not match packet, invalid flow id -encoding, non-RTP on RTP-flow ID, etc.

-
-
-
ROQ_STREAM_CREATION_ERROR (0x04):
-
-

The endpoint detected that its peer created a stream that violates the ROQ protocol.

-
-
-
ROQ_FRAME_CANCELLED (0x05):
-
-

A receiving endpoint is using STOP_SENDING on the current stream to request -new frames be sent on new streams. Similarly, a sender notifies a receiver that -retransmissions of a frame were stopped using RESET_STREAM and new frames will -be sent on new streams.

-
-
-
ROQ_UNKNOWN_FLOW_ID (0x06):
-
-

An endpoint was unable to handle a flow identifier, e.g., because it was not -signalled or because the endpoint does not support multiplexing using arbitrary -flow identifiers.

-
-
-
ROQ_EXPECTATION_UNMET (0x07):
-
-

Expectiations of the QUIC transport set by RoQ out-of-band signalling were not -met by the QUIC connection.

-
-
-
-
-
-
-
-

-10. API Considerations -

-

The mapping described in the previous sections poses some interface requirements -for the QUIC implementation. Although RoQ works without these requirements, some -optimizations regarding rate adaptation and RTCP mapping require certain -functionalities to be exposed to the application.

-

Each item in the following list can be considered individually. Any exposed -information or function can be used by RoQ regardless of whether the other items -are available. Thus, RoQ does not depend on the availability of all of the -listed features but can apply different optimizations depending on the -functionality exposed by the QUIC implementation.

-
    -
  • -

    Maximum Datagram Size: The maximum datagram size that the QUIC connection -can transmit on the network path to the QUIC receiver. If a RoQ sender using -datagrams does not know the maximum datagram size for the path to the RoQ -receiver, there are only two choices - either use heuristics to limit the size -of RoQ messages, or be prepared to lose RoQ messages that were too large to be -carried through the network path and delivered to the RoQ receiver.

    -
    • -
  • -

    Datagram Acknowledgment and Loss: Section 5.2 of [RFC9221] allows QUIC -implementations to notify the application that a QUIC Datagram was -acknowledged or that it believes a datagram was lost. Given the datagram -acknowledgments and losses, the application can deduce which RTP packets -arrived at the receiver and which were lost (see also Section 8.1).

    -
    • -
  • -

    Stream States: The stream states include which parts of the data sent on a -stream were successfully delivered and which are still outstanding to be sent -or retransmitted. If an application keeps track of the RTP packets sent on a -stream, their respective sizes, and in which order they were transmitted, it -can infer which RTP packets were acknowledged according to the definition in -Section 8.2.

    -
    • -
  • -

    Arrival timestamps: If the QUIC connection uses a timestamp extension like -[I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts], the -arrival timestamps or one-way delays can support the application as described -in Section 8 and Section 7.

    -
    • -
  • -

    Bandwidth Estimation: If a bandwidth estimation is available in the QUIC -implementation, exposing it avoids the implementation of an additional -bandwidth estimation algorithm in the application.

    -
    • -
  • -

    ECN: If ECN marks are available, they can support the bandwidth estimation -of the application if necessary.

    -
    • -
-
-
-
-
-

-11. Discussion -

-
-
-

-11.1. Impact of Connection Migration -

-

RTP sessions are characterized by a continuous flow of packets into either or -both directions. A connection migration may lead to pausing media -transmission until reachability of the peer under the new address is validated. -This may lead to short breaks in media delivery in the order of RTT and, if -RTCP is used for RTT measurements, may cause spikes in observed delays. -Application layer congestion control mechanisms (and also packet repair schemes -such as retransmissions) need to be prepared to cope with such spikes.

-

If a QUIC connection is established via a signaling channel, this signaling -may have involved Interactive Connectivity Establishment (ICE) exchanges to -determine and choose suitable (IP address, port number) pairs for the QUIC -connection. Subsequent address change events may be noticed by QUIC via its -connection migration handling and/or at the ICE or other application layer, -e.g., by noticing changing IP addresses at the network interface. This may -imply that the two signaling and data "layers" get (temporarily) out of sync.

-
    -
  • -

    Editor's Note: It may be desirable that the API provides an indication -of connection migration event for either case.

    -
    • -
-
-
-
-
-

-11.2. 0-RTT considerations -

-

For repeated connections between peers, the initiator of a QUIC connection can -use 0-RTT data for both QUIC streams and datagrams. As such packets are subject to -replay attacks, applications shall carefully specify which data types and operations -are allowed. 0-RTT data may be beneficial for use with RoQ to reduce the -risk of media clipping, e.g., at the beginning of a conversation.

-

This specification defines carrying RTP on top of QUIC and thus does not finally -define what the actual application data are going to be. RTP typically carries -ephemeral media contents that is rendered and possibly recorded but otherwise -causes no side effects. Moreover, the amount of data that can be carried as 0-RTT -data is rather limited. But it is the responsibility of the respective application -to determine if 0-RTT data is permissible.

-
    -
  • -

    Editor's Note: Since the QUIC connection will often be created in the context -of an existing signaling relationship (e.g., using WebRTC or SIP), specific 0-RTT -keying material could be exchanged to prevent replays across sessions. Within -the same connection, replayed media packets would be discarded as duplicates by -the receiver.

    -
    • -
-
-
-
-
-
-
-

-12. Security Considerations -

-

RoQ is subject to the security considerations of RTP described in -Section 9 of [RFC3550] and the security considerations of any RTP profile in -use.

-

The security considerations for the QUIC protocol and datagram extension -described in Section 21 of [RFC9000], Section 9 of [RFC9001], Section 8 of [RFC9002] and Section 6 of [RFC9221] also apply to RoQ.

-

Note that RoQ provides mandatory security, and other RTP transports do -not. In order to prevent the inadvertent disclosure of RTP sessions to -unintended third parties, RTP topologies described in Section 3.2 that -include middleboxes supporting both RoQ and non-RoQ paths -MUST forward RTP packets on non-RoQ paths using a secure AVP profile -([RFC3711], [RFC4585], or another AVP profile providing equivalent -RTP-level security), whether or not RoQ senders are using a secure AVP -profile for those RTP packets.

-
-
-
-
-

-13. IANA Considerations -

-

This document registers a new ALPN protocol ID (in Section 13.1) and creates a -new registry that manages the assignment of error code points in RoQ (in -Section 13.2).

-
-
-

-13.1. Registration of a RoQ Identification String -

-

This document creates a new registration for the identification of RoQ -in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry -[RFC7301].

-

The "rtp-mux-quic" string identifies RoQ:

-
-
Protocol:
-
-

RTP over QUIC (RoQ)

-
-
-
Identification Sequence:
-
-

0x72 0x74 0x70 0x2D 0x6F 0x76 0x65 0x72 0x2D 0x71 0x75 0x69 0x63 ("rtp-mux-quic")

-
-
-
Specification:
-
-

This document

-
-
-
-
-
-
-
-

-13.2. RoQ Error Codes Registry -

-

This document establishes a registry for RoQ error codes. The "RTP over QUIC -(RoQ) Error Codes" registry manages a 62-bit space and is listed under the -"Real-Time Transport Protocol (RTP) Parameters" heading.

-

The new error codes registry created in this document operates under the QUIC -registration policy documented in Section 22.1 of [RFC9000]. This registry -includes the common set of fields listed in Section 22.1.1 of [RFC9000].

-

Permanent registrations in this registry are assigned using the Specification -Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in -hexadecimal; inclusive), which are assigned using Standards Action or IESG -Approval as defined in Sections 4.9 and 4.10 of [RFC8126].

-

Registrations for error codes are required to include a description of the error -code. An expert reviewer is advised to examine new registrations for possible -duplication or interaction with existing error codes.

-

In addition to common fields as described in Section Section 22.1 of [RFC9000], this registry includes two additional fields. Permanent -registrations in this registry MUST include the following fields:

-
-
Name:
-
-

A name for the error code.

-
-
-
Description:
-
-

A brief description of the error code semantics, which MAY be a summary if a -specification reference is provided.

-
-
-
-

The initial allocations in this registry are all assigned permanent status and -list a change controller of the IETF and a contact of the AVTCORE working group -(avt@ietf.org).

-

The entries in Table 2 are registered by this document.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 2: -Initial RoQ Error Codes -
ValueNameDescriptionSpecification
0x00ROQ_NO_ERRORNo Error - Section 9 -
0x01ROQ_GENERAL_ERRORGeneral error - Section 9 -
0x02ROQ_INTERNAL_ERRORInternal Error - Section 9 -
0x03ROQ_PACKET_ERRORInvalid payload format - Section 9 -
0x04ROQ_STREAM_CREATION_ERRORInvalid stream type - Section 9 -
0x05ROQ_FRAME_CANCELLEDFrame cancelled - Section 9 -
0x06ROQ_UNKNOWN_FLOW_IDUnknown Flow ID - Section 9 -
0x07ROQ_EXPECTATION_UNMETExternally signalled requirement unmet - Section 9 -
-
-
-
-
-
-
-

-14. References -

-
-
-

-14.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC3550]
-
-Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, , <https://www.rfc-editor.org/rfc/rfc3550>.
-
-
[RFC3551]
-
-Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, , <https://www.rfc-editor.org/rfc/rfc3551>.
-
-
[RFC3611]
-
-Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, , <https://www.rfc-editor.org/rfc/rfc3611>.
-
-
[RFC4585]
-
-Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, , <https://www.rfc-editor.org/rfc/rfc4585>.
-
-
[RFC4588]
-
-Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, , <https://www.rfc-editor.org/rfc/rfc4588>.
-
-
[RFC6679]
-
-Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, , <https://www.rfc-editor.org/rfc/rfc6679>.
-
-
[RFC7301]
-
-Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
-
-
[RFC7667]
-
-Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, , <https://www.rfc-editor.org/rfc/rfc7667>.
-
-
[RFC768]
-
-Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/rfc/rfc768>.
-
-
[RFC8126]
-
-Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC8298]
-
-Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, , <https://www.rfc-editor.org/rfc/rfc8298>.
-
-
[RFC8698]
-
-Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media", RFC 8698, DOI 10.17487/RFC8698, , <https://www.rfc-editor.org/rfc/rfc8698>.
-
-
[RFC8836]
-
-Jesup, R. and Z. Sarker, Ed., "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, , <https://www.rfc-editor.org/rfc/rfc8836>.
-
-
[RFC8888]
-
-Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, , <https://www.rfc-editor.org/rfc/rfc8888>.
-
-
[RFC8999]
-
-Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, , <https://www.rfc-editor.org/rfc/rfc8999>.
-
-
[RFC9000]
-
-Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
-
-
[RFC9001]
-
-Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/rfc/rfc9001>.
-
-
[RFC9002]
-
-Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, , <https://www.rfc-editor.org/rfc/rfc9002>.
-
-
[RFC9221]
-
-Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, , <https://www.rfc-editor.org/rfc/rfc9221>.
-
-
-
-
-
-
-

-14.2. Informative References -

-
-
[I-D.draft-dawkins-avtcore-sdp-rtp-quic]
-
-Dawkins, S., "SDP Offer/Answer for RTP using QUIC as Transport", Work in Progress, Internet-Draft, draft-dawkins-avtcore-sdp-rtp-quic-00, , <https://datatracker.ietf.org/doc/html/draft-dawkins-avtcore-sdp-rtp-quic-00>.
-
-
[I-D.draft-huitema-quic-ts]
-
-Huitema, C., "Quic Timestamps For Measuring One-Way Delays", Work in Progress, Internet-Draft, draft-huitema-quic-ts-08, , <https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts-08>.
-
-
[I-D.draft-hurst-quic-rtp-tunnelling]
-
-Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, , <https://datatracker.ietf.org/doc/html/draft-hurst-quic-rtp-tunnelling-01>.
-
-
[I-D.draft-ietf-avtcore-rtcp-green-metadata]
-
-He, Y., Herglotz, C., and E. Francois, "RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution", Work in Progress, Internet-Draft, draft-ietf-avtcore-rtcp-green-metadata-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtcp-green-metadata-02>.
-
-
[I-D.draft-ietf-avtext-lrr-07]
-
-Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", Work in Progress, Internet-Draft, draft-ietf-avtext-lrr-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07>.
-
-
[I-D.draft-ietf-masque-h3-datagram]
-
-Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", Work in Progress, Internet-Draft, draft-ietf-masque-h3-datagram-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-11>.
-
-
[I-D.draft-ietf-quic-ack-frequency]
-
-Iyengar, J., Swett, I., and M. Kühlewind, "QUIC Acknowledgement Frequency", Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-07>.
-
-
[I-D.draft-ietf-quic-multipath]
-
-Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-06>.
-
-
[I-D.draft-ietf-quic-reliable-stream-reset]
-
-Seemann, M. and K. Oku, "Reliable QUIC Stream Resets", Work in Progress, Internet-Draft, draft-ietf-quic-reliable-stream-reset-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-reliable-stream-reset-05>.
-
-
[I-D.draft-ietf-rmcat-gcc]
-
-Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real-Time Communication", Work in Progress, Internet-Draft, draft-ietf-rmcat-gcc-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02>.
-
-
[I-D.draft-ietf-wish-whip]
-
-Murillo, S. G. and A. Gouaillard, "WebRTC-HTTP ingestion protocol (WHIP)", Work in Progress, Internet-Draft, draft-ietf-wish-whip-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-wish-whip-12>.
-
-
[I-D.draft-smith-quic-receive-ts]
-
-Smith, C. and I. Swett, "QUIC Extension for Reporting Packet Receive Timestamps", Work in Progress, Internet-Draft, draft-smith-quic-receive-ts-00, , <https://datatracker.ietf.org/doc/html/draft-smith-quic-receive-ts-00>.
-
-
[I-D.draft-thomson-quic-enough]
-
-Thomson, M., "Signaling That a QUIC Receiver Has Enough Stream Data", Work in Progress, Internet-Draft, draft-thomson-quic-enough-00, , <https://datatracker.ietf.org/doc/html/draft-thomson-quic-enough-00>.
-
-
[RFC1122]
-
-Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.
-
-
[RFC1191]
-
-Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, , <https://www.rfc-editor.org/rfc/rfc1191>.
-
-
[RFC3168]
-
-Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
-
-
[RFC3261]
-
-Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, , <https://www.rfc-editor.org/rfc/rfc3261>.
-
-
[RFC3711]
-
-Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
-
-
[RFC5093]
-
-Hunt, G., "BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)", RFC 5093, DOI 10.17487/RFC5093, , <https://www.rfc-editor.org/rfc/rfc5093>.
-
-
[RFC5104]
-
-Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, , <https://www.rfc-editor.org/rfc/rfc5104>.
-
-
[RFC5450]
-
-Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, , <https://www.rfc-editor.org/rfc/rfc5450>.
-
-
[RFC5484]
-
-Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, DOI 10.17487/RFC5484, , <https://www.rfc-editor.org/rfc/rfc5484>.
-
-
[RFC5725]
-
-Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, , <https://www.rfc-editor.org/rfc/rfc5725>.
-
-
[RFC5760]
-
-Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, , <https://www.rfc-editor.org/rfc/rfc5760>.
-
-
[RFC5761]
-
-Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, , <https://www.rfc-editor.org/rfc/rfc5761>.
-
-
[RFC6051]
-
-Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, , <https://www.rfc-editor.org/rfc/rfc6051>.
-
-
[RFC6284]
-
-Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, , <https://www.rfc-editor.org/rfc/rfc6284>.
-
-
[RFC6285]
-
-Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, , <https://www.rfc-editor.org/rfc/rfc6285>.
-
-
[RFC6332]
-
-Begen, A. and E. Friedrich, "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 6332, DOI 10.17487/RFC6332, , <https://www.rfc-editor.org/rfc/rfc6332>.
-
-
[RFC6464]
-
-Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, , <https://www.rfc-editor.org/rfc/rfc6464>.
-
-
[RFC6465]
-
-Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, , <https://www.rfc-editor.org/rfc/rfc6465>.
-
-
[RFC6582]
-
-Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, , <https://www.rfc-editor.org/rfc/rfc6582>.
-
-
[RFC6642]
-
-Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report", RFC 6642, DOI 10.17487/RFC6642, , <https://www.rfc-editor.org/rfc/rfc6642>.
-
-
[RFC6776]
-
-Clark, A. and Q. Wu, "Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block", RFC 6776, DOI 10.17487/RFC6776, , <https://www.rfc-editor.org/rfc/rfc6776>.
-
-
[RFC6798]
-
-Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting", RFC 6798, DOI 10.17487/RFC6798, , <https://www.rfc-editor.org/rfc/rfc6798>.
-
-
[RFC6843]
-
-Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting", RFC 6843, DOI 10.17487/RFC6843, , <https://www.rfc-editor.org/rfc/rfc6843>.
-
-
[RFC6904]
-
-Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, , <https://www.rfc-editor.org/rfc/rfc6904>.
-
-
[RFC6958]
-
-Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting", RFC 6958, DOI 10.17487/RFC6958, , <https://www.rfc-editor.org/rfc/rfc6958>.
-
-
[RFC6990]
-
-Huang, R., Wu, Q., Asaeda, H., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting", RFC 6990, DOI 10.17487/RFC6990, , <https://www.rfc-editor.org/rfc/rfc6990>.
-
-
[RFC7002]
-
-Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting", RFC 7002, DOI 10.17487/RFC7002, , <https://www.rfc-editor.org/rfc/rfc7002>.
-
-
[RFC7003]
-
-Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, , <https://www.rfc-editor.org/rfc/rfc7003>.
-
-
[RFC7004]
-
-Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting", RFC 7004, DOI 10.17487/RFC7004, , <https://www.rfc-editor.org/rfc/rfc7004>.
-
-
[RFC7005]
-
-Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, , <https://www.rfc-editor.org/rfc/rfc7005>.
-
-
[RFC7097]
-
-Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets", RFC 7097, DOI 10.17487/RFC7097, , <https://www.rfc-editor.org/rfc/rfc7097>.
-
-
[RFC7243]
-
-Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, , <https://www.rfc-editor.org/rfc/rfc7243>.
-
-
[RFC7244]
-
-Asaeda, H., Wu, Q., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting", RFC 7244, DOI 10.17487/RFC7244, , <https://www.rfc-editor.org/rfc/rfc7244>.
-
-
[RFC7266]
-
-Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting", RFC 7266, DOI 10.17487/RFC7266, , <https://www.rfc-editor.org/rfc/rfc7266>.
-
-
[RFC7272]
-
-van Brandenburg, R., Stokking, H., van Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, , <https://www.rfc-editor.org/rfc/rfc7272>.
-
-
[RFC7294]
-
-Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications", RFC 7294, DOI 10.17487/RFC7294, , <https://www.rfc-editor.org/rfc/rfc7294>.
-
-
[RFC7380]
-
-Tong, J., Bi, C., Ed., Even, R., Wu, Q., Ed., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting", RFC 7380, DOI 10.17487/RFC7380, , <https://www.rfc-editor.org/rfc/rfc7380>.
-
-
[RFC7509]
-
-Huang, R. and V. Singh, "RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics", RFC 7509, DOI 10.17487/RFC7509, , <https://www.rfc-editor.org/rfc/rfc7509>.
-
-
[RFC7728]
-
-Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, , <https://www.rfc-editor.org/rfc/rfc7728>.
-
-
[RFC7826]
-
-Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, , <https://www.rfc-editor.org/rfc/rfc7826>.
-
-
[RFC7867]
-
-Huang, R., "RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications", RFC 7867, DOI 10.17487/RFC7867, , <https://www.rfc-editor.org/rfc/rfc7867>.
-
-
[RFC7941]
-
-Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, , <https://www.rfc-editor.org/rfc/rfc7941>.
-
-
[RFC8015]
-
-Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics", RFC 8015, DOI 10.17487/RFC8015, , <https://www.rfc-editor.org/rfc/rfc8015>.
-
-
[RFC8083]
-
-Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, , <https://www.rfc-editor.org/rfc/rfc8083>.
-
-
[RFC8085]
-
-Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <https://www.rfc-editor.org/rfc/rfc8085>.
-
-
[RFC8201]
-
-McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, , <https://www.rfc-editor.org/rfc/rfc8201>.
-
-
[RFC8286]
-
-Xia, J., Even, R., Huang, R., and L. Deng, "RTP/RTCP Extension for RTP Splicing Notification", RFC 8286, DOI 10.17487/RFC8286, , <https://www.rfc-editor.org/rfc/rfc8286>.
-
-
[RFC8825]
-
-Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, , <https://www.rfc-editor.org/rfc/rfc8825>.
-
-
[RFC8849]
-
-Even, R. and J. Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, , <https://www.rfc-editor.org/rfc/rfc8849>.
-
-
[RFC8852]
-
-Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", RFC 8852, DOI 10.17487/RFC8852, , <https://www.rfc-editor.org/rfc/rfc8852>.
-
-
[RFC8860]
-
-Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", RFC 8860, DOI 10.17487/RFC8860, , <https://www.rfc-editor.org/rfc/rfc8860>.
-
-
[RFC8861]
-
-Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, , <https://www.rfc-editor.org/rfc/rfc8861>.
-
-
[RFC8899]
-
-Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, , <https://www.rfc-editor.org/rfc/rfc8899>.
-
-
[RFC9114]
-
-Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <https://www.rfc-editor.org/rfc/rfc9114>.
-
-
[RFC9143]
-
-Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, , <https://www.rfc-editor.org/rfc/rfc9143>.
-
-
[RFC9308]
-
-Kühlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, , <https://www.rfc-editor.org/rfc/rfc9308>.
-
-
[RFC9330]
-
-Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, , <https://www.rfc-editor.org/rfc/rfc9330>.
-
-
[RFC9335]
-
-Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, , <https://www.rfc-editor.org/rfc/rfc9335>.
-
-
[VJMK88]
-
-"Congestion Avoidance and Control", , <https://ee.lbl.gov/papers/congavoid.pdf>.
-
-
[_3GPP-TS-26.114]
-
-"IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", , <https://portal.3gpp.org/desktopmodules/Specifications/specificationId=1404>.
-
-
-
-
-
-
-
-

-Appendix A. List of optional QUIC Extensions -

-

The following is a list of QUIC protocol extensions that might be beneficial for -RoQ, but are not required by RoQ.

-
    -
  • -

    An Unreliable Datagram Extension to QUIC [RFC9221]. Without support for -unreliable datagrams, RoQ cannot use the encapsulation specified in -Section 5.3, but can still use QUIC streams as specified in -Section 5.2.

    -
    • -
  • -

    A version of QUIC receive timestamps can be helpful for improved jitter -calculations and congestion control. If the QUIC connection uses a timestamp -extension like, the arrival timestamps or one-way delays could be exposed to -the application for improved bandwidth estimation or RTCP mappings as -described in Section 8 and Appendix B.

    - -
    • -
  • -

    QUIC Acknowledgement Frequency [I-D.draft-ietf-quic-ack-frequency] can -be used by a sender to optimize the acknowledgement behaviour of the receiver, -e.g., to optimize congestion control.

    -
    • -
  • -

    Signaling That a QUIC Receiver Has Enough Stream Data - [I-D.draft-thomson-quic-enough] and Reliable QUIC Stream Resets - [I-D.draft-ietf-quic-reliable-stream-reset] would allow RoQ senders and -receivers to use versions of CLOSE_STREAM and STOP_SENDING that contain -offsets. The offset could be used to reliably retransmit all frames up to a -certain frame that should be cancelled before resuming transmission of further -frames on new QUIC streams.

    -
    • -
-
-
-
-
-

-Appendix B. Considered RTCP Packet Types and RTP Header Extensions -

-

This section lists all the RTCP packet types and RTP header extensions that were -considered in the analysis described in Section 8.

-

Several but not all of these control packets and their attributes can be mapped -from QUIC, as described in Section 8.4. Mappable from QUIC -has one of four values: yes, partly, QUIC extension needed, and no. -Partly is used for packet types for which some fields can be mapped from QUIC, -but not all. QUIC extension needed describes packet types which could be -mapped with help from one or more QUIC extensions.

-

Examples of how certain packet types could be mapped with the help of QUIC -extensions follow in Appendix B.6.

-
-
-

-B.1. RTCP Control Packet Types -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3
NameShortcutPTDefining DocumentMappable from QUICComments
SMPTE time-code mappingSMPTETC194 - [RFC5484] -no 
Extended inter-arrival jitter reportIJ195 - [RFC5450] -noWould require send-timestamps, which are not provided by any QUIC extension today
Sender ReportsSR200 - [RFC3550] -QUIC extension needed / partlysee Appendix B.6.4 and Appendix B.6.1 -
Receiver ReportsRR201 - [RFC3550] -QUIC extension neededsee Appendix B.6.1 -
Source descriptionSDES202 - [RFC3550] -no 
GoodbyeBYE203 - [RFC3550] -partlysee Section 8.4.3 -
Application-definedAPP204 - [RFC3550] -no 
Generic RTP FeedbackRTPFB205 - [RFC4585] -partlysee Appendix B.3 -
Payload-specificPSFB205 - [RFC4585] -partlysee Appendix B.4 -
extended reportXR207 - [RFC3611] -partlysee Appendix B.2 -
AVB RTCP packetAVB    
Receiver Summary InformationRSI209 - [RFC5760] -  
Port MappingTOKEN210 - [RFC6284] -no 
IDMS SettingsIDMS211 - [RFC7272] -no 
Reporting Group Reporting SourcesRGRS212 - [RFC8861] -  
Splicing Notification MessageSNM213 - [RFC8286] -no 
-
-
-
-
-

-B.2. Extended Reports (XR) -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 4: -Extended Report Blocks -
NameDocumentMappable from QUICComments
Loss RLE Report Block - [RFC3611] -yesIf only used for acknowledgment, could be replaced by QUIC acknowledgments, see Section 8.1 and Section 8.2 -
Duplicate RLE Report Block - [RFC3611] -no 
Packet Receipt Times Report Block - [RFC3611] -QUIC extension needed / partlyQUIC could provide packet receive timestamps when using a timestamp extension that reports timestamp for every received packet, such as [I-D.draft-smith-quic-receive-ts]. However, QUIC does not provide feedback in RTP timestamp format.
Receiver Reference Time Report Block - [RFC3611] -QUIC extension neededUsed together with DLRR Report Blocks to calculate RTTs of non-senders. RTT measurements can natively be provided by QUIC.
DLRR Report Block - [RFC3611] -QUIC extension neededUsed together with Receiver Reference Time Report Blocks to calculate RTTs of non-senders. RTT can natively be provided by QUIC.
Statistics Summary Report Block - [RFC3611] -QUIC extension needed / partlyPacket loss and jitter can be inferred from QUIC acknowledgments, if a timestamp extension is used (see [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts]). The remaining fields cannot be mapped to QUIC.
VoIP Metrics Report Block - [RFC3611] -noas in other reports above, only loss and RTT available
RTCP XR - [RFC5093] -no 
Texas Instruments Extended VoIP Quality Block   
Post-repair Loss RLE Report Block - [RFC5725] -no 
Multicast Acquisition Report Block - [RFC6332] -no 
IDMS Report Block - [RFC7272] -no 
ECN Summary Report - [RFC6679] -partlysee Section 8.4.2 -
Measurement Information Block - [RFC6776] -no 
Packet Delay Variation Metrics Block - [RFC6798] -noQUIC timestamps may be used to achieve the same goal?
Delay Metrics Block - [RFC6843] -noQUIC has RTT and can provide timestamps for one-way delay, but no way of informing peers about end-to-end statistics when QUIC is only used on one segment of the path.
Burst/Gap Loss Summary Statistics Block - [RFC7004] - QUIC ACKs?
Burst/Gap Discard Summary Statistics Block - [RFC7004] -no 
Frame Impairment Statistics Summary - [RFC7004] -no 
Burst/Gap Loss Metrics Block - [RFC6958] - QUIC ACKs?
Burst/Gap Discard Metrics Block - [RFC7003] -no 
MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block - [RFC6990] -no 
De-Jitter Buffer Metrics Block - [RFC7005] -no 
Discard Count Metrics Block - [RFC7002] -no 
DRLE (Discard RLE Report) - [RFC7097] -no 
BDR (Bytes Discarded Report) - [RFC7243] -no 
RFISD (RTP Flows Initial Synchronization Delay) - [RFC7244] -no 
RFSO (RTP Flows Synchronization Offset Metrics Block) - [RFC7244] -no 
MOS Metrics Block - [RFC7266] -no 
LCB (Loss Concealment Metrics Block) - [RFC7294], Section 4.1 -no 
CSB (Concealed Seconds Metrics Block) - [RFC7294], Section 4.1 -no 
MPEG2 Transport Stream PSI Decodability Statistics Metrics Block - [RFC7380] -no 
Post-Repair Loss Count Metrics Report Block - [RFC7509] -no 
Video Loss Concealment Metric Report Block - [RFC7867] -no 
Independent Burst/Gap Discard Metrics Block - [RFC8015] -no 
-
-
-
-
-
-

-B.3. Generic RTP Feedback (RTPFB) -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 5
NameLong NameDocumentMappable from QUICComments
Generic NACKGeneric negative acknowledgement - [RFC4585] -partlysee Section 8.4.1 -
TMMBRTemporary Maximum Media Stream Bit Rate Request - [RFC5104] -no 
TMMBNTemporary Maximum Media Stream Bit Rate Notification - [RFC5104] -no 
RTCP-SR-REQRTCP Rapid Resynchronisation Request - [RFC6051] -no 
RAMSRapid Acquisition of Multicast Sessions - [RFC6285] -no 
TLLEITransport-Layer Third-Party Loss Early Indication - [RFC6642] -no?no way of telling QUIC peer "don't ask for retransmission", but QUIC would not ask that anyway, only RTCP NACK?
RTCP-ECN-FBRTCP ECN Feedback - [RFC6679] -partlysee Section 8.4.2 -
PAUSE-RESUMEMedia Pause/Resume - [RFC7728] -no 
DBIDelay Budget Information (DBI) - [_3GPP-TS-26.114] -  
CCFBRTP Congestion Control Feedback - [RFC8888] -QUIC extension neededsee Appendix B.6.2 -
-
-
-
-
-

-B.4. Payload-specific RTP Feedback (PSFB) -

-

Because QUIC is a generic transport protocol, QUIC feedback cannot replace the -following Payload-specific RTP Feedback (PSFB) feedback.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 6
NameLong NameDocument
PLIPicture Loss Indication - [RFC4585] -
SLISlice Loss Indication - [RFC4585] -
RPSIReference Picture Selection Indication - [RFC4585] -
FIRFull Intra Request Command - [RFC5104] -
TSTRTemporal-Spatial Trade-off Request - [RFC5104] -
TSTNTemporal-Spatial Trade-off Notification - [RFC5104] -
VBCMVideo Back Channel Message - [RFC5104] -
PSLEIPayload-Specific Third-Party Loss Early Indication - [RFC6642] -
ROIVideo region-of-interest (ROI) - [_3GPP-TS-26.114] -
LRRLayer Refresh Request Command - [I-D.draft-ietf-avtext-lrr-07] -
VPViewport (VP) - [_3GPP-TS-26.114] -
AFBApplication Layer Feedback - [RFC4585] -
TSRRTemporal-Spatial Resolution Request - [I-D.draft-ietf-avtcore-rtcp-green-metadata] -
TSRNTemporal-Spatial Resolution Notification - [I-D.draft-ietf-avtcore-rtcp-green-metadata] -
-
-
-
-
-

-B.5. RTP Header extensions -

-

Like the payload-specific feedback packets, QUIC cannot directly replace the -control information in the following header extensions. RoQ does not place -restrictions on sending any RTP header extensions. However, some extensions, -such as Transmission Time offsets [RFC5450] are used to improve network -jitter calculation, which can be done in QUIC if a timestamp extension is used.

-
-
-

-B.5.1. Compact Header Extensions -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 7
Extension URIDescriptionReferenceMappable from QUIC
urn:ietf:params:rtp-hdrext:toffsetTransmission Time offsets - [RFC5450] -no
urn:ietf:params:rtp-hdrext:ssrc-audio-levelAudio Level - [RFC6464] -no
urn:ietf:params:rtp-hdrext:splicing-intervalSplicing Interval - [RFC8286] -no
urn:ietf:params:rtp-hdrext:smpte-tcSMPTE time-code mapping - [RFC5484] -no
urn:ietf:params:rtp-hdrext:sdesReserved as base URN for RTCP SDES items that are also defined as RTP compact header extensions. - [RFC7941] -no
urn:ietf:params:rtp-hdrext:ntp-64Synchronisation metadata: 64-bit timestamp format - [RFC6051] -no
urn:ietf:params:rtp-hdrext:ntp-56Synchronisation metadata: 56-bit timestamp format - [RFC6051] -no
urn:ietf:params:rtp-hdrext:encryptEncrypted extension header element - [RFC6904] -no, but maybe irrelevant?
urn:ietf:params:rtp-hdrext:csrc-audio-levelMixer-to-client audio level indicators - [RFC6465] -no
urn:3gpp:video-orientation:6Higher granularity (6-bit) coordination of video orientation (CVO) feature, see clause 6.2.3 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:video-orientationCoordination of video orientation (CVO) feature, see clause 6.2.3 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:roi-sentSignalling of the arbitrary region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 - [_3GPP-TS-26.114] -probably not(?)
urn:3gpp:predefined-roi-sentSignalling of the predefined region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 - [_3GPP-TS-26.114] -probably not(?)
-
-
-
-
-

-B.5.2. SDES Compact Header Extensions -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 8
Extension URIDescriptionReferenceMappable from QUIC
urn:ietf:params:rtp-hdrext:sdes:cnameSource Description: Canonical End-Point Identifier (SDES CNAME) - [RFC7941] -no
urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idRTP Stream Identifier - [RFC8852] -no
urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-idRTP Repaired Stream Identifier - [RFC8852] -no
urn:ietf:params:rtp-hdrext:sdes:CaptIdCLUE CaptId - [RFC8849] -no
urn:ietf:params:rtp-hdrext:sdes:midMedia identification - [RFC9143] -no
-
-
-
-
-
-
-

-B.6. Examples -

-
-
-

-B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") -

-

Considerations for mapping QUIC feedback into Receiver Reports (PT=201, -Name=RR, [RFC3550]) are:

-
    -
  • -

    Fraction lost: When RTP packets are carried in QUIC datagrams, the -fraction of lost packets can be directly inferred from QUIC's -acknowledgments. The calculation SHOULD include all packets up to the -acknowledged RTP packet with the highest RTP sequence number. Later packets -SHOULD be ignored since they may still be in flight unless other QUIC -packets that were sent after the RTP packet were already acknowledged.

    -
    • -
  • -

    Cumulative lost: Similar to the fraction of lost packets, the cumulative -loss can be inferred from QUIC's acknowledgments, including all packets up -to the latest acknowledged packet.

    -
    • -
  • -

    Highest Sequence Number received: In RTCP, this field is a 32-bit field -that contains the highest sequence number a receiver received in an RTP -packet and the count of sequence number cycles the receiver has observed. A -sender sends RTP packets in QUIC packets and receives acknowledgments for -the QUIC packets. By keeping a mapping from a QUIC packet to the RTP packets -encapsulated in that QUIC packet, the sender can infer the highest sequence -number and number of cycles seen by the receiver from QUIC acknowledgments.

    -
    • -
  • -

    Interarrival jitter: If QUIC acknowledgments carry timestamps as described -in [I-D.draft-smith-quic-receive-ts], senders can infer the interarrival -jitter from the arrival timestamps in QUIC acknowledgments.

    -
    • -
  • -

    Last SR: Similar to lost packets, the NTP timestamp of the last received -sender report can be inferred from QUIC acknowledgments.

    -
    • -
  • -

    Delay since last SR: This field is not required when the receiver reports -are entirely replaced by QUIC feedback.

    -
    • -
-
-
-
-
-

-B.6.2. Congestion Control Feedback ("CCFB") -

-

RTP Congestion Control Feedback (PT=205, FMT=11, Name=CCFB, -[RFC8888]) contains acknowledgments, arrival timestamps, and ECN -notifications for each received packet. Acknowledgments and ECNs can be inferred -from QUIC as described above. Arrival timestamps can be added through extended -acknowledgment frames as described in [I-D.draft-smith-quic-receive-ts] or -[I-D.draft-huitema-quic-ts].

-
-
-
-
-

-B.6.3. Extended Report ("XR") -

-

Extended Reports (PT=207, Name=XR, [RFC3611]) offer an extensible -framework for a variety of different control messages. Some of the statistics -that are defined as extended report blocks can be derived from QUIC, too. Other -report blocks need to be evaluated individually to determine whether the -contained information can be transmitted using QUIC instead. Table 4 -in Appendix B.2 lists considerations for mapping QUIC feedback to some -of the Extended Reports.

-
-
-
-
-

-B.6.4. Application Layer Repair and other Control Messages -

-

While Appendix B.6.1 presented some RTCP packets that can be replaced by QUIC -features, QUIC cannot replace all of the defined RTCP packet types. This mostly -affects RTCP packet types, which carry control information that is to be -interpreted by the RTP application layer rather than the underlying transport -protocol itself.

-
    -
  • -

    Sender Reports (PT=200, Name=SR, [RFC3550]) are similar to Receiver -Reports, as described in Appendix B.6.1. They are sent by media senders and -additionally contain an NTP and an RTP timestamp and the number of packets and -octets transmitted by the sender. The timestamps can be used by a receiver to -synchronize streams. QUIC cannot provide similar control information since it -does not know about RTP timestamps. A QUIC receiver cannot calculate the -packet or octet counts since it does not know about lost datagrams. Thus, -sender reports are required in RoQ to synchronize streams at the receiver. The -sender reports SHOULD not contain any receiver report blocks if the -information can be inferred from the QUIC transport as explained in -Appendix B.6.1.

    -
    • -
-

In addition to carrying transmission statistics, RTCP packets can contain -application layer control information that cannot directly be mapped to QUIC. -Examples of this information may include:

-
    -
  • -

    Source Description (PT=202, Name=SDES) and Application (PT=204, -Name=APP) packet types from [RFC3550], or

    -
    • -
  • -

    many of the payload-specific feedback messages (PT=206) defined in -[RFC4585], used to control the codec behavior of the sender.

    -
    • -
-

Since QUIC does not provide any kind of application layer control messaging, -QUIC feedback cannot be mapped into these RTCP packet types. If the RTP -application needs this information, the RTCP packet types are used in the same -way as they would be used over any other transport protocol.

-
-
-
-
-
-
-
-
-

-Appendix C. Experimental Results -

-

An experimental implementation of the mapping described in this document can be -found on Github. The application -implements the RoQ Datagrams mapping and implements SCReAM congestion -control at the application layer. It can optionally disable the builtin QUIC -congestion control (NewReno). The endpoints only use RTCP for congestion control -feedback, which can optionally be disabled and replaced by the QUIC connection -statistics as described in Section 8.4.

-

Experimental results of the implementation can be found on -Github, too.

-
-
-
-
-

-Acknowledgments -

-

Early versions of this document were similar in spirit to -[I-D.draft-hurst-quic-rtp-tunnelling], although many details differ. The -authors would like to thank Sam Hurst for providing his thoughts about how QUIC -could be used to carry RTP.

-

The guidance in Section 5.2 about configuring the number of parallel unidirectional QUIC streams is based on Section 6.2 of [RFC9114], with obvious substitutions for RTP/RTCP.

-

The authors would like to thank Bernard Aboba, David Schinazi, Lucas Pardue, -Sergio Garcia Murillo, Spencer Dawkins, and Vidhi Goel for their valuable -comments and suggestions contributing to this document.

-
-
-
-
-

-Authors' Addresses -

-
-
Jörg Ott
-
Technical University Munich
- -
-
-
Mathis Engelbart
-
Technical University Munich
- -
-
-
Spencer Dawkins
-
Tencent America LLC
- -
-
-
- - - diff --git a/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.txt b/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.txt deleted file mode 100644 index fd9b97a..0000000 --- a/remove-media-encoder-terminology/draft-ietf-avtcore-rtp-over-quic.txt +++ /dev/null @@ -1,2821 +0,0 @@ - - - - -Audio/Video Transport Core Maintenance J. Ott -Internet-Draft M. Engelbart -Intended status: Standards Track Technical University Munich -Expires: 2 August 2024 S. Dawkins - Tencent America LLC - 30 January 2024 - - - RTP over QUIC (RoQ) - draft-ietf-avtcore-rtp-over-quic-latest - -Abstract - - This document specifies a minimal mapping for encapsulating Real-time - Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets - within the QUIC protocol. This mapping is called RTP over QUIC - (RoQ). It also discusses how to leverage state from the QUIC - implementation in the endpoints, in order to reduce the need to - exchange RTCP packets and how to implement congestion control and - rate adaptation without relying on RTCP feedback. - -Discussion Venues - - This note is to be removed before publishing as an RFC. - - Discussion of this document takes place on the Audio/Video Transport - Core Maintenance Working Group mailing list (avt@ietf.org), which is - archived at https://mailarchive.ietf.org/arch/browse/avt/. - - Source for this draft and an issue tracker can be found at - https://github.com/mengelbart/rtp-over-quic-draft. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 2 August 2024. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Background - 1.2. Motivations - 1.2.1. "Always-On" Transport-level Authentication and - Encryption - 1.2.2. "Always-On" Internet-Safe Congestion Avoidance - 1.2.3. RTP Rate Adaptation Based on QUIC Feedback - 1.2.4. Path MTU Discovery and RTP Media Coalescence - 1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single - QUIC Connection - 1.2.6. Exploiting Multiple Connections - 1.2.7. Exploiting New QUIC Capabilities - 1.3. What's in Scope for this Specification - 1.4. What's Out of Scope for this Specification - 2. Terminology and Notation - 3. Protocol Overview - 3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of - Both - 3.2. Supported RTP Topologies - 4. Connection Establishment and ALPN - 4.1. Draft version identification - 5. Encapsulation - 5.1. Multiplexing - 5.2. QUIC Streams - 5.2.1. Stream Encapsulation - 5.2.2. Media Frame Cancellation - 5.2.3. Flow control and MAX_STREAMS - 5.3. QUIC Datagrams - 6. Connection Shutdown - 7. Congestion Control and Rate Adaptation - 7.1. Congestion Control at the Transport Layer - 7.2. Rate Adaptation at the Application Layer - 7.3. Sharing QUIC connections - 8. Replacing RTCP and RTP Header Extensions with QUIC Feedback - 8.1. RoQ Datagrams - 8.2. RoQ Streams - 8.3. Multihop Topologies - 8.4. Feedback Mappings - 8.4.1. Negative Acknowledgments ("NACK") - 8.4.2. ECN Feedback ("ECN") - 8.4.3. Goodbye Packets ("BYE") - 9. Error Handling - 10. API Considerations - 11. Discussion - 11.1. Impact of Connection Migration - 11.2. 0-RTT considerations - 12. Security Considerations - 13. IANA Considerations - 13.1. Registration of a RoQ Identification String - 13.2. RoQ Error Codes Registry - 14. References - 14.1. Normative References - 14.2. Informative References - Appendix A. List of optional QUIC Extensions - Appendix B. Considered RTCP Packet Types and RTP Header Extensions - B.1. RTCP Control Packet Types - B.2. Extended Reports (XR) - B.3. Generic RTP Feedback (RTPFB) - B.4. Payload-specific RTP Feedback (PSFB) - B.5. RTP Header extensions - B.5.1. Compact Header Extensions - B.5.2. SDES Compact Header Extensions - B.6. Examples - B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") - B.6.2. Congestion Control Feedback ("CCFB") - B.6.3. Extended Report ("XR") - B.6.4. Application Layer Repair and other Control Messages - Appendix C. Experimental Results - Acknowledgments - Authors' Addresses - -1. Introduction - - This document specifies a minimal mapping for encapsulating Real-time - Transport Protocol (RTP) [RFC3550] and RTP Control Protocol (RTCP) - [RFC3550] packets within the QUIC protocol ([RFC9000]). This mapping - is called RTP over QUIC (RoQ). It also discusses how to leverage - state from the QUIC implementation in the endpoints, in order to - reduce the need to exchange RTCP packets, and how to implement - congestion control and rate adaptation without relying on RTCP - feedback. - -1.1. Background - - The Real-time Transport Protocol (RTP) [RFC3550] is generally used to - carry real-time media for conversational media sessions, such as - video conferences, across the Internet. Since RTP requires real-time - delivery and is tolerant to packet losses, the default underlying - transport protocol has been UDP, recently with DTLS on top to secure - the media exchange and occasionally TCP (and possibly TLS) as a - fallback. - - This specification describes an application usage of QUIC - ([RFC9308]). As a baseline, the specification does not expect more - than a standard QUIC implementation as defined in [RFC8999], - [RFC9000], [RFC9001], and [RFC9002], providing a secure end-to-end - transport that is also expected to work well through NATs and - firewalls. Beyond this baseline, real-time applications can benefit - from QUIC extensions such as unreliable QUIC datagrams [RFC9221], - which provides additional desirable properties for real-time traffic - (e.g., no unnecessary retransmissions, avoiding head-of-line - blocking). - -1.2. Motivations - - From time to time, someone asks the reasonable question, "why should - anyone implement and deploy RoQ"? This reasonable question deserves - a better answer than "because we can". Upon reflection, the - following motivations seem useful to state. - - The motivations in this section are in no particular order, and this - reflects the reality that not all implementers and deployers would - agree on "the most important motivations". - -1.2.1. "Always-On" Transport-level Authentication and Encryption - - Although application-level mechanisms to encrypt RTP and RTCP - payloads have existed since the introduction of Secure Real-time - Transport Protocol (SRTP) [RFC3711], encryption of RTP and RTCP - header fields and contributing sources has only been defined recently - (in Cryptex [RFC9335], and both SRTP and Cryptex are optional - capabilities for RTP. - - This is in sharp contrast to "always-on" transport-level encryption - in the QUIC protocol, using Transport Layer Security (TLS 1.3) as - described in [RFC9001]. QUIC implementations always authenticate the - entirety of each packet, and encrypt as much of each packet as is - practical, even switching from "long headers", which expose more QUIC - header fields needed to establish a connection, to "short headers", - which only expose the absolute minimum QUIC header fields needed to - identify the connection to the receiver, so that the QUIC payload is - presented to the right QUIC application [RFC8999]. - -1.2.2. "Always-On" Internet-Safe Congestion Avoidance - - 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 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 Section 1.2.5, 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. - - Taken as a whole, - - * 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". - -1.2.3. RTP Rate Adaptation Based on 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 - Section 7 on rate adaptation, and in Section 8 on replacing RTCP and - RTP header extensions with QUIC feedback. - - 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. - -1.2.4. Path MTU Discovery and RTP Media Coalescence - - The minimum Path MTU supported by conformant QUIC implementations is - 1200 bytes [RFC9000], and in addition, QUIC implementations allow - senders to use either DPLPMTUD ([RFC8899]) or PMTUD ([RFC1191], - [RFC8201]) to determine the actual MTU size that the receiver and - path between sender and receiver support, which can be even larger. - - 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. - -1.2.5. Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC - Connection - - In order to conserve ports, especially at NATs and Firewalls, this - specification defines a flow identifier, so that multiple RTP flows, - RTCP flows, and non-RTP flows can be distinguished even if they are - carried on the same QUIC connection. This is described in more - detail in Section 5.1. - -1.2.6. Exploiting Multiple Connections - - Although there is much interest in multiplexing flows on a single - QUIC connection as described in Section 1.2.5, QUIC also provides the - capability of establishing and validating multiple paths for a single - QUIC connection [RFC9000]. Once multiple paths have been validated, - a sender can migrate from one path to another with no additional - signaling, allowing an endpoint to move from one endpoint address to - another without interruption, as long as only a single path is in - active use at any point in time. - - Connection migration may be desireable for a number of reasons, but - to give one example, this allows a sender to distinguish between more - costly cellular paths and less costly WiFi paths, with no action - required from the application. - -1.2.7. Exploiting New QUIC Capabilities - - In addition to connection migration as described in Section 1.2.6, - the capability of validating multiple paths for simultaneous active - use is under active development in the IETF - [I-D.draft-ietf-quic-multipath]. We don't discuss Multipath QUIC - further in this document, because the specification hasn't been - approved yet, but it's one example of ways that RTP, a mature - protocol, can exploit new transport capabilities as they become - available. - -1.3. What's in Scope for this Specification - - This document defines a mapping for RTP and RTCP over QUIC, called - RoQ, and describes ways to reduce the amount of RTCP traffic by - leveraging state information readily available within a QUIC - endpoint. This document also describes different options for - implementing congestion control and rate adaptation for RoQ. - - This specification focuses on providing a secure encapsulation of RTP - packets for transmission over QUIC. The expected usage is wherever - RTP is used to carry media packets, allowing QUIC in place of other - transport protocols such as TCP, UDP, SCTP, DTLS, etc. That is, we - expect RoQ to be used in contexts in which a signaling protocol is - used to announce or negotiate a media encapsulation and the - associated transport parameters (such as IP address, port number). - RoQ is not intended as a stand-alone media transport, although QUIC - transport parameters could be statically configured. - - The above implies that RoQ is targeted at peer-to-peer operation; but - it may also be used in client-server-style settings, e.g., when - talking to a conference server as described in RFC 7667 ([RFC7667]), - or, if RoQ is used to replace RTSP ([RFC7826]), to a media server. - - An appropriate 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 mechanism, so the application - can use a rate adaption mechanism of its choice. - - Moreover, this document describes how a QUIC implementation and its - API can be extended to improve efficiency of the RoQ protocol - operation. - - RoQ does not impact the usage of RTP Audio Video Profiles (AVP) - ([RFC3551]), or any RTP-based mechanisms, even though it may render - some of them unnecessary, e.g., Secure Real-Time Transport Prococol - (SRTP) ([RFC3711]) might not be needed, because end-to-end security - is already provided by QUIC, and double encryption by QUIC and by - SRTP might have more costs than benefits. Nor does RoQ limit the use - of RTCP-based mechanisms, even though some information or functions - obtained by using RTCP mechanisms may also be available from the - underlying QUIC implementation by other means. - - Between two (or more) endpoints, RoQ supports multiplexing multiple - RTP-based media streams within a single QUIC connection and thus - using a single (destination IP address, destination port number, - source IP address, source port number, protocol) 5-tuple.. We note - that multiple independent QUIC connections may be established in - parallel using the same destination IP address, destination port - number, source IP address, source port number, protocol) 5-tuple., - e.g. to carry different media channels. These connections would be - logically independent of one another. - -1.4. What's Out of Scope for this Specification - - This document does not attempt to enhance QUIC for real-time media or - define a replacement for, or evolution of, RTP. Work to map other - media transport protocols to QUIC is under way elsewhere in the IETF. - - RoQ is designed for use with point-to-point connections, because QUIC - itself is not defined for multicast operation. The scope of this - document is limited to unicast RTP/RTCP, even though nothing would or - should prevent its use in multicast setups once QUIC supports - multicast. - - RoQ does not define congestion control and rate adaptation algorithms - for use with media. However, Section 7 discusses options for how - congestion control and rate adaptation could be performed at the QUIC - and/or at the RTP layer, and how information available at the QUIC - layer could be exposed via an API for the benefit of RTP layer - implementation. - - *Editor's note:* Need to check whether Section 7 will also - describe the QUIC interface that's being exposed, or if that ends - up somewhere else in the document. - - RoQ does not define prioritization mechanisms when handling different - media as those would be dependent on the media themselves and their - relationships. Prioritization is left to the application using RoQ. - - This document does not cover signaling for session setup. SDP for - RoQ is defined in separate documents such as - [I-D.draft-dawkins-avtcore-sdp-rtp-quic], and can be carried in any - signaling protocol that can carry SDP, including the Session - Initiation Protocol (SIP) ([RFC3261]), Real-Time Protocols for - Browser-Based Applications (RTCWeb) ([RFC8825]), or WebRTC-HTTP - Ingestion Protocol (WHIP) ([I-D.draft-ietf-wish-whip]). - -2. Terminology and Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in BCP - 14 [RFC2119] [RFC8174] 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 Section 7.2, - 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: 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 a sender from - overwhelming the capacity of a path between a sender and a - receiver, causing some outstanding data to be discarded before the - receiver can receive the data and acknowledge it to the sender. - - Datagram: Datagrams exist in UDP as well as in QUIC's unreliable - datagram extension. If not explicitly noted differently, the term - datagram in this document refers to a QUIC Datagram as defined in - [RFC9221]. - - Delay-based or Low-latency congestion control algorithm: A - congestion control algorithm that aims at keeping queues, and thus - the latency, at intermediary network elements as short as - possible. Delay-based congestion control algorithms use, for - example, an increasing one-way delay as a signal of congestion. - - Endpoint: A QUIC server or client that participates in an RoQ - session. - - Frame: A QUIC frame as defined in [RFC9000]. - - Loss-based congestion control algorithm: A congestion control - algorithm that uses packet loss, or an Explicit Congestion - Notification (ECN) that is interpreted as loss (as in [RFC3168]), - as a signal for congestion. Loss-based congestion control - algorithms allow senders to send data on a path until packets are - dropped by intermediary network elements, which the algorithm - treats as a signal of congestion. - - QUIC congestion controller: A software component of an application's - QUIC implementation that implements a congestion control - algorithm. - - 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. - - Receiver: An endpoint that receives media in RTP packets and may - send or receive RTCP packets. - - RTP congestion controller: A software component of an application's - RTP implementation that implements a congestion control algorithm. - - Sender: An endpoint that sends media in RTP packets and may send or - receive RTCP packets. - - Packet diagrams in this document use the format defined in - Section 1.3 of [RFC9000] to illustrate the order and size of fields. - -3. Protocol Overview - - This document introduces a mapping of the Real-time Transport - Protocol (RTP) to the QUIC transport protocol. RoQ allows the use of - QUIC streams and QUIC datagrams to transport real-time data, and - thus, the QUIC implementation MUST support QUIC's datagram extension, - if RTP packets should be sent over QUIC datagrams. - - [RFC3550] specifies that RTP sessions need to be transmitted on - different transport addresses to allow multiplexing between them. - RoQ uses a different approach to leverage the advantages of QUIC - connections without managing a separate QUIC connection per RTP - session. QUIC does not provide demultiplexing between different - flows on datagrams but suggests that an application implement a - demultiplexing mechanism if required. An example of such a mechanism - would be flow identifiers prepended to each datagram frame as - described in Section 2.1 of [I-D.draft-ietf-masque-h3-datagram]. RoQ - uses a flow identifier to replace the network address and port number - to multiplex many RTP sessions over the same QUIC connection. - - An RTP application is responsible for determining what to send in an - encoded media stream, and how to send that encoded media stream - within a targeted bitrate. - - This document does not mandate how an application determines what to - send in an encoded media stream, because decisions about what to send - within a targeted bitrate, and how to adapt to changes in the - targeted bitrate, can be application and codec-specific. For - example, adjusting quantization in response to changing network - conditions may work well in many cases, but if what's being shared is - video that includes text, maintaining readability is important. - - 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. - - Since QUIC also collects some metrics about the network's - performance, these metrics can be used to generate the required - feedback at the sender-side and provide it to the rate adaptation - algorithm to avoid the additional overhead of the RTCP stream. This - is discussed in more detail in Section 8. - -3.1. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both - - This document describes the use of both QUIC streams and QUIC - datagrams as RTP encapsulations, but does not take a position on - which encapsulation an application should use. Indeed, an - application can use both QUIC streams and QUIC datagram - encapsulations. The choice of which encapsulation is used is up to - the application developer, but it is worth noting the differences. - - QUIC [RFC9000] was initially designed to carry HTTP [RFC9114] in QUIC - streams, and QUIC streams provide what HTTP application developers - require - for example, QUIC streams provide a stateful, connection- - oriented, flow-controlled, reliable, ordered stream of bytes to an - application. QUIC streams can be multiplexed over a single QUIC - connection, using stream IDs to demultiplex incoming messages. - - QUIC Datagrams [RFC9221] were developed as a QUIC extension, intended - to support applications that do not require reliable delivery of - application data. This extension defines two QUIC DATAGRAM frame - types (one including a length field, the other not including a length - field), and these DATAGRAM frames can co-exist with QUIC STREAM - frames within a single QUIC connection, sharing the connection's - cryptographic and authentication context, and congestion controller - context. - - There is no default relative priority between DATAGRAM frames with - respect to each other, and there is no default priority between - DATAGRAM frames and QUIC streams. The implementation likely presents - an API to allow appplications to assign relative priorities, but this - is not mandated by the standard and may not be present in all - implementations. - - Because QUIC datagrams are an extension to QUIC, they inherit a great - deal of functionality from QUIC (much of which is described in - Section 1.2); so much so that it is easier to explain what datagrams - do NOT inherit. - - * DATAGRAM frames do not provide any explicit flow control - signaling. This means that a QUIC receiver may not be able to - commit the necessary resources to process incoming frames, but the - purpose for DATAGRAM frames is to carry application-level - information that can be lost and will not be retransmitted, - - * DATAGRAM frames do inherit the QUIC connection's congestion - controller. This means that although there is no frame-level flow - control, DATAGRAM frames may be delayed until the controller - allows them to be sent, or dropped (with an optional notification - to the sending application). Implementations can also delay - sending DATAGRAM frames to maintain consistent packet pacing (as - described in Section 7.7 of [RFC9002]), and can allow an - application to specify a sending expiration time, but these - capabilities are not mandated by the standard and may not be - present in all implementations. - - * DATAGRAM frames cannot be fragmented. They are limited in size by - the max_datagram_frame_size transport parameter, and further - limited by the max_udp_payload_size transport parameter and the - Maximum Transmission Unit (MTU) of the path between endpoints. - - * DATAGRAM frames belong to a QUIC connection as a whole. There is - no QUIC-level way to multiplex/demultiplex DATAGRAM frames within - a single QUIC connection. Any multiplexing identifiers must be - added, interpreted, and removed by an application, and they will - be sent as part of the payload of the DATAGRAM frame itself. - - Because QUIC datagrams are an extension to QUIC, a RoQ endpoint - cannot count on a RoQ peer supporting that extension. The RoQ - endpoint may discover that its peer does not support datagrams while - using signaling to set up QUIC connections, but may also discover - that its peer has not negotiated the use of this extension during the - QUIC handshake. When this happens, the RoQ endpoint needs to make a - decision about what to do next. - - * If the use of QUIC datagrams was critical, the endpoint can simply - close the QUIC connection, allowing someone or something to - correct this mismatch, so that QUIC datagrams can be used. - - * If the use of QUIC datagrams was not critical, the endpoint can - negotiate the use of QUIC streams instead. - -3.2. Supported RTP Topologies - - RoQ only supports some of the RTP topologies described in [RFC7667]. - Most notably, due to QUIC [RFC9000] being a purely IP unicast - protocol at the time of writing, RoQ cannot be used as a transport - protocol for any of the paths that rely on IP multicast in several - multicast topologies (e.g., _Topo-ASM_, _Topo-SSM_, _Topo-SSM-RAMS_). - - Some "multicast topologies" can include IP unicast paths (e.g., - _Topo-SSM_, _Topo-SSM-RAMS_). In these cases, the unicast paths can - use RoQ. - - RTP supports different types of translators and mixers. Whenever a - middlebox such as a translator or a mixer needs to access the content - of RTP/RTCP-packets, the QUIC connection has to be terminated at that - middlebox. - - RoQ streams (see Section 5.2) can support much larger RTP packet - sizes than other transport protocols such as UDP can, which can lead - to problems with transport translators which translate from RoQ to - RTP over a different transport protocol. A similar problem can occur - if a translator needs to translate from RTP over UDP to RoQ - datagrams, where the MTU of a QUIC datagram may be smaller than the - MTU of a UDP datagram. In both cases, the translator may need to - rewrite the RTP packets to fit into the smaller MTU of the other - protocol. Such a translator may need codec-specific knowledge to - packetize the payload of the incoming RTP packets in smaller RTP - packets. - - Additional details are provided in the following table. - - +=======================================+============+========+==========+ - |RFC 7667 Section |Shortcut |RTP over|Comments | - | |Name |QUIC? | | - +=======================================+============+========+==========+ - |3.1 |Topo-Point- |yes | | - |(https://datatracker.ietf.org/doc/html/|to-Point | | | - |rfc7667#section-3.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.1 |Topo-PtP- |yes |Note-NAT | - |(https://datatracker.ietf.org/doc/html/|Relay | | | - |rfc7667#section-3.2.1.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.2 |Topo-Trn- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|Translator | |Note-SEC | - |rfc7667#section-3.2.1.2) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.1.3 |Topo-Media- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|Translator | | | - |rfc7667#section-3.2.1.3) | | | | - +---------------------------------------+------------+--------+----------+ - |3.2.2 |Topo-Back- |yes |Note-SEC | - |(https://datatracker.ietf.org/doc/html/|To-Back | |Note-MTU | - |rfc7667#section-3.2.2) | | |Note-MCast| - +---------------------------------------+------------+--------+----------+ - |3.3.1 |Topo-ASM |no |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | | | - |rfc7667#section-3.3.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.3.2 |Topo-SSM |partly |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | |Note- | - |rfc7667#section-3.3.2) | | |UCast- | - | | | |MCast | - +---------------------------------------+------------+--------+----------+ - |3.3.3 |Topo-SSM- |partly |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|RAMS | |Note- | - |rfc7667#section-3.3.3) | | |MCast- | - | | | |UCast | - +---------------------------------------+------------+--------+----------+ - |3.4 |Topo-Mesh |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | | | - |rfc7667#section-3.4) | | | | - +---------------------------------------+------------+--------+----------+ - |3.5.1 |Topo-PtM- |possibly|Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Trn- | |Note-MTU | - |rfc7667#section-3.5.1) |Translator | |Note-Topo-| - | | | |PtM-Trn- | - | | | |Translator| - +---------------------------------------+------------+--------+----------+ - |3.6 |Topo-Mixer |possibly|Note-MCast| - |(https://datatracker.ietf.org/doc/html/| | |Note-Topo-| - |rfc7667#section-3.6) | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.6.1 |Media- |partly |Note-Topo-| - |(https://datatracker.ietf.org/doc/html/|Mixing-Mixer| |Mixer | - |rfc7667#section-3.6.1) | | | | - +---------------------------------------+------------+--------+----------+ - |3.6.2 |Media- |partly |Note-Topo-| - |(https://datatracker.ietf.org/doc/html/|Switching- | |Mixer | - |rfc7667#section-3.6.2) |Mixer | | | - +---------------------------------------+------------+--------+----------+ - |3.7 |Selective |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Forwarding | |Note-Topo-| - |rfc7667#section-3.7) |Middlebox | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.8 |Topo-Video- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|switch-MCU | |Note-MCast| - |rfc7667#section-3.8) | | |Note-Topo-| - | | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.9 |Topo-RTCP- |yes |Note-MTU | - |(https://datatracker.ietf.org/doc/html/|terminating-| |Note-MCast| - |rfc7667#section-3.9) |MCU | |Note-Topo-| - | | | |Mixer | - +---------------------------------------+------------+--------+----------+ - |3.10 |Topo-Split- |yes |Note-MCast| - |(https://datatracker.ietf.org/doc/html/|Terminal | | | - |rfc7667#section-3.10) | | | | - +---------------------------------------+------------+--------+----------+ - |3.11 |Topo- |Possibly|Note-Warn,| - |(https://datatracker.ietf.org/doc/html/|Asymmetric | |Note- | - |rfc7667#section-3.11) | | |MCast, | - | | | |Note-MTU | - +---------------------------------------+------------+--------+----------+ - - Table 1 - - Note-NAT: QUIC [RFC9000] doesn't support NAT traversal. - - Note-MTU: Supported, but may require MTU adaptation. - - Note-Sec: Note that RoQ provides mandatory security, and other RTP - transports do not. Section 12 describes strategies to prevent the - inadvertent disclosure of RTP sessions to unintended third - parties. - - Note-MCast: QUIC [RFC9000] cannot be used for multicast paths. - - Note-UCast-MCast: The topology refers to a _Distribution Source_, - which receives and relays RTP from a number of different media - senders via unicast before relaying it to the receivers via - multicast. QUIC can be used between the senders and the - _Distribution Source_. - - Note-MCast-UCast: The topology refers to a _Burst Source_ or - _Retransmission Source_, which retransmits RTP to receivers via - unicast. QUIC can be used between the _Retransmission Source_ and - the receivers. - - Note-Topo-PtM-Trn-Translator: Supports unicast paths between RTP - sources and translators. - - Note-Topo-Mixer: Supports unicast paths between RTP senders and - mixers. - - Note-Warn: Quote from [RFC7667]: _This topology is so problematic - and it is so easy to get the RTCP processing wrong, that it is NOT - RECOMMENDED to implement this topology._ - -4. Connection Establishment and ALPN - - QUIC requires the use of ALPN [RFC7301] tokens during connection - setup. RoQ uses "rtp-mux-quic" as ALPN token in the TLS handshake - (see also Section 13. - - Note that the use of a given RTP profile is not reflected in the ALPN - token even though it could be considered part of the application - usage. This is simply because different RTP sessions, which may use - different RTP profiles, may be carried within the same QUIC - connection. - - *Editor's note:* "rtp-mux-quic" indicates that RTP and other - protocols may be multiplexed on the same QUIC connection using a - flow identifier as described in Section 5. Applications are - responsible for negotiation of protocols in use by appropriate use - of a signaling protocol such as SDP. - - *Editor's note:* This implies that applications cannot use RoQ as - specified in this document over WebTransport. - -4.1. Draft version identification - - *RFC Editor's note:* Please remove this section prior to - publication of a final version of this document. - - RoQ uses the token "rtp-mux-quic" to identify itself in ALPN. - - Only implementations of the final, published RFC can identify - themselves as "rtp-mux-quic". Until such an RFC exists, - implementations MUST NOT identify themselves using this string. - - Implementations of draft versions of the protocol MUST add the string - "-" and the corresponding draft number to the identifier. For - example, draft-ietf-avtcore-rtp-over-quic-04 is identified using the - string "rtp-mux-quic-04". - - Non-compatible experiments that are based on these draft versions - MUST append the string "-" and an experiment name to the identifier. - -5. Encapsulation - - This section describes the encapsulation of RTP/RTCP packets in QUIC. - - QUIC supports two transport methods: streams [RFC9000] and datagrams - [RFC9221]. This document specifies mappings of RTP to both of the - transport modes. Senders MAY combine both modes by sending some RTP/ - RTCP packets over the same or different QUIC streams and others in - QUIC datagrams. - - Section 5.1 introduces a multiplexing mechanism that supports - multiplexing RTP, RTCP, and, with some constraints, other non-RTP - protocols. Section 5.2 and Section 5.3 explain the specifics of - mapping RTP to QUIC streams and QUIC datagrams, respectively. - -5.1. Multiplexing - - RoQ uses flow identifiers to multiplex different RTP, RTCP, and non- - RTP data streams on a single QUIC connection. A flow identifier is a - QUIC variable-length integer as described in Section 16 of [RFC9000]. - Each flow identifier is associated with a stream of RTP packets, RTCP - packets, or a data stream of a non-RTP protocol. - - In a QUIC connection using the ALPN token defined in Section 4, every - QUIC datagram and every QUIC stream MUST start with a flow - identifier. A peer MUST NOT send any data in a datagram or stream - that is not associated with the flow identifier which started the - datagram or stream. - - RTP and RTCP packets of different RTP sessions MUST use distinct flow - identifiers. If peers wish to send multiple types of media in a - single RTP session, they MAY do so by following [RFC8860]. - - A single RTP session MAY be associated with one or two flow - identifiers. Thus, it is possible to send RTP and RTCP packets - belonging to the same session using different flow identifiers. RTP - and RTCP packets of a single RTP session MAY use the same flow - identifier (following the procedures defined in [RFC5761], or they - MAY use different flow identifiers. - - The association between flow identifiers and data streams MUST be - negotiated using appropriate signaling. Applications MAY send data - using flow identifiers not associated with any RTP or RTCP stream. - If a receiver cannot associate a flow identifier with any RTP/RTCP or - non-RTP flow, it MAY drop the data flow. If the data flow was sent - on a QUIC stream, the receiver SHOULD send a STOP_SENDING frame with - the application error code set to ROQ_UNKNOWN_FLOW_ID. - - There are different use cases for sharing the same QUIC connection - between RTP and non-RTP data streams. Peers might use the same - connection to exchange signaling messages or exchange data while - sending and receiving media streams. The semantics of non-RTP - datagrams or streams are not in the scope of this document. Peers - MAY use any protocol on top of the encapsulation described in this - document. - - Flow identifiers introduce some overhead in addition to the header - overhead of RTP/RTCP and QUIC. QUIC variable-length integers require - between one and eight bytes depending on the number expressed. Thus, - it is advisable to use low numbers first and only use higher ones if - necessary due to an increased number of flows. - -5.2. QUIC Streams - - To send RTP/RTCP packets over QUIC streams, a sender MUST open at - least one new unidirectional QUIC stream. RoQ uses unidirectional - streams, because there is no synchronous relationship between sent - and received RTP/RTCP packets. A peer that receives a bidirectional - stream with a flow identifier that is associated with an RTP or RTCP - stream, SHOULD stop reading from the stream and send a STOP_SENDING - frame with the application protocol error code set to - ROQ_STREAM_CREATION_ERROR. - - A RoQ sender MAY open new QUIC streams for different packets using - the same flow identifier, for example, to avoid head-of-line - blocking. - - Because a sender can continue sending on a lower stream number after - starting packet transmission on a higher stream number, a RoQ - receiver MUST be prepared to receive RoQ packets on any number of - QUIC streams (subject to its limit on parallel open streams) and MUST - not make assumptions about which RTP sequence numbers are carried in - which streams. - -5.2.1. Stream Encapsulation - - Figure 1 shows the encapsulation format for RoQ Streams. - - Payload { - Flow Identifier (i), - RTP/RTCP Payload(..) ..., - } - - Figure 1: RoQ Streams Payload Format - - Flow Identifier: Flow identifier to demultiplex different data flows - on the same QUIC connection. - - RTP/RTCP Payload: Contains the RTP/RTCP payload; see Figure 2 - - The payload in a QUIC stream starts with the flow identifier followed - by one or more RTP/RTCP payloads. All RTP/RTCP payloads sent on a - stream MUST belong to the RTP session with the same flow identifier. - - Each payload begins with a length field indicating the length of the - RTP/RTCP packet, followed by the packet itself, see Figure 2. - - RTP/RTCP Payload { - Length(i), - RTP/RTCP Packet(..), - } - - Figure 2: RTP/RTCP payload for QUIC streams - - Length: A QUIC variable length integer (see Section 16 of [RFC9000]) - describing the length of the following RTP/RTCP packets in bytes. - - RTP/RTCP Packet: The RTP/RTCP packet to transmit. - -5.2.2. Media Frame Cancellation - - QUIC uses RESET_STREAM and STOP_SENDING frames to terminate the - sending part of a stream and to request termination of an incoming - stream by the sending peer respectively. - - A RoQ sender MAY use RESET_STREAM if it knows that a packet, which - was not yet successfully and completely transmitted, is no longer - needed. - - A RoQ receiver that is no longer interested in reading a certain - partition of the media stream MAY signal this to the sending peer - using a STOP_SENDING frame. - - In both cases, the error code of the RESET_STREAM frame or the - STOP_SENDING frame MUST be set to ROQ_FRAME_CANCELLED. - - STOP_SENDING is not a request to the sender to stop sending the RTP - media stream, only an indication that a receiver stopped reading the - QUIC stream being used. A sender with additional media frames to - send SHOULD continue sending them on another QUIC stream. - Alternatively, new media frames can be sent as QUIC datagrams (see - Section 5.3). - - Any media frame that has already been sent on the QUIC stream that - received the STOP_SENDING frame, MUST NOT be sent again on the new - QUIC stream(s) or datagrams. - - Note that an RTP receiver cannot request a reset of only a particular - media frame because the sending QUIC implementation might already - have sent data for the following frame on the same stream. In that - case, STOP_SENDING and the following RESET_STREAM would also drop the - following media frame and thus lead to unintentionally skipping one - or more frames. - - *Editor's note:* A receiver cannot cancel a certain frame but - still receive retransmissions for a frame the was following on the - same stream using STOP_SENDING, because STOP_SENDING does not - include an offset which would allow signaling where - retransmissions should continue. - - A translator that translates between two endpoints, both connected - via QUIC, MUST forward RESET_STREAM frames received from one end to - the other unless it forwards the RTP packets on QUIC datagrams. - - Large RTP packets sent on a stream will be fragmented into smaller - QUIC frames. The QUIC frames are transmitted reliably and in order - such that a receiving application can read a complete RTP packet from - the stream as long as the stream is not closed with a RESET_STREAM - frame. No retransmission has to be implemented by the application - since QUIC frames lost in transit are retransmitted by QUIC. - -5.2.3. Flow control and MAX_STREAMS - - In order to permit QUIC streams to open, a RoQ sender SHOULD - configure non-zero minimum values for the number of permitted streams - and the initial stream flow-control window, based on the number of - parallel, or simultaneously active, RTP/RTCP flows. Endpoints that - excessively restrict the number of streams or the flow-control window - of these streams will increase the chance that the remote peer - reaches the limit early and becomes blocked. - - Opening new streams for new packets MAY implicitly limit the number - of packets concurrently in transit because the QUIC receiver provides - an upper bound of parallel streams, which it can update using QUIC - MAX_STREAMS frames. The number of packets that have to be - transmitted concurrently depends on several factors, such as the - number of RTP streams within a QUIC connection, the bitrate of the - media streams, and the maximum acceptable transmission delay of a - given packet. Receivers are responsible for providing senders enough - credit to open new streams for new packets anytime. - - As an example, consider a conference scenario with 20 participants. - Each participant receives audio and video streams of every other - participant from a central server. If the sender opens a new QUIC - stream for every frame at 30 frames per second video and 50 frames - per second audio, it will open 1520 new QUIC streams per second. A - receiver must provide at least that many credits for opening new - unidirectional streams to the server every second. - - In addition, the receiver should also consider the requirements of - protocols into account that are multiplexed with RTP, including RTCP - and data streams. These considerations may also be relevant when - implementing signaling since it may be necessary to inform the - receiver about how fast and how many stream credits it will have to - provide to the media-sending peer. - -5.3. QUIC Datagrams - - Senders can also transmit RTP packets in QUIC datagrams. QUIC - datagrams are an extension to QUIC described in [RFC9221]. QUIC - datagrams can only be used if the use of the datagram extension was - successfully negotiated during the QUIC handshake. If the QUIC - extension was signaled using a signaling protocol, but that extension - was not negotiated during the QUIC handshake, a peer MAY close the - connection with the ROQ_EXPECTATION_UNMET error code. - - QUIC datagrams preserve frame boundaries. Thus, a single RTP packet - can be mapped to a single QUIC datagram without additional framing. - Senders SHOULD consider the header overhead associated with QUIC - datagrams and ensure that the RTP/RTCP packets, including their - payloads, flow identifier, QUIC, and IP headers, will fit into path - MTU. - - Figure 3 shows the encapsulation format for RoQ Datagrams. - - Payload { - Flow Identifier (i), - RTP/RTCP Packet (..), - } - - Figure 3: RoQ Datagram Payload Format - - Flow Identifier: Flow identifier to demultiplex different data flows - on the same QUIC connection. - - RTP/RTCP Packet: The RTP/RTCP packet to transmit. - - RoQ senders need to be aware that QUIC uses the concept of QUIC - frames. Different kinds of QUIC frames are used for different - application and control data types. A single QUIC packet can contain - more than one QUIC frame, including, for example, QUIC stream or - datagram frames carrying application data and acknowledgement frames - carrying QUIC acknowledgements, as long as the overall size fits into - the MTU. One implication is that the number of packets a QUIC stack - transmits depends on whether it can fit acknowledgement and datagram - frames in the same QUIC packet. Suppose the application creates many - datagram frames that fill up the QUIC packet. In that case, the QUIC - stack might have to create additional packets for acknowledgement- - (and possibly other control-) frames. The additional overhead could, - in some cases, be reduced if the application creates smaller RTP - packets, such that the resulting datagram frame can fit into a QUIC - packet that can also carry acknowledgement frames. - - Since QUIC datagrams are not retransmitted on loss (see also - Section 8.4 for loss signaling), if an application wishes to - retransmit lost RTP packets, the retransmission has to be implemented - by the application. RTP retransmissions can be done in the same RTP - session or a separate RTP session [RFC4588] and the flow identifier - MUST be set to the flow identifier of the RTP session in which the - retransmission happens. - -6. Connection Shutdown - - Either peers MAY close the connection for variety of reasons. If one - of the peers wants to close the RoQ connection, the peer can use a - QUIC CONNECTION_CLOSE frame with one of the error codes defined in - Section 9. - -7. Congestion Control and Rate Adaptation - - 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. - - This document discusses aspects of transport level congestion control - in Section 7.1 and application layer rate control in Section 7.2. It - does not mandate any specific congestion control algorithm for QUIC - or rate adaptation algorithm for RTP. - - This document also gives guidance about avoiding problems with - _nested_ congestion controllers in Section 7.2. - - This document also discusses congestion control implications of using - shared or multiple separate QUIC connections to send and receive - multiple independent data streams in Section 7.3. - -7.1. Congestion Control at the Transport Layer - - 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. - - 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 3.1. - - 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 - Appendix A. 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 Section 7.2. - - It is assumed that the congestion controller in use provides a pacing - mechanism to determine when a packet can be sent to avoid bursts and - minimize variation in inter-packet arrival times. 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. - -7.2. Rate Adaptation at the 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. - - 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 - being 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 Section 8 and Section 10. - -7.3. Sharing QUIC connections - - Two endpoints may establish channels in order to exchange more than - one type of data simultaneously. The channels can be intended to - carry real-time RTP data or other non-real-time data. This can be - realized in different ways. - - * One straightforward solution is to establish multiple QUIC - connections, one for each channel, whether the channel is used for - real-time media or non-real-time data. This is a straightforward - solution, but has the 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. - - In both cases, the congestion controllers can be chosen to match the - demands of the respective channels and the different QUIC connections - will compete for the same resources in the network. No local - prioritization of data across the different (types of) channels would - be necessary. - - Although it is possible to multiplex (all or a subset of) real-time - and non-real-time channels onto a single, shared QUIC connection, - which can be done by using the flow identifier described in - Section 5.1, the underlying QUIC implementation will likely use the - same congestion controller for all channels in the shared QUIC - connection. For this reason, applications multiplexing multiple - streams in one connection SHOULD implement some form of stream - prioritization or bandwidth allocation. - -8. Replacing RTCP and RTP Header Extensions with QUIC Feedback - - Because RTP has so often used UDP as its underlying transport - protocol, and receiving little or no feedback from UDP, RTP - implementations rely on feedback from the RTP Control Protocol (RTCP) - so that RTP senders and receivers can exchange control information to - monitor connection statistics and to identify and synchronize - streams. - - Because QUIC provides transport-level feedback, it can replace at - least some RTP transport-level feedback with current QUIC feedback - [RFC9000]. In addition, RTP-level feedback that is not available in - QUIC by default can potentially be replaced with generally useful - QUIC extensions in the future as described in Appendix B.6. - - When statistics contained in RTCP packets are also available from - QUIC or can be derived from statistics available from QUIC, it is - desirable to provide these statistics at only one protocol layer. - This avoids consumption of bandwidth to deliver equivalent control - information at more than one level of the protocol stack. QUIC and - RTCP both have rules describing when certain signals have to be sent. - This document does not change any of the rules described by either - protocol, but specifies a baseline for replacing some of the RTCP - packet types by mapping the contents to QUIC connection statistics, - and reducing the transmission frequency and bandwidth requirements - for some RTCP packet types that must be transmitted periodically. - Future documents can extend this mapping for other RTCP format types, - and can make use of new QUIC extensions that become available over - time. The mechanisms described in this section can enhance the - statistics provided by RTCP and reduce the bandwidth overhead - required by certain RTCP packets. Applications using RoQ need to - adhere to the rules for RTCP feedback given by [RFC3550] and the RTP - profiles in use. - - Most statements about "QUIC" in Section 8 are applicable to both RTP - encapsulated in QUIC streams and RTP encapsulated in QUIC datagrams. - The differences are described in Section 8.1 and Section 8.2. - - *Editor's Note:* Additional discussion of bandwidth minimization - could go in this section, or in an earlier proposed section on - motivations for defining and deploying RoQ. - - While RoQ places no restrictions on applications sending RTCP, this - document assumes that the reason an implementor chooses to support - RoQ is to obtain benefits beyond what's available when RTP uses UDP - as its underlying transport layer. It is RECOMMENDED to expose - relevant information from the QUIC layer to the application instead - of exchanging additional RTCP packets, where applicable. - - Section 8.4 discusses what information can be exposed from the QUIC - connection layer to reduce the RTCP overhead. - -8.1. RoQ Datagrams - - QUIC Datagrams are ack-eliciting packets, which means that an - acknowledgment is triggered when a datagram frame is received. Thus, - a sender can assume that an RTP packet arrived at the receiver or was - lost in transit, using the QUIC acknowledgments of QUIC Datagram - frames. In the following, an RTP packet is regarded as acknowledged - when the QUIC Datagram frame that carried the RTP packet was - acknowledged. - -8.2. RoQ Streams - - For RTP packets that are sent over QUIC streams, an RTP packet is - considered acknowledged after all frames that carried fragments of - the RTP packet were acknowledged. - - When QUIC Streams are used, the application should be aware that the - direct mapping proposed below may not reflect the real - characteristics of the network. RTP packet loss can seem lower than - actual packet loss due to QUIC's automatic retransmissions. - Similarly, timing information might be incorrect due to - retransmissions. - -8.3. Multihop Topologies - - In some topologies, RoQ may be used on only some of the links between - multiple session participants. Other links may be using RTP over - UDP, or over some other supported RTP encapsulation protocol, and - some participants might be using implementations that don't support - RoQ at all. These participants will not be able to infer feedback - from QUIC, and they may receive less RTCP feedback than expected. On - the other hand, participants using RoQ might not be aware that other - participants are not using RoQ and send as little RTCP as possible - since they assume their RoQ peer will be able to infer statistics - from QUIC. There are two ways to solve this problem: if the - middlebox translating between RoQ and RTP over other RTP transport - protocols such as UDP or TCP provides Back-to-Back RTP sessions as - described in Section 3.2.2 of [RFC7667], this middlebox can add RTCP - packets for the participants not using RoQ by using the statistics - the middlebox gets from QUIC and the mappings described in the - following sections. If the middlebox does not provide Back-to-Back - RTP sessions, participants may use additional signalling to let the - RoQ participants know what RTCP is required. - -8.4. Feedback Mappings - - This section explains how some of the RTCP packet types that are used - to signal reception statistics can be replaced by equivalent - statistics that are already collected by QUIC. The following list - explains how this mapping can be achieved for the individual fields - of different RTCP packet types. - - The list of RTCP packets in this section is not exhaustive, and - similar considerations SHOULD be taken into account before exchanging - any other type of RTCP control packets using RoQ. - - A more thorough analysis of RTCP Control Packet Types (in - Appendix B.1), Generic RTP Feedback (RTPFB) (in Appendix B.3), - Payload-specific RTP Feedback (PSFB) (in Appendix B.4), Extended - Reports (in Appendix B.2), and RTP Header Extensions (in - Appendix B.5), including the information that cannot be mapped from - QUIC. - -8.4.1. Negative Acknowledgments ("NACK") - - Generic _Negative Acknowledgments_ (PT=205, FMT=1, Name=Generic NACK, - [RFC4585]) contain information about RTP packets which the receiver - considered lost. Section 6.2.1. of [RFC4585] recommends using this - feature only if the underlying protocol cannot provide similar - feedback. QUIC does not provide negative acknowledgments but can - detect lost packets based on the Gap numbers contained in QUIC ACK - frames (Section 6 of [RFC9002]). - -8.4.2. ECN Feedback ("ECN") - - _ECN Feedback_ (PT=205, FMT=8, Name=RTCP-ECN-FB, [RFC6679]) packets - report the count of observed ECN-CE marks. [RFC6679] defines two - RTCP reports, one packet type (with PT=205 and FMT=8), and a new - report block for the extended reports, which are listed above. QUIC - supports ECN reporting through acknowledgments. If the QUIC - connection supports ECN, the reporting of ECN counts SHOULD be done - using QUIC acknowledgments rather than RTCP ECN feedback reports. - -8.4.3. Goodbye Packets ("BYE") - - RTP session participants can use _Goodbye_ RTCP packets (PT=203, - Name=BYE, [RFC3550]), to indicate that a source is no longer active. - If the participant is also going to close the QUIC connection, the - _BYE_ packet can be replaced by a QUIC CONNECTION_CLOSE frame. In - this case, the reason for leaving can be transmitted in QUIC's - CONNECTION_CLOSE _Reason Phrase_. However, if the participant wishes - to use this QUIC connection for any other multiplexed traffic, the - participant has to use the BYE packet because the QUIC - CONNECTION_CLOSE would close the entire QUIC connection for all other - QUIC streams and datagrams. - -9. Error Handling - - The following error codes are defined for use when abruptly - terminating streams, aborting reading of streams, or immediately - closing RoQ connections. - - ROQ_NO_ERROR (0x00): No error. This is used when the connection or - stream needs to be closed, but there is no error to signal. - - ROQ_GENERAL_ERROR (0x01): An error that does not match a more - specific error code occured. - - ROQ_INTERNAL_ERROR (0x02): An internal error has occured in the RoQ - stack. - - ROQ_PACKET_ERROR (0x03): Invalid payload format, e.g., length does - not match packet, invalid flow id encoding, non-RTP on RTP-flow - ID, etc. - - ROQ_STREAM_CREATION_ERROR (0x04): The endpoint detected that its - peer created a stream that violates the ROQ protocol. - - ROQ_FRAME_CANCELLED (0x05): A receiving endpoint is using - STOP_SENDING on the current stream to request new frames be sent - on new streams. Similarly, a sender notifies a receiver that - retransmissions of a frame were stopped using RESET_STREAM and new - frames will be sent on new streams. - - ROQ_UNKNOWN_FLOW_ID (0x06): An endpoint was unable to handle a flow - identifier, e.g., because it was not signalled or because the - endpoint does not support multiplexing using arbitrary flow - identifiers. - - ROQ_EXPECTATION_UNMET (0x07): Expectiations of the QUIC transport - set by RoQ out-of-band signalling were not met by the QUIC - connection. - -10. API Considerations - - The mapping described in the previous sections poses some interface - requirements for the QUIC implementation. Although RoQ works without - these requirements, some optimizations regarding rate adaptation and - RTCP mapping require certain functionalities to be exposed to the - application. - - Each item in the following list can be considered individually. Any - exposed information or function can be used by RoQ regardless of - whether the other items are available. Thus, RoQ does not depend on - the availability of all of the listed features but can apply - different optimizations depending on the functionality exposed by the - QUIC implementation. - - * _Maximum Datagram Size_: The maximum datagram size that the QUIC - connection can transmit on the network path to the QUIC receiver. - If a RoQ sender using datagrams does not know the maximum datagram - size for the path to the RoQ receiver, there are only two choices - - either use heuristics to limit the size of RoQ messages, or be - prepared to lose RoQ messages that were too large to be carried - through the network path and delivered to the RoQ receiver. - - * _Datagram Acknowledgment and Loss_: Section 5.2 of [RFC9221] - allows QUIC implementations to notify the application that a QUIC - Datagram was acknowledged or that it believes a datagram was lost. - Given the datagram acknowledgments and losses, the application can - deduce which RTP packets arrived at the receiver and which were - lost (see also Section 8.1). - - * _Stream States_: The stream states include which parts of the data - sent on a stream were successfully delivered and which are still - outstanding to be sent or retransmitted. If an application keeps - track of the RTP packets sent on a stream, their respective sizes, - and in which order they were transmitted, it can infer which RTP - packets were acknowledged according to the definition in - Section 8.2. - - * _Arrival timestamps_: If the QUIC connection uses a timestamp - extension like [I-D.draft-smith-quic-receive-ts] or - [I-D.draft-huitema-quic-ts], the arrival timestamps or one-way - delays can support the application as described in Section 8 and - Section 7. - - * _Bandwidth Estimation_: If a bandwidth estimation is available in - the QUIC implementation, exposing it avoids the implementation of - an additional bandwidth estimation algorithm in the application. - - * _ECN_: If ECN marks are available, they can support the bandwidth - estimation of the application if necessary. - -11. Discussion - -11.1. Impact of Connection Migration - - RTP sessions are characterized by a continuous flow of packets into - either or both directions. A connection migration may lead to - pausing media transmission until reachability of the peer under the - new address is validated. This may lead to short breaks in media - delivery in the order of RTT and, if RTCP is used for RTT - measurements, may cause spikes in observed delays. Application layer - congestion control mechanisms (and also packet repair schemes such as - retransmissions) need to be prepared to cope with such spikes. - - If a QUIC connection is established via a signaling channel, this - signaling may have involved Interactive Connectivity Establishment - (ICE) exchanges to determine and choose suitable (IP address, port - number) pairs for the QUIC connection. Subsequent address change - events may be noticed by QUIC via its connection migration handling - and/or at the ICE or other application layer, e.g., by noticing - changing IP addresses at the network interface. This may imply that - the two signaling and data "layers" get (temporarily) out of sync. - - *Editor's Note:* It may be desirable that the API provides an - indication of connection migration event for either case. - -11.2. 0-RTT considerations - - For repeated connections between peers, the initiator of a QUIC - connection can use 0-RTT data for both QUIC streams and datagrams. - As such packets are subject to replay attacks, applications shall - carefully specify which data types and operations are allowed. 0-RTT - data may be beneficial for use with RoQ to reduce the risk of media - clipping, e.g., at the beginning of a conversation. - - This specification defines carrying RTP on top of QUIC and thus does - not finally define what the actual application data are going to be. - RTP typically carries ephemeral media contents that is rendered and - possibly recorded but otherwise causes no side effects. Moreover, - the amount of data that can be carried as 0-RTT data is rather - limited. But it is the responsibility of the respective application - to determine if 0-RTT data is permissible. - - *Editor's Note:* Since the QUIC connection will often be created - in the context of an existing signaling relationship (e.g., using - WebRTC or SIP), specific 0-RTT keying material could be exchanged - to prevent replays across sessions. Within the same connection, - replayed media packets would be discarded as duplicates by the - receiver. - -12. Security Considerations - - RoQ is subject to the security considerations of RTP described in - Section 9 of [RFC3550] and the security considerations of any RTP - profile in use. - - The security considerations for the QUIC protocol and datagram - extension described in Section 21 of [RFC9000], Section 9 of - [RFC9001], Section 8 of [RFC9002] and Section 6 of [RFC9221] also - apply to RoQ. - - Note that RoQ provides mandatory security, and other RTP transports - do not. In order to prevent the inadvertent disclosure of RTP - sessions to unintended third parties, RTP topologies described in - Section 3.2 that include middleboxes supporting both RoQ and non-RoQ - paths MUST forward RTP packets on non-RoQ paths using a secure AVP - profile ([RFC3711], [RFC4585], or another AVP profile providing - equivalent RTP-level security), whether or not RoQ senders are using - a secure AVP profile for those RTP packets. - -13. IANA Considerations - - This document registers a new ALPN protocol ID (in Section 13.1) and - creates a new registry that manages the assignment of error code - points in RoQ (in Section 13.2). - -13.1. Registration of a RoQ Identification String - - This document creates a new registration for the identification of - RoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) - Protocol IDs" registry [RFC7301]. - - The "rtp-mux-quic" string identifies RoQ: - - Protocol: RTP over QUIC (RoQ) - - Identification Sequence: 0x72 0x74 0x70 0x2D 0x6F 0x76 0x65 0x72 - 0x2D 0x71 0x75 0x69 0x63 ("rtp-mux-quic") - - Specification: This document - -13.2. RoQ Error Codes Registry - - This document establishes a registry for RoQ error codes. The "RTP - over QUIC (RoQ) Error Codes" registry manages a 62-bit space and is - listed under the "Real-Time Transport Protocol (RTP) Parameters" - heading. - - The new error codes registry created in this document operates under - the QUIC registration policy documented in Section 22.1 of [RFC9000]. - This registry includes the common set of fields listed in - Section 22.1.1 of [RFC9000]. - - Permanent registrations in this registry are assigned using the - Specification Required policy ([RFC8126]), except for values between - 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using - Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 - of [RFC8126]. - - Registrations for error codes are required to include a description - of the error code. An expert reviewer is advised to examine new - registrations for possible duplication or interaction with existing - error codes. - - In addition to common fields as described in Section Section 22.1 of - [RFC9000], this registry includes two additional fields. Permanent - registrations in this registry MUST include the following fields: - - Name: A name for the error code. - - Description: A brief description of the error code semantics, which - MAY be a summary if a specification reference is provided. - - The initial allocations in this registry are all assigned permanent - status and list a change controller of the IETF and a contact of the - AVTCORE working group (avt@ietf.org). - - The entries in Table 2 are registered by this document. - - +=======+===========================+=============+===============+ - | Value | Name | Description | Specification | - +=======+===========================+=============+===============+ - | 0x00 | ROQ_NO_ERROR | No Error | Section 9 | - +-------+---------------------------+-------------+---------------+ - | 0x01 | ROQ_GENERAL_ERROR | General | Section 9 | - | | | error | | - +-------+---------------------------+-------------+---------------+ - | 0x02 | ROQ_INTERNAL_ERROR | Internal | Section 9 | - | | | Error | | - +-------+---------------------------+-------------+---------------+ - | 0x03 | ROQ_PACKET_ERROR | Invalid | Section 9 | - | | | payload | | - | | | format | | - +-------+---------------------------+-------------+---------------+ - | 0x04 | ROQ_STREAM_CREATION_ERROR | Invalid | Section 9 | - | | | stream type | | - +-------+---------------------------+-------------+---------------+ - | 0x05 | ROQ_FRAME_CANCELLED | Frame | Section 9 | - | | | cancelled | | - +-------+---------------------------+-------------+---------------+ - | 0x06 | ROQ_UNKNOWN_FLOW_ID | Unknown | Section 9 | - | | | Flow ID | | - +-------+---------------------------+-------------+---------------+ - | 0x07 | ROQ_EXPECTATION_UNMET | Externally | Section 9 | - | | | signalled | | - | | | requirement | | - | | | unmet | | - +-------+---------------------------+-------------+---------------+ - - Table 2: Initial RoQ Error Codes - -14. References - -14.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. - Jacobson, "RTP: A Transport Protocol for Real-Time - Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, - July 2003, . - - [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and - Video Conferences with Minimal Control", STD 65, RFC 3551, - DOI 10.17487/RFC3551, July 2003, - . - - [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., - "RTP Control Protocol Extended Reports (RTCP XR)", - RFC 3611, DOI 10.17487/RFC3611, November 2003, - . - - [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, - "Extended RTP Profile for Real-time Transport Control - Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, - DOI 10.17487/RFC4585, July 2006, - . - - [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. - Hakenberg, "RTP Retransmission Payload Format", RFC 4588, - DOI 10.17487/RFC4588, July 2006, - . - - [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., - and K. Carlberg, "Explicit Congestion Notification (ECN) - for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August - 2012, . - - [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, - "Transport Layer Security (TLS) Application-Layer Protocol - Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, - July 2014, . - - [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, - DOI 10.17487/RFC7667, November 2015, - . - - [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - DOI 10.17487/RFC0768, August 1980, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation - for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December - 2017, . - - [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- - Assisted Dynamic Adaptation (NADA): A Unified Congestion - Control Scheme for Real-Time Media", RFC 8698, - DOI 10.17487/RFC8698, February 2020, - . - - [RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control - Requirements for Interactive Real-Time Media", RFC 8836, - DOI 10.17487/RFC8836, January 2021, - . - - [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP - Control Protocol (RTCP) Feedback for Congestion Control", - RFC 8888, DOI 10.17487/RFC8888, January 2021, - . - - [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", - RFC 8999, DOI 10.17487/RFC8999, May 2021, - . - - [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based - Multiplexed and Secure Transport", RFC 9000, - DOI 10.17487/RFC9000, May 2021, - . - - [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure - QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, - . - - [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection - and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, - May 2021, . - - [RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable - Datagram Extension to QUIC", RFC 9221, - DOI 10.17487/RFC9221, March 2022, - . - -14.2. Informative References - - [I-D.draft-dawkins-avtcore-sdp-rtp-quic] - Dawkins, S., "SDP Offer/Answer for RTP using QUIC as - Transport", Work in Progress, Internet-Draft, draft- - dawkins-avtcore-sdp-rtp-quic-00, 28 January 2022, - . - - [I-D.draft-huitema-quic-ts] - Huitema, C., "Quic Timestamps For Measuring One-Way - Delays", Work in Progress, Internet-Draft, draft-huitema- - quic-ts-08, 28 August 2022, - . - - [I-D.draft-hurst-quic-rtp-tunnelling] - Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, - Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, 28 - January 2021, . - - [I-D.draft-ietf-avtcore-rtcp-green-metadata] - He, Y., Herglotz, C., and E. Francois, "RTP Control - Protocol (RTCP) Messages for Temporal-Spatial Resolution", - Work in Progress, Internet-Draft, draft-ietf-avtcore-rtcp- - green-metadata-02, 12 October 2023, - . - - [I-D.draft-ietf-avtext-lrr-07] - Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. - Flodman, "The Layer Refresh Request (LRR) RTCP Feedback - Message", Work in Progress, Internet-Draft, draft-ietf- - avtext-lrr-07, 2 July 2017, - . - - [I-D.draft-ietf-masque-h3-datagram] - Schinazi, D. and L. Pardue, "HTTP Datagrams and the - Capsule Protocol", Work in Progress, Internet-Draft, - draft-ietf-masque-h3-datagram-11, 17 June 2022, - . - - [I-D.draft-ietf-quic-ack-frequency] - Iyengar, J., Swett, I., and M. Kühlewind, "QUIC - Acknowledgement Frequency", Work in Progress, Internet- - Draft, draft-ietf-quic-ack-frequency-07, 27 October 2023, - . - - [I-D.draft-ietf-quic-multipath] - Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, - C., and M. Kühlewind, "Multipath Extension for QUIC", Work - in Progress, Internet-Draft, draft-ietf-quic-multipath-06, - 23 October 2023, . - - [I-D.draft-ietf-quic-reliable-stream-reset] - Seemann, M. and K. Oku, "Reliable QUIC Stream Resets", - Work in Progress, Internet-Draft, draft-ietf-quic- - reliable-stream-reset-05, 23 January 2024, - . - - [I-D.draft-ietf-rmcat-gcc] - Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. - Mascolo, "A Google Congestion Control Algorithm for Real- - Time Communication", Work in Progress, Internet-Draft, - draft-ietf-rmcat-gcc-02, 8 July 2016, - . - - [I-D.draft-ietf-wish-whip] - Murillo, S. G. and A. Gouaillard, "WebRTC-HTTP ingestion - protocol (WHIP)", Work in Progress, Internet-Draft, draft- - ietf-wish-whip-12, 26 January 2024, - . - - [I-D.draft-smith-quic-receive-ts] - Smith, C. and I. Swett, "QUIC Extension for Reporting - Packet Receive Timestamps", Work in Progress, Internet- - Draft, draft-smith-quic-receive-ts-00, 25 October 2021, - . - - [I-D.draft-thomson-quic-enough] - Thomson, M., "Signaling That a QUIC Receiver Has Enough - Stream Data", Work in Progress, Internet-Draft, draft- - thomson-quic-enough-00, 30 March 2023, - . - - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, - DOI 10.17487/RFC1122, October 1989, - . - - [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, - DOI 10.17487/RFC1191, November 1990, - . - - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", - RFC 3168, DOI 10.17487/RFC3168, September 2001, - . - - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, - A., Peterson, J., Sparks, R., Handley, M., and E. - Schooler, "SIP: Session Initiation Protocol", RFC 3261, - DOI 10.17487/RFC3261, June 2002, - . - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC5093] Hunt, G., "BT's eXtended Network Quality RTP Control - Protocol Extended Reports (RTCP XR XNQ)", RFC 5093, - DOI 10.17487/RFC5093, December 2007, - . - - [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, - "Codec Control Messages in the RTP Audio-Visual Profile - with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, - February 2008, . - - [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in - RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, - . - - [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", - RFC 5484, DOI 10.17487/RFC5484, March 2009, - . - - [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE - Report Block Type for RTP Control Protocol (RTCP) Extended - Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February - 2010, . - - [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control - Protocol (RTCP) Extensions for Single-Source Multicast - Sessions with Unicast Feedback", RFC 5760, - DOI 10.17487/RFC5760, February 2010, - . - - [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and - Control Packets on a Single Port", RFC 5761, - DOI 10.17487/RFC5761, April 2010, - . - - [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP - Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, - . - - [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping - between Unicast and Multicast RTP Sessions", RFC 6284, - DOI 10.17487/RFC6284, June 2011, - . - - [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, - "Unicast-Based Rapid Acquisition of Multicast RTP - Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, - . - - [RFC6332] Begen, A. and E. Friedrich, "Multicast Acquisition Report - Block Type for RTP Control Protocol (RTCP) Extended - Reports (XRs)", RFC 6332, DOI 10.17487/RFC6332, July 2011, - . - - [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time - Transport Protocol (RTP) Header Extension for Client-to- - Mixer Audio Level Indication", RFC 6464, - DOI 10.17487/RFC6464, December 2011, - . - - [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- - time Transport Protocol (RTP) Header Extension for Mixer- - to-Client Audio Level Indication", RFC 6465, - DOI 10.17487/RFC6465, December 2011, - . - - [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The - NewReno Modification to TCP's Fast Recovery Algorithm", - RFC 6582, DOI 10.17487/RFC6582, April 2012, - . - - [RFC6642] Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol - (RTCP) Extension for a Third-Party Loss Report", RFC 6642, - DOI 10.17487/RFC6642, June 2012, - . - - [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information - Reporting Using a Source Description (SDES) Item and an - RTCP Extended Report (XR) Block", RFC 6776, - DOI 10.17487/RFC6776, October 2012, - . - - [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended - Report (XR) Block for Packet Delay Variation Metric - Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, - . - - [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for Delay Metric - Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, - . - - [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure - Real-time Transport Protocol (SRTP)", RFC 6904, - DOI 10.17487/RFC6904, April 2013, - . - - [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP - Control Protocol (RTCP) Extended Report (XR) Block for - Burst/Gap Loss Metric Reporting", RFC 6958, - DOI 10.17487/RFC6958, May 2013, - . - - [RFC6990] Huang, R., Wu, Q., Asaeda, H., and G. Zorn, "RTP Control - Protocol (RTCP) Extended Report (XR) Block for MPEG-2 - Transport Stream (TS) Program Specific Information (PSI) - Independent Decodability Statistics Metrics Reporting", - RFC 6990, DOI 10.17487/RFC6990, August 2013, - . - - [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for Discard Count Metric - Reporting", RFC 7002, DOI 10.17487/RFC7002, September - 2013, . - - [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control - Protocol (RTCP) Extended Report (XR) Block for Burst/Gap - Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, - September 2013, . - - [RFC7004] Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP - Control Protocol (RTCP) Extended Report (XR) Blocks for - Summary Statistics Metrics Reporting", RFC 7004, - DOI 10.17487/RFC7004, September 2013, - . - - [RFC7005] Clark, A., Singh, V., and Q. Wu, "RTP Control Protocol - (RTCP) Extended Report (XR) Block for De-Jitter Buffer - Metric Reporting", RFC 7005, DOI 10.17487/RFC7005, - September 2013, . - - [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control - Protocol (RTCP) Extended Report (XR) for RLE of Discarded - Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, - . - - [RFC7243] Singh, V., Ed., Ott, J., and I. Curcio, "RTP Control - Protocol (RTCP) Extended Report (XR) Block for the Bytes - Discarded Metric", RFC 7243, DOI 10.17487/RFC7243, May - 2014, . - - [RFC7244] Asaeda, H., Wu, Q., and R. Huang, "RTP Control Protocol - (RTCP) Extended Report (XR) Blocks for Synchronization - Delay and Offset Metrics Reporting", RFC 7244, - DOI 10.17487/RFC7244, May 2014, - . - - [RFC7266] Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control - Protocol (RTCP) Extended Report (XR) Blocks for Mean - Opinion Score (MOS) Metric Reporting", RFC 7266, - DOI 10.17487/RFC7266, June 2014, - . - - [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., - Boronat, F., Montagud, M., and K. Gross, "Inter- - Destination Media Synchronization (IDMS) Using the RTP - Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, - June 2014, . - - [RFC7294] Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control - Protocol (RTCP) Extended Report (XR) Blocks for - Concealment Metrics Reporting on Audio Applications", - RFC 7294, DOI 10.17487/RFC7294, July 2014, - . - - [RFC7380] Tong, J., Bi, C., Ed., Even, R., Wu, Q., Ed., and R. - Huang, "RTP Control Protocol (RTCP) Extended Report (XR) - Block for MPEG2 Transport Stream (TS) Program Specific - Information (PSI) Decodability Statistics Metrics - Reporting", RFC 7380, DOI 10.17487/RFC7380, November 2014, - . - - [RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP) - Extended Report (XR) for Post-Repair Loss Count Metrics", - RFC 7509, DOI 10.17487/RFC7509, May 2015, - . - - [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP - Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, - February 2016, . - - [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., - and M. Stiemerling, Ed., "Real-Time Streaming Protocol - Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December - 2016, . - - [RFC7867] Huang, R., "RTP Control Protocol (RTCP) Extended Report - (XR) Block for Loss Concealment Metrics for Video - Applications", RFC 7867, DOI 10.17487/RFC7867, July 2016, - . - - [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP - Header Extension for the RTP Control Protocol (RTCP) - Source Description Items", RFC 7941, DOI 10.17487/RFC7941, - August 2016, . - - [RFC8015] Singh, V., Perkins, C., Clark, A., and R. Huang, "RTP - Control Protocol (RTCP) Extended Report (XR) Block for - Independent Reporting of Burst/Gap Discard Metrics", - RFC 8015, DOI 10.17487/RFC8015, November 2016, - . - - [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: - Circuit Breakers for Unicast RTP Sessions", RFC 8083, - DOI 10.17487/RFC8083, March 2017, - . - - [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage - Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, - March 2017, . - - [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., - "Path MTU Discovery for IP version 6", STD 87, RFC 8201, - DOI 10.17487/RFC8201, July 2017, - . - - [RFC8286] Xia, J., Even, R., Huang, R., and L. Deng, "RTP/RTCP - Extension for RTP Splicing Notification", RFC 8286, - DOI 10.17487/RFC8286, October 2017, - . - - [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for - Browser-Based Applications", RFC 8825, - DOI 10.17487/RFC8825, January 2021, - . - - [RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to - Controlling Multiple Streams for Telepresence (CLUE) Media - Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021, - . - - [RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream - Identifier Source Description (SDES)", RFC 8852, - DOI 10.17487/RFC8852, January 2021, - . - - [RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending - Multiple Types of Media in a Single RTP Session", - RFC 8860, DOI 10.17487/RFC8860, January 2021, - . - - [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, - "Sending Multiple RTP Streams in a Single RTP Session: - Grouping RTP Control Protocol (RTCP) Reception Statistics - and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, - January 2021, . - - [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. - Völker, "Packetization Layer Path MTU Discovery for - Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, - September 2020, . - - [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, - June 2022, . - - [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, - "Negotiating Media Multiplexing Using the Session - Description Protocol (SDP)", RFC 9143, - DOI 10.17487/RFC9143, February 2022, - . - - [RFC9308] Kühlewind, M. and B. Trammell, "Applicability of the QUIC - Transport Protocol", RFC 9308, DOI 10.17487/RFC9308, - September 2022, . - - [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. - White, "Low Latency, Low Loss, and Scalable Throughput - (L4S) Internet Service: Architecture", RFC 9330, - DOI 10.17487/RFC9330, January 2023, - . - - [RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely - Encrypting RTP Header Extensions and Contributing - Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, - . - - [VJMK88] "Congestion Avoidance and Control", November 1988, - . - - [_3GPP-TS-26.114] - "IP Multimedia Subsystem (IMS); Multimedia telephony; - Media handling and interaction", 5 January 2023, - . - -Appendix A. List of optional QUIC Extensions - - The following is a list of QUIC protocol extensions that might be - beneficial for RoQ, but are not required by RoQ. - - * _An Unreliable Datagram Extension to QUIC_ [RFC9221]. Without - support for unreliable datagrams, RoQ cannot use the encapsulation - specified in Section 5.3, but can still use QUIC streams as - specified in Section 5.2. - - * A version of QUIC receive timestamps can be helpful for improved - jitter calculations and congestion control. If the QUIC - connection uses a timestamp extension like, the arrival timestamps - or one-way delays could be exposed to the application for improved - bandwidth estimation or RTCP mappings as described in Section 8 - and Appendix B. - - - _Quic Timestamps For Measuring One-Way Delays_ - [I-D.draft-huitema-quic-ts] - - - _QUIC Extension for Reporting Packet Receive Timestamps_ - [I-D.draft-smith-quic-receive-ts] - - * _QUIC Acknowledgement Frequency_ - [I-D.draft-ietf-quic-ack-frequency] can be used by a sender to - optimize the acknowledgement behaviour of the receiver, e.g., to - optimize congestion control. - - * _Signaling That a QUIC Receiver Has Enough Stream Data_ - [I-D.draft-thomson-quic-enough] and _Reliable QUIC Stream Resets_ - [I-D.draft-ietf-quic-reliable-stream-reset] would allow RoQ - senders and receivers to use versions of CLOSE_STREAM and - STOP_SENDING that contain offsets. The offset could be used to - reliably retransmit all frames up to a certain frame that should - be cancelled before resuming transmission of further frames on new - QUIC streams. - -Appendix B. Considered RTCP Packet Types and RTP Header Extensions - - This section lists all the RTCP packet types and RTP header - extensions that were considered in the analysis described in - Section 8. - - Several but not all of these control packets and their attributes can - be mapped from QUIC, as described in Section 8.4. _Mappable from - QUIC_ has one of four values: _yes_, _partly_, _QUIC extension - needed_, and _no_. _Partly_ is used for packet types for which some - fields can be mapped from QUIC, but not all. _QUIC extension needed_ - describes packet types which could be mapped with help from one or - more QUIC extensions. - - Examples of how certain packet types could be mapped with the help of - QUIC extensions follow in Appendix B.6. - -B.1. RTCP Control Packet Types - - +==============+========+===+===========+===========+===============+ - | Name |Shortcut|PT | Defining | Mappable | Comments | - | | | | Document | from QUIC | | - +==============+========+===+===========+===========+===============+ - | SMPTE time- |SMPTETC |194| [RFC5484] | no | | - | code mapping | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Extended |IJ |195| [RFC5450] | no | Would | - | inter- | | | | | require | - | arrival | | | | | send- | - | jitter | | | | | timestamps, | - | report | | | | | which are | - | | | | | | not provided | - | | | | | | by any QUIC | - | | | | | | extension | - | | | | | | today | - +--------------+--------+---+-----------+-----------+---------------+ - | Sender |SR |200| [RFC3550] | QUIC | see Appendix | - | Reports | | | | extension | B.6.4 and | - | | | | | needed / | Appendix | - | | | | | partly | B.6.1 | - +--------------+--------+---+-----------+-----------+---------------+ - | Receiver |RR |201| [RFC3550] | QUIC | see Appendix | - | Reports | | | | extension | B.6.1 | - | | | | | needed | | - +--------------+--------+---+-----------+-----------+---------------+ - | Source |SDES |202| [RFC3550] | no | | - | description | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Goodbye |BYE |203| [RFC3550] | partly | see Section | - | | | | | | 8.4.3 | - +--------------+--------+---+-----------+-----------+---------------+ - | Application- |APP |204| [RFC3550] | no | | - | defined | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Generic RTP |RTPFB |205| [RFC4585] | partly | see | - | Feedback | | | | | Appendix B.3 | - +--------------+--------+---+-----------+-----------+---------------+ - | Payload- |PSFB |205| [RFC4585] | partly | see | - | specific | | | | | Appendix B.4 | - +--------------+--------+---+-----------+-----------+---------------+ - | extended |XR |207| [RFC3611] | partly | see | - | report | | | | | Appendix B.2 | - +--------------+--------+---+-----------+-----------+---------------+ - | AVB RTCP |AVB | | | | | - | packet | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Receiver |RSI |209| [RFC5760] | | | - | Summary | | | | | | - | Information | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Port Mapping |TOKEN |210| [RFC6284] | no | | - +--------------+--------+---+-----------+-----------+---------------+ - | IDMS |IDMS |211| [RFC7272] | no | | - | Settings | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Reporting |RGRS |212| [RFC8861] | | | - | Group | | | | | | - | Reporting | | | | | | - | Sources | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - | Splicing |SNM |213| [RFC8286] | no | | - | Notification | | | | | | - | Message | | | | | | - +--------------+--------+---+-----------+-----------+---------------+ - - Table 3 - -B.2. Extended Reports (XR) - - +===============+==========+=========+==================================+ - |Name |Document |Mappable |Comments | - | | |from QUIC| | - +===============+==========+=========+==================================+ - |Loss RLE Report|[RFC3611] |yes |If only used for acknowledgment, | - |Block | | |could be replaced by QUIC | - | | | |acknowledgments, see Section 8.1 | - | | | |and Section 8.2 | - +---------------+----------+---------+----------------------------------+ - |Duplicate RLE |[RFC3611] |no | | - |Report Block | | | | - +---------------+----------+---------+----------------------------------+ - |Packet Receipt |[RFC3611] |QUIC |QUIC could provide packet receive | - |Times Report | |extension|timestamps when using a timestamp | - |Block | |needed / |extension that reports timestamp | - | | |partly |for every received packet, such as| - | | | |[I-D.draft-smith-quic-receive-ts].| - | | | |However, QUIC does not provide | - | | | |feedback in RTP timestamp format. | - +---------------+----------+---------+----------------------------------+ - |Receiver |[RFC3611] |QUIC |Used together with DLRR Report | - |Reference Time | |extension|Blocks to calculate RTTs of non- | - |Report Block | |needed |senders. RTT measurements can | - | | | |natively be provided by QUIC. | - +---------------+----------+---------+----------------------------------+ - |DLRR Report |[RFC3611] |QUIC |Used together with Receiver | - |Block | |extension|Reference Time Report Blocks to | - | | |needed |calculate RTTs of non-senders. | - | | | |RTT can natively be provided by | - | | | |QUIC. | - +---------------+----------+---------+----------------------------------+ - |Statistics |[RFC3611] |QUIC |Packet loss and jitter can be | - |Summary Report | |extension|inferred from QUIC | - |Block | |needed / |acknowledgments, if a timestamp | - | | |partly |extension is used (see | - | | | |[I-D.draft-smith-quic-receive-ts] | - | | | |or [I-D.draft-huitema-quic-ts]). | - | | | |The remaining fields cannot be | - | | | |mapped to QUIC. | - +---------------+----------+---------+----------------------------------+ - |VoIP Metrics |[RFC3611] |no |as in other reports above, only | - |Report Block | | |loss and RTT available | - +---------------+----------+---------+----------------------------------+ - |RTCP XR |[RFC5093] |no | | - +---------------+----------+---------+----------------------------------+ - |Texas | | | | - |Instruments | | | | - |Extended VoIP | | | | - |Quality Block | | | | - +---------------+----------+---------+----------------------------------+ - |Post-repair |[RFC5725] |no | | - |Loss RLE Report| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Multicast |[RFC6332] |no | | - |Acquisition | | | | - |Report Block | | | | - +---------------+----------+---------+----------------------------------+ - |IDMS Report |[RFC7272] |no | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |ECN Summary |[RFC6679] |partly |see Section 8.4.2 | - |Report | | | | - +---------------+----------+---------+----------------------------------+ - |Measurement |[RFC6776] |no | | - |Information | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Packet Delay |[RFC6798] |no |QUIC timestamps may be used to | - |Variation | | |achieve the same goal? | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Delay Metrics |[RFC6843] |no |QUIC has RTT and can provide | - |Block | | |timestamps for one-way delay, but | - | | | |no way of informing peers about | - | | | |end-to-end statistics when QUIC is| - | | | |only used on one segment of the | - | | | |path. | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap Loss |[RFC7004] | |QUIC ACKs? | - |Summary | | | | - |Statistics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap |[RFC7004] |no | | - |Discard Summary| | | | - |Statistics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Frame |[RFC7004] |no | | - |Impairment | | | | - |Statistics | | | | - |Summary | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap Loss |[RFC6958] | |QUIC ACKs? | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Burst/Gap |[RFC7003] |no | | - |Discard Metrics| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |MPEG2 Transport|[RFC6990] |no | | - |Stream PSI- | | | | - |Independent | | | | - |Decodability | | | | - |Statistics | | | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |De-Jitter |[RFC7005] |no | | - |Buffer Metrics | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Discard Count |[RFC7002] |no | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |DRLE (Discard |[RFC7097] |no | | - |RLE Report) | | | | - +---------------+----------+---------+----------------------------------+ - |BDR (Bytes |[RFC7243] |no | | - |Discarded | | | | - |Report) | | | | - +---------------+----------+---------+----------------------------------+ - |RFISD (RTP |[RFC7244] |no | | - |Flows Initial | | | | - |Synchronization| | | | - |Delay) | | | | - +---------------+----------+---------+----------------------------------+ - |RFSO (RTP Flows|[RFC7244] |no | | - |Synchronization| | | | - |Offset Metrics | | | | - |Block) | | | | - +---------------+----------+---------+----------------------------------+ - |MOS Metrics |[RFC7266] |no | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |LCB (Loss |[RFC7294],|no | | - |Concealment |Section | | | - |Metrics Block) |4.1 | | | - +---------------+----------+---------+----------------------------------+ - |CSB (Concealed |[RFC7294],|no | | - |Seconds Metrics|Section | | | - |Block) |4.1 | | | - +---------------+----------+---------+----------------------------------+ - |MPEG2 Transport|[RFC7380] |no | | - |Stream PSI | | | | - |Decodability | | | | - |Statistics | | | | - |Metrics Block | | | | - +---------------+----------+---------+----------------------------------+ - |Post-Repair |[RFC7509] |no | | - |Loss Count | | | | - |Metrics Report | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Video Loss |[RFC7867] |no | | - |Concealment | | | | - |Metric Report | | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - |Independent |[RFC8015] |no | | - |Burst/Gap | | | | - |Discard Metrics| | | | - |Block | | | | - +---------------+----------+---------+----------------------------------+ - - Table 4: Extended Report Blocks - -B.3. Generic RTP Feedback (RTPFB) - - +=======+=================+=================+=========+================+ - |Name |Long Name |Document |Mappable |Comments | - | | | |from QUIC| | - +=======+=================+=================+=========+================+ - |Generic|Generic negative |[RFC4585] |partly |see | - |NACK |acknowledgement | | |Section 8.4.1 | - +-------+-----------------+-----------------+---------+----------------+ - |TMMBR |Temporary Maximum|[RFC5104] |no | | - | |Media Stream Bit | | | | - | |Rate Request | | | | - +-------+-----------------+-----------------+---------+----------------+ - |TMMBN |Temporary Maximum|[RFC5104] |no | | - | |Media Stream Bit | | | | - | |Rate Notification| | | | - +-------+-----------------+-----------------+---------+----------------+ - |RTCP- |RTCP Rapid |[RFC6051] |no | | - |SR-REQ |Resynchronisation| | | | - | |Request | | | | - +-------+-----------------+-----------------+---------+----------------+ - |RAMS |Rapid Acquisition|[RFC6285] |no | | - | |of Multicast | | | | - | |Sessions | | | | - +-------+-----------------+-----------------+---------+----------------+ - |TLLEI |Transport-Layer |[RFC6642] |no? |no way of | - | |Third-Party Loss | | |telling QUIC | - | |Early Indication | | |peer "don't ask | - | | | | |for | - | | | | |retransmission",| - | | | | |but QUIC would | - | | | | |not ask that | - | | | | |anyway, only | - | | | | |RTCP NACK? | - +-------+-----------------+-----------------+---------+----------------+ - |RTCP- |RTCP ECN Feedback|[RFC6679] |partly |see | - |ECN-FB | | | |Section 8.4.2 | - +-------+-----------------+-----------------+---------+----------------+ - |PAUSE- |Media Pause/ |[RFC7728] |no | | - |RESUME |Resume | | | | - +-------+-----------------+-----------------+---------+----------------+ - |DBI |Delay Budget |[_3GPP-TS-26.114]| | | - | |Information (DBI)| | | | - +-------+-----------------+-----------------+---------+----------------+ - |CCFB |RTP Congestion |[RFC8888] |QUIC |see | - | |Control Feedback | |extension|Appendix B.6.2 | - | | | |needed | | - +-------+-----------------+-----------------+---------+----------------+ - - Table 5 - -B.4. Payload-specific RTP Feedback (PSFB) - - Because QUIC is a generic transport protocol, QUIC feedback cannot - replace the following Payload-specific RTP Feedback (PSFB) feedback. - - +=====+============+==============================================+ - |Name |Long Name | Document | - +=====+============+==============================================+ - |PLI |Picture Loss| [RFC4585] | - | |Indication | | - +-----+------------+----------------------------------------------+ - |SLI |Slice Loss | [RFC4585] | - | |Indication | | - +-----+------------+----------------------------------------------+ - |RPSI |Reference | [RFC4585] | - | |Picture | | - | |Selection | | - | |Indication | | - +-----+------------+----------------------------------------------+ - |FIR |Full Intra | [RFC5104] | - | |Request | | - | |Command | | - +-----+------------+----------------------------------------------+ - |TSTR |Temporal- | [RFC5104] | - | |Spatial | | - | |Trade-off | | - | |Request | | - +-----+------------+----------------------------------------------+ - |TSTN |Temporal- | [RFC5104] | - | |Spatial | | - | |Trade-off | | - | |Notification| | - +-----+------------+----------------------------------------------+ - |VBCM |Video Back | [RFC5104] | - | |Channel | | - | |Message | | - +-----+------------+----------------------------------------------+ - |PSLEI|Payload- | [RFC6642] | - | |Specific | | - | |Third-Party | | - | |Loss Early | | - | |Indication | | - +-----+------------+----------------------------------------------+ - |ROI |Video | [_3GPP-TS-26.114] | - | |region-of- | | - | |interest | | - | |(ROI) | | - +-----+------------+----------------------------------------------+ - |LRR |Layer | [I-D.draft-ietf-avtext-lrr-07] | - | |Refresh | | - | |Request | | - | |Command | | - +-----+------------+----------------------------------------------+ - |VP |Viewport | [_3GPP-TS-26.114] | - | |(VP) | | - +-----+------------+----------------------------------------------+ - |AFB |Application | [RFC4585] | - | |Layer | | - | |Feedback | | - +-----+------------+----------------------------------------------+ - |TSRR |Temporal- | [I-D.draft-ietf-avtcore-rtcp-green-metadata] | - | |Spatial | | - | |Resolution | | - | |Request | | - +-----+------------+----------------------------------------------+ - |TSRN |Temporal- | [I-D.draft-ietf-avtcore-rtcp-green-metadata] | - | |Spatial | | - | |Resolution | | - | |Notification| | - +-----+------------+----------------------------------------------+ - - Table 6 - -B.5. RTP Header extensions - - Like the payload-specific feedback packets, QUIC cannot directly - replace the control information in the following header extensions. - RoQ does not place restrictions on sending any RTP header extensions. - However, some extensions, such as Transmission Time offsets [RFC5450] - are used to improve network jitter calculation, which can be done in - QUIC if a timestamp extension is used. - -B.5.1. Compact Header Extensions - - +====================+================+=================+===========+ - |Extension URI |Description |Reference |Mappable | - | | | |from QUIC | - +====================+================+=================+===========+ - |urn:ietf:params:rtp-|Transmission |[RFC5450] |no | - |hdrext:toffset |Time offsets | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Audio Level |[RFC6464] |no | - |hdrext:ssrc-audio- | | | | - |level | | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Splicing |[RFC8286] |no | - |hdrext:splicing- |Interval | | | - |interval | | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|SMPTE time-code |[RFC5484] |no | - |hdrext:smpte-tc |mapping | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Reserved as |[RFC7941] |no | - |hdrext:sdes |base URN for | | | - | |RTCP SDES items | | | - | |that are also | | | - | |defined as RTP | | | - | |compact header | | | - | |extensions. | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Synchronisation |[RFC6051] |no | - |hdrext:ntp-64 |metadata: | | | - | |64-bit | | | - | |timestamp | | | - | |format | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Synchronisation |[RFC6051] |no | - |hdrext:ntp-56 |metadata: | | | - | |56-bit | | | - | |timestamp | | | - | |format | | | - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Encrypted |[RFC6904] |no, but | - |hdrext:encrypt |extension | |maybe | - | |header element | |irrelevant?| - +--------------------+----------------+-----------------+-----------+ - |urn:ietf:params:rtp-|Mixer-to-client |[RFC6465] |no | - |hdrext:csrc-audio- |audio level | | | - |level |indicators | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:video- |Higher |[_3GPP-TS-26.114]|probably | - |orientation:6 |granularity | |not(?) | - | |(6-bit) | | | - | |coordination of | | | - | |video | | | - | |orientation | | | - | |(CVO) feature, | | | - | |see clause | | | - | |6.2.3 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:video- |Coordination of |[_3GPP-TS-26.114]|probably | - |orientation |video | |not(?) | - | |orientation | | | - | |(CVO) feature, | | | - | |see clause | | | - | |6.2.3 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:roi-sent |Signalling of |[_3GPP-TS-26.114]|probably | - | |the arbitrary | |not(?) | - | |region-of- | | | - | |interest (ROI) | | | - | |information for | | | - | |the sent video, | | | - | |see clause | | | - | |6.2.3.4 | | | - +--------------------+----------------+-----------------+-----------+ - |urn:3gpp:predefined-|Signalling of |[_3GPP-TS-26.114]|probably | - |roi-sent |the predefined | |not(?) | - | |region-of- | | | - | |interest (ROI) | | | - | |information for | | | - | |the sent video, | | | - | |see clause | | | - | |6.2.3.4 | | | - +--------------------+----------------+-----------------+-----------+ - - Table 7 - -B.5.2. SDES Compact Header Extensions - - +=======================+==================+===========+==========+ - | Extension URI | Description | Reference | Mappable | - | | | | from | - | | | | QUIC | - +=======================+==================+===========+==========+ - | urn:ietf:params:rtp- | Source | [RFC7941] | no | - | hdrext:sdes:cname | Description: | | | - | | Canonical End- | | | - | | Point Identifier | | | - | | (SDES CNAME) | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | RTP Stream | [RFC8852] | no | - | hdrext:sdes:rtp- | Identifier | | | - | stream-id | | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | RTP Repaired | [RFC8852] | no | - | hdrext:sdes:repaired- | Stream | | | - | rtp-stream-id | Identifier | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | CLUE CaptId | [RFC8849] | no | - | hdrext:sdes:CaptId | | | | - +-----------------------+------------------+-----------+----------+ - | urn:ietf:params:rtp- | Media | [RFC9143] | no | - | hdrext:sdes:mid | identification | | | - +-----------------------+------------------+-----------+----------+ - - Table 8 - -B.6. Examples - -B.6.1. Mapping QUIC Feedback to RTCP Receiver Reports ("RR") - - Considerations for mapping QUIC feedback into _Receiver Reports_ - (PT=201, Name=RR, [RFC3550]) are: - - * _Fraction lost_: When RTP packets are carried in QUIC datagrams, - the fraction of lost packets can be directly inferred from QUIC's - acknowledgments. The calculation SHOULD include all packets up to - the acknowledged RTP packet with the highest RTP sequence number. - Later packets SHOULD be ignored since they may still be in flight - unless other QUIC packets that were sent after the RTP packet were - already acknowledged. - - * _Cumulative lost_: Similar to the fraction of lost packets, the - cumulative loss can be inferred from QUIC's acknowledgments, - including all packets up to the latest acknowledged packet. - - * _Highest Sequence Number received_: In RTCP, this field is a - 32-bit field that contains the highest sequence number a receiver - received in an RTP packet and the count of sequence number cycles - the receiver has observed. A sender sends RTP packets in QUIC - packets and receives acknowledgments for the QUIC packets. By - keeping a mapping from a QUIC packet to the RTP packets - encapsulated in that QUIC packet, the sender can infer the highest - sequence number and number of cycles seen by the receiver from - QUIC acknowledgments. - - * _Interarrival jitter_: If QUIC acknowledgments carry timestamps as - described in [I-D.draft-smith-quic-receive-ts], senders can infer - the interarrival jitter from the arrival timestamps in QUIC - acknowledgments. - - * _Last SR_: Similar to lost packets, the NTP timestamp of the last - received sender report can be inferred from QUIC acknowledgments. - - * _Delay since last SR_: This field is not required when the - receiver reports are entirely replaced by QUIC feedback. - -B.6.2. Congestion Control Feedback ("CCFB") - - RTP _Congestion Control Feedback_ (PT=205, FMT=11, Name=CCFB, - [RFC8888]) contains acknowledgments, arrival timestamps, and ECN - notifications for each received packet. Acknowledgments and ECNs can - be inferred from QUIC as described above. Arrival timestamps can be - added through extended acknowledgment frames as described in - [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts]. - -B.6.3. Extended Report ("XR") - - _Extended Reports_ (PT=207, Name=XR, [RFC3611]) offer an extensible - framework for a variety of different control messages. Some of the - statistics that are defined as extended report blocks can be derived - from QUIC, too. Other report blocks need to be evaluated - individually to determine whether the contained information can be - transmitted using QUIC instead. Table 4 in Appendix B.2 lists - considerations for mapping QUIC feedback to some of the _Extended - Reports_. - -B.6.4. Application Layer Repair and other Control Messages - - While Appendix B.6.1 presented some RTCP packets that can be replaced - by QUIC features, QUIC cannot replace all of the defined RTCP packet - types. This mostly affects RTCP packet types, which carry control - information that is to be interpreted by the RTP application layer - rather than the underlying transport protocol itself. - - * _Sender Reports_ (PT=200, Name=SR, [RFC3550]) are similar to - _Receiver Reports_, as described in Appendix B.6.1. They are sent - by media senders and additionally contain an NTP and an RTP - timestamp and the number of packets and octets transmitted by the - sender. The timestamps can be used by a receiver to synchronize - streams. QUIC cannot provide similar control information since it - does not know about RTP timestamps. A QUIC receiver cannot - calculate the packet or octet counts since it does not know about - lost datagrams. Thus, sender reports are required in RoQ to - synchronize streams at the receiver. The sender reports SHOULD - not contain any receiver report blocks if the information can be - inferred from the QUIC transport as explained in Appendix B.6.1. - - In addition to carrying transmission statistics, RTCP packets can - contain application layer control information that cannot directly be - mapped to QUIC. Examples of this information may include: - - * _Source Description_ (PT=202, Name=SDES) and _Application_ - (PT=204, Name=APP) packet types from [RFC3550], or - - * many of the payload-specific feedback messages (PT=206) defined in - [RFC4585], used to control the codec behavior of the sender. - - Since QUIC does not provide any kind of application layer control - messaging, QUIC feedback cannot be mapped into these RTCP packet - types. If the RTP application needs this information, the RTCP - packet types are used in the same way as they would be used over any - other transport protocol. - -Appendix C. Experimental Results - - An experimental implementation of the mapping described in this - document can be found on Github (https://github.com/mengelbart/rtp- - over-quic). The application implements the RoQ Datagrams mapping and - implements SCReAM congestion control at the application layer. It - can optionally disable the builtin QUIC congestion control (NewReno). - The endpoints only use RTCP for congestion control feedback, which - can optionally be disabled and replaced by the QUIC connection - statistics as described in Section 8.4. - - Experimental results of the implementation can be found on Github - (https://github.com/mengelbart/rtp-over-quic-mininet), too. - -Acknowledgments - - Early versions of this document were similar in spirit to - [I-D.draft-hurst-quic-rtp-tunnelling], although many details differ. - The authors would like to thank Sam Hurst for providing his thoughts - about how QUIC could be used to carry RTP. - - The guidance in Section 5.2 about configuring the number of parallel - unidirectional QUIC streams is based on Section 6.2 of [RFC9114], - with obvious substitutions for RTP/RTCP. - - The authors would like to thank Bernard Aboba, David Schinazi, Lucas - Pardue, Sergio Garcia Murillo, Spencer Dawkins, and Vidhi Goel for - their valuable comments and suggestions contributing to this - document. - -Authors' Addresses - - Jörg Ott - Technical University Munich - Email: ott@in.tum.de - - - Mathis Engelbart - Technical University Munich - Email: mathis.engelbart@gmail.com - - - Spencer Dawkins - Tencent America LLC - Email: spencerdawkins.ietf@gmail.com diff --git a/remove-media-encoder-terminology/index.html b/remove-media-encoder-terminology/index.html deleted file mode 100644 index 5f79f4e..0000000 --- a/remove-media-encoder-terminology/index.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - mengelbart/rtp-over-quic-draft remove-media-encoder-terminology preview - - - - -

Editor's drafts for remove-media-encoder-terminology branch of mengelbart/rtp-over-quic-draft

-

View saved issues, or the latest GitHub issues and pull requests in the repo.

- - - - - - -
RTP over QUIC (RoQ)plain textsame as main
- - -