]> Technical University Munich

ott@in.tum.de

Technical University Munich

mathis.engelbart@gmail.com

General Internet-Draft This document specifies a minimal mapping for encapsulating RTP and RTCP packets within QUIC. It also discusses how to leverage state from the QUIC implementation in the endpoints to reduce the exchange of RTCP packets. Discussion Venues Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Real-time Transport Protocol (RTP) 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. With the advent of QUIC and, most notably, its unreliable DATAGRAM extension, another secure transport protocol becomes available. QUIC and its DATAGRAMs combine desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking) with a secure end-to-end transport that is also expected to work well through NATs and firewalls. Moreover, with QUIC's multiplexing capabilities, reliable and unreliable transport connections as, e.g., needed for WebRTC, can be established with only a single port used at either end of the connection. This document defines a mapping of how to carry RTP over QUIC. The focus is on RTP and RTCP packet mapping and on reducing the amount of RTCP traffic by leveraging state information readily available within a QUIC endpoint. This document also briefly touches upon how to signal media over QUIC using the Session Description Protocol (SDP) . The scope of this document is limited to unicast RTP/RTCP. Note that this draft is similar in spirit to but differs in numerous ways from .

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 when, and only when, they appear in all capitals, as shown here. The following terms are used:

Congestion Controller:

QUIC specifies a congestion controller in , but the specific requirements for interactive real-time media lead to the development of dedicated congestion control algorithms. In this document, the term congestion controller refers to these algorithms dedicated to real-time applications.

Datagram:

Datagrams exist in UDP as well as in QUICs unreliable datagram extension. If not explicitly noted differently, the term datagram in this document refers to a QUIC Datagram as defined in .

Endpoint:

A QUIC server or client that participates in an RTP over QUIC session.

Frame:

A QUIC frame as defined in .

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.

Receiver:

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

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 to illustrate the order and size of fields.

Protocol Overview This document introduces a mapping of the Real-time Transport Protocol (RTP) to the QUIC transport protocol. QUIC supports two transport methods: reliable streams and unreliable datagrams , . RTP over QUIC uses unreliable QUIC datagrams to transport real-time data, and thus, the QUIC implementation MUST support QUICs unreliable datagram extension. Since datagram frames cannot be fragmented, the QUIC implementation MUST also provide a way to query the maximum datagram size so that an application can create RTP packets that always fit into a QUIC datagram frame. specifies that RTP sessions need to be transmitted on different transport addresses to allow multiplexing between them. RTP over QUIC 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 are flow identifiers prepended to each datagram frame as described in . RTP over QUIC uses a flow identifier to replace the network address and port number to multiplex many RTP sessions over the same QUIC connection. A congestion controller can be plugged in to adapt the media bitrate to the available bandwidth. This document does not mandate any congestion control algorithm. Some examples include Network-Assisted Dynamic Adaptation (NADA) and Self-Clocked Rate Adaptation for Multimedia (SCReAM) . These congestion control 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 congestion controller to avoid the additional overhead of the RTCP stream.

Packet Format All RTP and RTCP packets MUST be sent in QUIC datagram frames with the following format:

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.

