]> Technical University Munich

ott@in.tum.de

Technical University Munich

mathis.engelbart@gmail.com

Applications and Real-Time Audio/Video Transport Core Maintenance Internet-Draft This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. 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 Discussion of this document takes place on the Audio/Video Transport Core Maintenance Working Group mailing list (avt@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol (). 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.

Background 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. This specification describes an application usage of QUIC (). As a baseline, the specification does not expect more than a standard QUIC implementation as defined in , , , and , 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 , which provides additional desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking). 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.

What's in Scope for this Specification This document defines a mapping for RTP and RTCP over QUIC (this mapping is hereafter referred to as "RTP-over-QUIC"), 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 RTP over QUIC. 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 RTP-over-QUIC 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). RTP-over-QUIC is not intended as a stand-alone media transport, although QUIC transport parameters could be statically configured. The above implies that RTP-over-QUIC 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 (), or, if RTP-over-QUIC is used to replace RTSP (), to a media server. Moreover, this document describes how a QUIC implementation and its API can be extended to improve efficiency of the RTP-over-QUIC protocol operation. RTP-over-QUIC does not impact the usage of RTP Audio Video Profiles (AVP) (), or any RTP-based mechanisms, even though it may render some of them unnecessary, e.g., Secure Real-Time Transport Prococol (SRTP) () 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 RTP-over-QUIC 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, RTP-over-QUIC 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.

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. RTP-over-QUIC 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. RTP-over-QUIC does not define congestion control and rate adaptation algorithms for use with media. However, 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 will also describe the QUIC interface that's being exposed, or if that ends up somewhere else in the document.

RTP-over-QUIC 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 RTP-over-QUIC. This document does not cover signaling for session setup. SDP for RTP-over-QUIC is defined in separate documents such as , and can be carried in any signaling protocol that can carry SDP, including the Session Initiation Protocol (SIP) (), Real-Time Protocols for Browser-Based Applications (RTCWeb) (), or WebRTC-HTTP Ingestion Protocol (WHIP) ().

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.

• Editor's note: the list of terms below will almost certainly grow in size as the specification matures.

The following terms are used:

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 .

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.

Rate Adaptation:

A mechanism to help a sender determine and adjust its sending rate, in order to maximize the amount of information that is sent to a receiver, without causing queues to build beyond a reasonable amount, causing "buffer bloat" and "jitter". Rate adapation is one way to accomplish congestion control for realtime media, especially when a sender has multiple media streams to the receiver, because the sum of all sending rates for media streams must not be high enough to cause congestion on the path these media streams share between sender and receiver.

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. RTP over QUIC 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. 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 rate adaptation algorithm can be plugged in to adapt the media bitrate to the available bandwidth. This document does not mandate any specific rate adaptation algorithm. Some examples include Network-Assisted Dynamic Adaptation (NADA) and Self-Clocked Rate Adaptation for Multimedia (SCReAM) . 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.

Supported RTP Topologies RTP over QUIC only supports some of the RTP topologies described in . Most notably, due to QUIC being a purely unicast protocol at the time of writing, RTP over QUIC cannot be used as a transport protocol in any of the multicast topologies (e.g., Topo-ASM, Topo-SSM, Topo-SSM-RAMS). 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. Using RTP over QUIC streams (see ) 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 RTP over QUIC to RTP over a different transport protocol. A similar problem can occur if a translator needs to translate from RTP over UDP to RTP over QUIC 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.