For multiplexing RTP sessions on the same QUIC connection, each RTP/RTCP packet is prefixed with a flow identifier. This flow identifier serves as a replacement for using different transport addresses per session. A flow identifier is a QUIC variable-length integer which must be unique per stream. RTP and RTCP packets of a single RTP session MAY be sent using the same flow identifier (following the procedures defined in , or they MAY be sent using different flow identifiers. The respective mode of operation MUST be indicated using the appropriate signaling, e.g., when using SDP as discussed in . RTP and RTCP packets of different RTP sessions MUST be sent using different flow identifiers. Differentiating RTP/RTCP datagrams of different RTP sessions from non-RTP/RTCP datagrams is the responsibility of the application by means of appropriate use of flow identifiers and the corresponding signaling. Senders SHOULD consider the header overhead associated with QUIC datagrams and ensure that the RTP/RTCP packets, including their payloads, QUIC, and IP headers, will fit into path MTU.

Congestion Control RTP over QUIC needs to employ congestion control to avoid overloading the network. RTP and QUIC both offer different congestion control mechanisms. QUIC specifies a congestion control algorithm similar to TCP NewReno, but allows senders to choose a different algorithm, as long as the algorithm conforms to the guidelines specified in . RTP does not specify a congestion controller, but provides feedback formats for congestion control (e.g. ) as well as different congestion control algorithms in separate RFCs (e.g. and ). The congestion control algorithms for RTP are specifically tailored for real-time transmissions at low latencies. RTP congestion control mostly works delay-based, using the growing one-way delay as a congestion signal. The available congestion control algorithms for RTP also expose a target_bitrate that can be used to dynamically reconfigure media encoders to produce media at a rate that can be sent in real-time under the given network conditions. This section defines two options for congestion control for RTP over QUIC, but it does not mandate which congestion control algorithms to use. The congestion control algorithm MUST expose a target_bitrate to which the encoder should be configured to fully utilize the available bandwidth. Furthermore, it is assumed that the congestion controller provides a pacing mechanism to determine when a packet can be sent to avoid bursts. The currently proposed congestion control algorithms for real-time communications provide such a pacing mechanism. The use of congestion controllers which don't provide a pacing mechanism is out of scope of this document. Additionally, the section defines how the connection statistics obtained from QUIC can be used to reduce RTCP feedback overhead.

RTCP and QUIC Connection Statistics Since QUIC provides generic congestion signals which allow the implementation of different congestion control algorithms, senders are not dependent on RTCP feedback for congestion control. However, there are some restrictions, and the QUIC implementation MUST fulfill some requirements to use these signals for congestion control instead of RTCP feedback. To estimate the currently available bandwidth, real-time congestion control algorithms keep track of the sent packets and typically require a list of successfully delivered packets together with the timestamps at which they were received by a receiver. The bandwidth estimation can then be used to decide whether the media encoder can be configured to produce output at a higher or lower rate. A congestion controller used for RTP over QUIC should be able to compute an adequate bandwidth estimation using the following inputs:

• t_current: A current timestamp
• pkt_departure: The departure time for each RTP packet sent to the receiver.
• pkt_arrival: The arrival time for each RTP packet that was successfully delivered to the receiver.
• The RTT estimations calculated by QUIC as described in :
  • latest_rtt: The latest RTT sample generated by QUIC.
  • min_rtt: The miminum RTT observed by QUIC over a period of time
  • smoothed_rtt: An exponentially-weighted moving average of the observed RTT values
  • rtt_var: The mean deviation in the observed RTT values
• ecn: Optionally ECN marks may be used, if supported by the network and exposed by the QUIC implementation.

The only value of these inputs not currently available in QUIC is the pkt_arrival. The exact arrival times of QUIC Datagrams can be obtained by using the QUIC extension described in or . QUIC allows acknowledgments to be sent with some delay, which could cause problems for delay-based congestion control algorithms. Sender and receiver can use to avoid feedback inaccuracies caused by delayed acknowledgments. If the QUIC extensions described in / and are not supported by sender and receiver, it is RECOMMENDED to use RTCP feedback reports instead of thee QUIC connection statistics for congestion control.

RTP Congestion Control at the QUIC layer The first option implements congestion control at the QUIC layer by replacing the standard QUIC congestion control with one of the congestion control algorithms for RTP.

• Editor's note: How can a QUIC connection be shared with non-RTP streams, when SCReAM/NADA/GCC is used as congestion controller? Can these algorithms be adapted to allow different streams including non-real-time streams?

• Editor's note: If this option is chosen, but the required QUIC statistics/extensions are not available and the sender has to use RTCP feedback for congestion control, the feedback needs to be fed back to the QUIC implementation.

RTP Congestion Control at the Application Layer The second option implements real-time congestion control at the application layer. This gives an application more control over the congestion controller and the congestion control feedback to use. It is RECOMMENDED to disable QUIC's congestion control when this option is used to avoid interferences between the congestion controllers at different layers.

• Editor's note: Maybe this option should be removed, as it has some issues: 1. It cannot be used in situations where the application is untrusted, such as in Webtransport, where the browser implements QUIC but cannot trust a JS application using it to do the right thing. 2. It is unclear how non-real-time data sharing the same connection can be congestion controlled. 3. If QUIC connection statistics should be used instead of RTCP, these have to be exposed to the application.

Bandwidth Allocation When the QUIC connection is shared between multiple data streams, a share of the available bandwidth should be allocated to each stream. An implementation MUST ensure that a real-time flow is always allowed to send data unless it has exhausted its allocated bandwidth share. This is especially important when the connection is shared with non-real-time flows.

• Editor's note: This section may need to explain the problem that occurs when non-real-time data fills up the congestion window when a real-time flow does not fully use its assigned bandwidth share.

Media Rate Control Independent from which option is chosen to implement congestion control, the sender likely needs to reconfigure the media encoder in reaction to changing network conditions. Common real-time congestion control algorithms expose a target_bitrate for this purpose. An RTP over QUIC implementation can either expose the most recent target_bitrate produced by the congestion controller to the application or accept a callback from the application, which updates the encoder bitrate whenever the congestion controller updates the target_bitrate.

SDP Signalling

• Editor's note: See also .

QUIC is a connection-based protocol that supports connectionless transmissions of DATAGRAM frames within an established connection. As noted above, demultiplexing DATAGRAMS intended for different purposes is up to the application using QUIC. There are several necessary steps to carry out jointly between the communicating peers to enable RTP over QUIC:

1. The protocol identifier for the m= lines MUST be "QUIC/RTP", combined as per with the respective audiovisual profile: for example, "QUIC/RTP/AVP".
2. The peers need to decide whether to establish a new QUIC connection or whether to re-use an existing one. In case of establishing a new connection, the initiator and the responder (client and server) need to be determined. Signaling for this step MUST follow on SDP attributes for connection-oriented media for the a=setup, a=connection, and a=fingerprint attributes. They MUST use the appropriate protocol identification as per 1.
3. The peers must provide a means for identifying RTP sessions carried in QUIC DATAGRAMS. To enable using a common transport connection for one, two, or more media sessions in the first place, the BUNDLE grouping framework MUST be used . All media sections belonging to a bundle group, except the first one, MUST set the port in the m= line to zero and MUST include the a=bundle-only attribute. For disambiguating different RTP session, a reference needs to be provided for each m= line to allow associating this specific media session with a flow identifier. This could be achieved following different approaches:
   • Simply reusing the a=extmap attribute and relying on RTP header extensions for demultiplexing different media packets carried in QUIC DATAGRAM frames.
   • Defining a variant or different flavor of the a=extmap attribute that binds media sessions to flow identifiers used in QUIC DATAGRAMS.
   • Editor's note: It is likely preferable to use multiplexing using QUIC DATAGRAM flow identifiers because this multiplexing mechanisms will also work across RTP and non-RTP media streams.
   In either case, the corresponding identifiers MUST be treated independently for each direction of transmission, so that an endpoint MAY choose its own identifies and only uses SDP to inform its peer which RTP sessions use which identifiers. To this end, SDP MUST be used to indicate the respective flow identifiers for RTP and RTCP of the different RTP sessions (for which we borrow inspiration from ).
4. The peers MUST agree, for each RTP session, whether or not to apply RTP/RTCP multiplexing. If multiplexing RTP and RTCP shall take place on the same flow identifier, this MUST be indicated using the attribute a=rtcp-mux.

A sample session setup offer (liberally borrowed and extended from and could look as follows:

SDP Offer m=video 0 QUIC/RTP/AVP 31 32 b=AS:1000 a=bundle-only a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:2 urn:ietf:params: ]]>

Signaling details to be worked out.

Used RTP/RTCP packet types Any RTP packet can be sent over QUIC and no RTCP packets are used by default. Since QUIC already includes some features which are usually implemented by certain RTCP messages, RTP over QUIC implementations should not need to implement the following RTCP messages:

• PT=205, FMT=1, Name=Generic NACK: Provides Negative Acknowledgments . Acknowledgment and loss notifications are already provided by the QUIC connection.
• PT=205, FMT=8, Name=RTCP-ECN-FB: Provides RTCP ECN Feedback . If supported, ECN may directly be exposed by the used QUIC implementation.
• PT=205, FMT=11, Name=CCFB: RTP Congestion Control Feedback which contains receive marks, timestamps and ECN notifications for each received packet . This can be inferred from QUIC as described in .
• PT=210, FMT=all, Name=Token, specifies a way to dynamically assign ports for RTP receivers. Since QUIC connections manage ports on their own, this is not required for RTP over QUIC.

Discussion

Impact of Connection Migration

Security Considerations TBD

IANA Considerations This document has no IANA actions.

References Normative References Apple Inc. Apple Inc. Google LLC Private Octopus Inc. Google LLC Magic Leap, Inc. Google LLC Fastly Google This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes loss detection and congestion control mechanisms for QUIC. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK] The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension. This specification updates RFCs 3264, 5888, and 7941. This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285. The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK] This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK] Informative References BBC Research & Development Tencent America LLC

Acknowledgments TODO acknowledge.