Connection Establishment and ALPN QUIC requires the use of ALPN tokens during connection setup. RTP over QUIC uses "rtp-mux-quic" as ALPN token in the TLS handshake (see also . 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 . 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 RTP over QUIC as specified in this document over WebTransport.

Draft version identification

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

RTP over QUIC 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.

Encapsulation This section describes the encapsulation of RTP/RTCP packets in QUIC. QUIC supports two transport methods: streams and datagrams . 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. introduces a multiplexing mechanism that supports multiplexing RTP, RTCP, and, with some constraints, other non-RTP protocols. and explain the specifics of mapping RTP to QUIC streams and QUIC datagrams, respectively.

Multiplexing RTP over QUIC 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 . 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 , 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 . 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 , 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 stream, it MAY drop the data stream. 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.

QUIC Streams To send RTP/RTCP packets over QUIC streams, a sender MUST open a new unidirectional QUIC stream. Streams are unidirectional because there is no synchronous relationship between sent and received RTP/RTCP packets. A sender MAY open new QUIC streams for different packets using the same flow identifier, for example, to avoid head-of-line blocking. shows the encapsulation format for RTP over QUIC Streams.

RTP over QUIC 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

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 .

RTP/RTCP payload for QUIC streams

Length:

A QUIC variable length integer describing the length of the following RTP/RTCP packets in bytes.

RTP/RTCP Packet:

The RTP/RTCP packet to transmit.

If a sender knows that a packet, which was not yet successfully and completely transmitted, is no longer needed, the sender MAY close the stream by sending a RESET_STREAM frame. 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.

• Editor's Note: It might be desired to also allow the receiver to request cancellation of a stream by sending STOP_SENDING frame. However, this might lead to unintended packet loss because the receiver does not know which and how many packets follow on the same stream. If this feature is required, a solution could be to require senders to open new streams for each application data unit, as described in a previous version of this document.

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. 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 with enough credit to open new streams for new packets at any time.

QUIC Datagrams Senders can also transmit RTP packets in QUIC datagrams. QUIC datagrams are an extension to QUIC described in . 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. shows the encapsulation format for RTP over QUIC Datagrams.

RTP over QUIC 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.

Since QUIC datagrams are not retransmitted on loss (see also 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 and the flow identifier MUST be set to the flow identifier of the RTP session in which the retransmission happens.

RTCP The RTP Control Protocol (RTCP) allows RTP senders and receivers to exchange control information to monitor connection statistics and to identify and synchronize streams. Many of the statistics contained in RTCP packets overlap with the connection statistics collected by a QUIC connection. To avoid using up bandwidth for duplicated control information, the information SHOULD only be sent at one protocol layer. QUIC relies on certain control frames to be sent. In general, applications MAY send RTCP without any restrictions. This document specifies a baseline for replacing some of the RTCP packet types by mapping the contents to QUIC connection statistics. Future documents can extend this mapping for other RTCP format types. It is RECOMMENDED to expose relevant information from the QUIC layer to the application instead of exchanging additional RTCP packets, where applicable. This section discusses what information can be exposed from the QUIC connection layer to reduce the RTCP overhead and which type of RTCP messages cannot be replaced by similar feedback from the transport layer. 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.

Transport Layer Feedback This section explains how some of the RTCP packet types which 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. 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. For RTP packets that are sent over QUIC streams, an RTP packet can be considered acknowledged, when all frames which 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. Some of the transport layer feedback that can be implemented in RTCP contains information that is not included in QUIC by default, but can be added via QUIC extensions. One important example are arrival timestamps, which are not part of QUIC's default acknowledgment frames, but can be added using or . Another extension, that can improve the precision of the feedback from QUIC is , which allows a sender to control the delay of acknowledgments sent by the receiver. The list of RTCP Receiver Reports that could be replaced by feedback from QUIC follows:

• Receiver Reports (PT=201, Name=RR, )
  • 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 one of the extensions referenced above, senders can infer from QUIC acks the interarrival jitter from the arrival timestamps.
  • Last SR: Similar to RTP arrival times, the arrival time of RTCP Sender Reports can be inferred from QUIC acknowledgments, if they include timestamps.
  • Delay since last SR: This field is not required when the receiver reports are entirely replaced by QUIC feedback.
• Negative Acknowledgments (PT=205, FMT=1, Name=Generic NACK, )
  • The generic negative acknowledgment packet contains information about packets which the receiver considered lost. recommends to use 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 .
• ECN Feedback (PT=205, FMT=8, Name=RTCP-ECN-FB, )
  • ECN feedback packets report the count of observed ECN-CE marks. 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 below. QUIC supports ECN reporting through acknowledgments. If the connection supports ECN, the reporting of ECN counts SHOULD be done using QUIC acknowledgments, rather than RTCP ECN feedback reports.
• Congestion Control Feedback (PT=205, FMT=11, Name=CCFB, )
  • RTP Congestion Control Feedback 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 or .
• Extended Reports (PT=207, Name=XR, )
  • Extended Reports offer an extensible framework for a variety of different control messages. Some of the standard report blocks which can be implemented in extended reports such as loss RLE or ECNs can be implemented in QUIC, too. For other report blocks, it SHOULD be evaluated individually, if the contained information can be transmitted using QUIC instead.

Application Layer Repair and other Control Messages While the previous section presented some RTCP packet that can be replaced by QUIC features, QUIC cannot replace all of the available RTCP packet types. This mostly affects RTCP packet types which carry control information that is to be interpreted by the application layer instead of the transport itself. Sender Reports (PT=200, Name=SR, ) are similar to Receiver Reports. They are sent by media senders and additionally contain a NTP and a 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 a similar control information, since it does not know about RTP timestamps. Nor can a QUIC receiver calculate the packet or octet counts, since it does not know about lost datagrams. Thus, sender reports are required in RTP over QUIC to synchronize streams at the receiver. The sender reports SHOULD not contain any receiver report blocks, as the information can be inferred from the QUIC transport as explained in the previous section. Next to carrying transmission statistics, RTCP packets can contain application layer control information, that cannot directly be mapped to QUIC. This includes for example the Source Description (PT=202, Name=SDES), Bye (PT=203, Name=BYE) and Application (PT=204, Name=APP) packet types from or many of the payload specific feedback messages (PT=206) defined in , which can for example be used to control the codec behavior of the sender. Since QUIC does not provide any kind of application layer control messaging, these RTCP packet types SHOULD be used in the same way as they would be used over any other transport protocol.

Congestion Control and Rate Adaptation Like any other application on the internet, RTP over QUIC needs to perform congestion control to avoid overloading the network. 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 is similar to TCP NewReno , but senders are free to choose any congestion control algorithm as long as they follow the guidelines specified in . RTP itself does not specify a congestion control algorithm, but defines an RTCP feedback message intended to enable rate adaptation for interactive real-time traffic using RTP, and successful rate adaptation will accomoplish congestion control as well. Various rate adaptation algorithms for real-time media are defined in separate RFCs (e.g. SCReAM and NADA ). The rate adaptation algorithms for RTP are specifically tailored for real-time transmissions at low latencies. The available rate adaptation algorithms for RTP expose a target_bitrate that can be used to dynamically reconfigure media codecs to produce media at a rate that can be sent in real-time under the observed network conditions. This section defines two architectures for congestion control and bandwidth estimation for RTP over QUIC, but it does not mandate any specific rate adaptation algorithm to use. The section also discusses congestion control implications of using shared or multiple separate QUIC connections to send and receive multiple independent data streams. It is assumed that the congestion controller in use provides a pacing mechanism to determine when a packet can be sent to avoid bursts. The currently proposed congestion control algorithms for real-time communications provide such pacing mechanisms. The use of congestion controllers which don't provide a pacing mechanism is out of scope of this document.

Congestion Control at the QUIC layer If congestion control is to be applied at the transport layer, it is RECOMMENDED that the QUIC Implementation uses a congestion controller that keeps queueing delays short to keep the transmission latency for RTP and RTCP packets as low as possible. Many low latency congestion control algorithms depend on detailed arrival time feedback to estimate the current one-way delay between sender and receiver. QUIC does not provide arrival timestamps in its acknowledgments. The QUIC implementations of the sender and receiver can use an extension to add this information to QUICs acknowledgment frames, e.g. or . If congestion control is done by the QUIC implementation, the application needs a mechanism to query the currently available bandwidth to adapt media codec configurations. The employed congestion controller of the QUIC connection SHOULD expose such an API to the application. If a current bandwidth estimate is not available from the QUIC congestion controller, the sender can either implement an alternative bandwidth estimation at the application layer as described in or a receiver can feedback the observed bandwidth through RTCP, e.g., using .

Congestion Control at the Application Layer If an application cannot access a bandwidth estimation from the QUIC layer, or the QUIC implementation does not support a delay-based, low-latency congestion control algorithm, the application can alternatively implement a bandwidth estimation algorithm at the application layer. Calculating a bandwidth estimation at the application layer can be done using the same bandwidth estimation algorithms as described in (NADA, SCReAM). The bandwidth estimation algorithm typically needs some feedback on the transmission performance. This feedback can be collected following the guidelines in . If the application implements full congestion control rather than just a bandwidth estimation at the application layer using a congestion controller that satisfies the requirements of , and the connection is only used to send real-time media which is subject to the application layer congestion control, it is RECOMMENDED to disable any other congestion control that is possibly running at the QUIC layer. Disabling the additional congestion controllers helps to avoid any interference between the different congestion controllers.

Shared QUIC connections Two endpoints may want to establish channels 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. A straightforward solution is to establish multiple QUIC connections, one for each channel. Or 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. Alternatively, (all or a subset of) real-time and non-real-time channels are multiplexed onto a single, shared QUIC connection, which can be done by using the flow identifier described in . Applications multiplexing multiple streams in one connection SHOULD implement some form of stream prioritization or bandwidth allocation.

API Considerations The mapping described in the previous sections poses some interface requirements on the QUIC implementation. Although a basic mapping should work without any of these requirements most of the optimizations regarding rate adaptation and RTCP mapping require certain functionalities to be exposed to the application. The following to sections contain a list of information that is required by an application to implement different optimizations () and functions that a QUIC implementation SHOULD expose to an application (). Each item in the following list can be considered individually. Any exposed information or function can be used by RTP over QUIC regardless of whether the other items are available. Thus, RTP over QUIC 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.

Information to be exported from QUIC This section provides a list of items that an application might want to export from an underlying QUIC implementation. It is thus RECOMMENDED that a QUIC implementation exports the listed items to the application.

• Maximum Datagram Size: The maximum datagram size that the QUIC connection can transmit.
• Datagram Acknowledgment and Loss: allows QUIC implementations to notify the application that a QUIC Datagram was acknowledged or that it believes a datagram was lost. The exposed information SHOULD include enough information to allow the application to maintain a mapping between the datagram that was acknowledged/lost and the RTP packet that was sent in that datagram.
• Stream States: The QUIC implementation SHOULD expose to a sender, how much of the data that was sent on a stream was successfully delivered and how much data is still outstanding to be sent or retransmitted.
• Arrival timestamps: If the QUIC connection uses a timestamp extension like or , the arrival timestamps or one-way delays SHOULD be exposed to the application.
• Bandwidth Estimation: If congestion control is done at the transport layer in the QUIC implementation, the QUIC implementation SHOULD expose an estimation of the currently available bandwidth to the application. Exposing the bandwidth estimation avoids the implementation of an additional bandwidth estimation algorithm in the application.
• ECN: If ECN marks are available, they SHOULD be exposed to the application.

Functions to be exposed by QUIC This sections lists functions that a QUIC implementation SHOULD expose to an application to implement different features of the mapping described in the previous sections of this document.

• Cancel Streams: To allow an application to cancel (re)transmission of packets that are no longer needed, the QUIC implementation MUST expose a way to cancel the corresponding QUIC streams.
• Configure Congestion Controller: If congestion control is to be implemented at the QUIC connection layer as described in , the QUIC implementation SHOULD expose an API to allow the application to configure the specifics of the congestion controller.
• Disable Congestion Controller: If congestion control is to be implemented at the application layer as described in , and the application layer is trusted to apply adequate congestion control as described in and , it is RECOMMENDED to allow the application to disable QUIC layer congestion control entirely.

Discussion

Flow Identifier suggests to use flow identifiers to multiplex different streams on QUIC Datagrams, which is implemented in , but it is unclear how applications can combine RTP over QUIC with other data streams using the same QUIC connections. If the non-RTP data streams use the same flow identifies, too and the application can make sure, that flow identifiers are unique, there should be no problem. Flow identifiers could be problematic, if different specifications for RTP and non-RTP data streams over QUIC mandate different incompatible flow identifiers.

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.

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 RTP over QUIC 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.

Security Considerations RTP over QUIC is subject to the security considerations of RTP described in and the security considerations of any RTP profile in use. The security considerations for the QUIC protocol and datagram extension described in , , and also apply to RTP over QUIC.

IANA Considerations

Registration of a RTP over QUIC Identification String This document creates a new registration for the identification of RTP over QUIC in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry . The "rtp-mux-quic" string identifies RTP over QUIC:

Protocol:

RTP over QUIC

Identification Sequence:

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

Specification:

This document

References Normative References 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 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 defines the properties of the QUIC transport protocol that are common to all versions of the protocol. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes loss detection and congestion control mechanisms for QUIC. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK] 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 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 document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK] Magic Leap, Inc. Google LLC This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps using a new ACK_RECEIVE_TIMESTAMPS frame type. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/wcsmith/draft-quic-receive-ts. Private Octopus Inc. The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame. Fastly Google This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. 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] 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 defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. 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. Informative References This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] Tencent America LLC This document describes these new SDP "proto" attribute values: "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications such as SIP and WebRTC that commonly use SDP as a session signaling protocol to set up RTP connections. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). Millicast CoSMo Software This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. Google LLC Cloudflare This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP specifications (RFCs 3550 and 3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. 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] RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK] Google This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. It also describes an absolute-value timestamp option for use in bandwidth estimatoin. QUIC is a UDP-based transport protocol for stream-orientated, congestion-controlled, secure, multiplexed data transfer. RTP carries real-time data between endpoints, and the accompanying control protocol RTCP allows monitoring and control of the transfer of such data. With RTP and RTCP being agnostic to the underlying transport protocol, it is possible to multiplex both the RTP and associated RTCP flows into a single QUIC connection to take advantage of QUIC features such as low-latency setup and strong TLS-based security.

Experimental Results An experimental implementation of the mapping described in this document can be found on Github. The application implements the RTP over QUIC 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 . Experimental results of the implementation can be found on Github, too.

Acknowledgments Early versions of this document were similar in spirit to , 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 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.