]> Nederlandse Publieke Omroep

Netherlands james.ietf@gmail.com

Tencent America LLC

United States of America spencerdawkins.ietf@gmail.com

applications MOQ Mailing List Internet-Draft QUIC This document describes use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further exploration, and describes considerations that should guide the design of protocols to satisfy these use cases. Note to Readers RFC Editor: please remove this section before publication Source code and issues for this draft can be found at https://github.com/fiestajetsam/draft-gruessing-moq-requirements. Discussion of this draft should take place on the IETF Media Over QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq.

Introduction This document describes use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further exploration, and describes considerations that should guide the design of protocols to satisfy these use cases.

For The Impatient Reader

• Our proposal is to focus on live media use cases, as described in , rather than on interactive media use cases or on-demand use cases.
• The reasoning behind this proposal can be found in .
• The considerations for protocol work to satisfy the proposed use cases can be found in .

Most of the rest of this document provides background for these sections.

Why QUIC For Media? It is not the purpose of this document to argue against proposals for work on media applications that do not involve QUIC. Such proposals are simply out of scope for this document. When work on the QUIC protocol () was chartered (), the key goals for QUIC were:

• Minimizing connection establishment and overall transport latency for applications, starting with HTTP,
• Providing multiplexing without head-of-line blocking,
• Requiring only changes to path endpoints to enable deployment,
• Enabling multipath and forward error correction extensions, and
• Providing always-secure transport, using TLS 1.3 by default.

These goals were chosen with HTTP () in mind. While work on "QUIC version 1" (version codepoint 0x00000001) was underway, protocol designers considered potential advantages of the QUIC protocol for other applications. In addition to the key goals for HTTP applications, these advantages were immediately apparent for at least some media applications:

• QUIC endpoints can create bidirectional or unidirectional ordered byte streams.
• QUIC will automatically handle congestion control, packet loss, and reordering for stream data.
• QUIC streams allow multiple media streams to share congestion and flow control without otherwise blocking each other.
• QUIC streams also allow partial reliability, since either the sender or receiver can terminate the stream early without affecting the overall connection.
• With the DATAGRAM extension (), further partially reliable models are possible, and applications can send congestion controlled datagrams below the MTU size.
• QUIC connections are established using an ALPN.
• QUIC endpoints can choose and change their connection ID.
• QUIC endpoints can migrate IP address without breaking the connection.
• Because QUIC is encapsulated in UDP, QUIC implementations can run in user space, rather than in kernel space, as TCP typically does. This allows more room for extensible APIs between application and transport, allowing more rapid implementation and deployment of new congestion control, retransmission, and prioritization mechanisms.
• QUIC is supported in browsers via HTTP/3 or WebTransport.
• With WebTransport, it is possible to write libraries or applications in JavaScript.

The specific advantages of interest may vary from use case to use case, but these advantages justify further investigation of "Media Over QUIC".

Terminology

The Many Meanings of "Media Over QUIC" Protocol developers have been considering the implications of the QUIC protocol () for media transport for several years, resulting in a large number of possible meanings of the term "Media Over QUIC", or "MOQ". As of this writing, "Media Over QUIC" has had at least these meanings:

• any kind of media carried directly over the QUIC protocol, as a QUIC payload
• any kind of media carried indirectly over the QUIC protocol, as an RTP payload ()
• any kind of media carried indirectly over the QUIC protocol, as an HTTP/3 payload
• any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload
• the encapsulation of any Media Transport Protocol () in a QUIC payload
• an IETF mailing list (), which was requested "... for discussion of video ingest and distribution protocols that use QUIC as the underlying transport", although discussion of other Media Over QUIC proposals have also been discussed there.

There may be IETF participants using other meanings as well. As of this writing, the second bullet ("any kind of media carried indirectly over the QUIC protocol, as an RTP payload"), seems to be in scope for the IETF AVTCORE working group, and was discussed at some length at the February 2022 AVTCORE working group meeting , although no drafts in this space have yet been adopted by the AVTCORE working group.

Media Transport Protoccol This document describes considerations for work on extensions to existing "Media Transport Protocols" or creation of new "Media Transport Protocols". Within this document, we use the term "Media Transport Protocol" to describe the protocol of interest. This is easier to understand if the reader assumes that we are talking about a protocol stack that looks something like this: where "Media Format" would be something like RTP payload formats or ISOBMFF , and "Media Transport Protocol" would be something like RTP or HTTP. Not all possible proposals for "Media Over QUIC" follow this model, but for the ones that do, it seems useful to have names for "the protocol layers beteern Media and QUIC". It is worth noting explicitly that the "Media Transport Protocol" layer might include more than one protocol. For example, a new Media Transport Protocol might be defined to run over HTTP, or even over WebTransport and HTTP.

Latency Requirement Categories Within this document, we extend the latency requirement categories for streaming media described in :

• ultra low-latency (less than 1 second)
• low-latency live (less than 10 seconds)
• non-low-latency live (10 seconds to a few minutes)
• on-demand (hours or more)

These latency bands were appropriate for streaming media, which was the target for , but some interactive media may have requirements that are significantly less than "ultra-low latency". Within this document, we are also using

• Ull-50 (less than 50 ms)
• Ull-200 (less than 200 ms)

Perhaps obviously, these last two latency bands are the shortened form of "ultra-low latency - 50 ms" and "ultra-low-latency - 200 ms". Perhaps less obviously, bikeshedding on better names and more useful values is welcomed.

Prior and Existing Specifications Several draft specifications have been proposed which either encapsulate existing Media Transport Protocols in QUIC, or define their own new Media Transport Protocol on top of QUIC. With the exception of RUSH (), it is unknown if the other specifications listed in this section have had any deployments or interop with multiple implementations.

QRT: QUIC RTP Tunnelling QRT encapsulates RTP and RTCP and define the means of using QUIC datagrams with them, defining a new payload within a datagram frame which distinguishes packets for a RTP packet flow vs RTCP.

RTP over QUIC This specification also encapsulates RTP and RTCP but unlike QRT which simply relies on the default QUIC congestion control mechanisms, it defines a set of requirements around QUIC implementation's congestion controller to permit the use of separate control algorithms.

RUSH - Reliable (unreliable) streaming protocol Whilst RUSH predates the datagram specification, it uses its own frame types on top of QUIC to take advantage of QUIC implementations reassembling messages greater than MTU. In addition individual media frames are given their own stream identifiers to remove HoL blocking from processing out-of-order. It defines its own registry for signalling codec information with room for future expansion but presently is limited to a subset of popular video and audio codecs and doesn't include other types (such as subtitles, transcriptions, or other signalling information) out of bitstream.

Tunnelling SRT over QUIC Secure Reliable Transport (SRT) () itself is a general purpose transport protocol primarily for ingest transport use cases and this specification covers the encapsulation and delivery of SRT on top of QUIC using datagram frame types. This specification sets some requirements regarding how the two interact and leaves considerations for congestion control and pacing to prevent conflict between the two protocols. Apart from that, SRT provides a native suport for stream multiplexing, thus contributing this missing functionality to QUIC datagrams.

Warp - Segmented Live Video Transport Warp's specification attemps to map Group of Picture encoding of video on top of QUIC streams. It depends on ISOBMFF containers to encapsulate both media as well as messaging, and defines prioritisation with separate considerations for audio and video. It doesn't yet define bi-directionality of media flows, and can be run over protocols like WebTransport .

Comparison of Existing Specifications ** Additional details for this comparison could usefully be added here. **

• Some drafts attempt to use existing payloads of RTP, RTCP, and SDP, while others do not.
• Some use QUIC Datagram frames, while others use QUIC streams.
• All drafts take differing approaches to flow/stream identification and management. Some address congestion control and others just defer this to QUIC to handle.
• Some drafts specify ALPN identification, while others do not.

Use Cases Informing This Proposal Our goal in this section is to understand the range of use cases that have been proposed for "Media Over QUIC". Although some of the use cases described in this section came out of "RTP over QUIC" proposals, they are worth considering in the broader "Media Over QUIC" context, and may be especially relevant to MOQ, depending on whether "RTP over QUIC" requires major changes to RTP and RTCP, in order to meet the requirements arising out of the corresponding use cases. An early draft in the "media over QUIC" space, , defined several key use cases. Some of the following use cases have been inspired by that document, and others have come from discussions with the wider MOQ community (among other places, a side meeting at IETF 112). For each use case in this section, we also define

• the number of senders or receiver in a given session transmitting distinct streams,
• whether a session has bi-direction flows of media from senders and receivers, and
• the expected lowest latency requirements using the definitions specified in .

It is likely that we should add other characteristics, as we come to understand them.

Interactive Media The use cases described in this section have one particular attribute in common - the target latency for these cases are on the order of one or two RTTs. In order to meet those targets, it is not possible to rely on protocol mechanisms that require multiple RTTs to function effectively. For example,

• When the target latency is on the order of one RTT, it makes sense to use FEC and codec-level packet loss concealment , rather than selectively retransmitting only lost packets. These mechanisms use more bytes, but do not require multiple RTTs in order to recover from packet loss.
• When the target latency is on the order of one RTT, it is impossible to use congestion control schemes like BBR , since BBR has probing mechanisms that rely on temporarily inducing delay and amortizing the consequences of that over multiple RTTs.

This may help to explain why these use cases often rely on protocols such as RTP , which provide low-level control of packetization and transmission.

Gaming

Attribute	Value
Senders/Receivers	One to One
Bi-directional	Yes
Latency	Ull-50

Where media is received, and user inputs are sent by the client. This may also include the client receiving other types of signalling, such as triggers for haptic feedback. This may also carry media from the client such as microphone audio for in-game chat with other players.

Remote Desktop

Attribute	Value
Senders/Receivers	One to One
Bi-directional	Yes
Latency	Ull-50

Where media is received, and user inputs are sent by the client. Latency requirements with this usecase are marginally different than the gaming use case. This may also include signalling and/or transmitting of files or devices connected to the user's computer.

Video Conferencing/Telephony

Attribute	Value
Senders/Receivers	Many to Many
Bi-directional	Yes
Latency	Ull-50 to Ull-200

Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation. This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers. The target for latency may be as large as Ull-200 for some media types such as audio, but other media types in this use case have much more stringent latency targets.

Live Media The use cases in this section, unlike the use cases described in , still have "humans in the loop", but these humans expect media to be "responsive", where the responsiveness is more on the order of 5 to 10 RTTs. This allows the use of protocol mechanisms that require more than one or two RTTs - as noted in , end-to-end recovery from packet loss and congestion avoidance are two such protocol mechanisms that can be used with Live Media. To illustrate the difference, the responsiveness expected with videoconferencing is much greater than watching a video, even if the video is being produced "live" and sent to a platform for syndication and distribution.

Live Media Ingest

Attribute	Value
Senders/Receivers	One to One
Bi-directional	No
Latency	Ull-200 to Ultra-Low

Where media is received from a source for onwards handling into a distribution platform. The media may comprise of multiple audio and/or video sources. Bitrates may either be static or set dynamically by signalling of connection inforation (bandwidth, latency) based on data sent by the receiver.

Live Media Syndication

Attribute	Value
Senders/Receivers	One to One
Bi-directional	No
Latency	Ull-200 to Ultra-Low

Where media is sent onwards to another platform for further distribution. The media may be compressed down to a bitrate lower than source, but larger than final distribution output. Streams may be redundant with failover mechanisms in place.

Live Media Streaming

Attribute	Value
Senders/Receivers	One to Many
Bi-directional	No
Latency	Ull-200 to Ultra-Low

Where media is received from a live broadcast or stream. This may comprise of multiple audio or video outputs with different codecs or bitrates. This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate change of behaviour in client such as advertisement breaks). The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past.

On-Demand Media Finally, the "On-Demand" use cases described in this section do not have a tight linkage between ingest and streaming, allowing significant transcoding, processing, insertion of video clips in a news article, etc. The latency constraints for the use cases in this section may be dominated by the time required for whatever actions are required before media are available for streaming.

On-Demand Ingest

Attribute	Value
Senders/Receivers	One to Many
Bi-directional	No
Latency	On Demand

Where media is ingested and processed for a system to later serve it to clients as on-demand media. This media provided from a pre-recorded source, or captured from live output, but in either case, this media is not immediately passed to viewers, but is stored for "on-demand" retrieval, and may be transcoded upon ingest.

On-Demand Media Streaming

Attribute	Value
Senders/Receivers	One to Many
Bi-directional	No
Latency	On Demand

Where media is received from a non-live, typically pre-recorded source. This may feature additional outputs, bitrates, codecs, and media types described in the live media streaming use case.

Proposed Scope for "Media Over QUIC" Our proposal is that "Media Over QUIC" discussions focus first on the use cases described in , which are Live Media Ingest (), Syndication (), and Streaming (). Our reasoning for this suggestion follows. Each of the above use cases in fit into one of three classifications of solutions.

Analysis for Interactive Use Cases The first group, Interactive Media, as described in , and covering gaming (), screen sharing (), and general video conferencing (), are largely covered by RTP, often in conjunction with WebRTC , and related protocols today. Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the RTP protocols and specifications.

Analysis for Live Media Use Cases The second group of classifications, in , covering Live Media Ingest (), Live Media Syndication (), and Live Media Streaming () are likely the use cases that will benefit most from this work. Existing ingest and streaming protocols such as HLS and DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used, these protocols add a significant amount of overhead compared to the media bitstream itself. For this reason, we suggest that work on "Media Over QUIC" protocols target these use cases at this time.

Analysis for On-Demand Use Cases The third group, , covering On-Demand Media Ingest () and On-Demand Media streaming () is unlikely to benefit from work in this space. Without the same "Live Media" latency requirements that would motivate deployment of new protocols, existing protocols such as HLS and DASH are probably "good enough" to meet the needs of these use cases. This does not mean that existing protocols in this space are perfect. Segmented protocols such as HLS and DASH were developed to overcome the deficiencies of TCP, as used in HTTP/1.1 and HTTP/2 , and do not make full use of the possible congestion window along the path from sender to receiver. Other protocols in this space have their own deficiencies. For example, RTSP does not have easy ways to add support for new media codecs. Our expectation is that these use cases will not drive work in the "Media Over QUIC" space, but as new protocols come into being, they may very well be taken up for these use cases as well.

Considerations for Protocol Work Even a cursory examination of the existing proposals listed in shows that there are fundamental differences in the approaches being used. This sction is intended to "up-level" the conversation beyond specific protocols, so that we can more likely agree on what is important for protocol design work. Please note that the considerations in this section are focused especially on the use cases described in , although other use cases are mentioned for comparison and contrast.

Here Be Dragons The discussion in is less mature than in most other sections of this document. The good news is that this section is fertile ground for people who would like to contribute to future revisions of this document. Comments are even more welcome for this section than for the rest of the document, for which they are welcome. The authors suggest that high-level comments are most appropriate at this time.

Codec Agility When initiating a media session, both the sender and receiver will need to agree on the codecs, bitrates, resolution, and other media details based on capabilities and preferences. This agreement needs to take place before commencing media transmission, but might also take place during media transmission, perhaps as a result of changes to device output or network conditions (such as reduction in available network bandwidth). It may be prefered to use existing ecosystem for such purposes, e.g. SDP .

Support an Appropriate Range of Latencies Support for a nominal latency appropriate for the use cases that are in scope should be achievable, with consideration for the minimum buffer that a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality.

Migration of Sessions Handling of migration of a session between hosts, either of sender or receiver should be supported. This may either happen because the sender is undergoing maintenence or a rebalancing of resource, because the either is experiencing a change in network connectivity (such as a device moving from WiFi to cellular connectivity) or other reasons. This may depend on QUIC capabilities such as but support for full QUIC operation over multiple paths between senders and receivers is by no means essential.

Appropriate Congestion Control An appropriate congestion control mechanism will depend upon the use cases under consideration. It's worth remembering that we have more experience with QUIC carrying HTTP traffic than with any other type of application at this time, and consequently, we have more experience with congestion control mechanisms such as NewReno , Cubic , and BBR being used with QUIC than with any other congestion control mechanisms. These congestion control mechanisms may also be appropriate for the on-demand use cases described in . Conversely, for the interactive use cases described in , these congestion control mechanisms are very likely inappropriate, especially when QUIC is being used with a Media Transport Protocol such as RTP, which provides its own congestion control mechanism, and which does not seem to interact well with a second, QUIC-level congestion control mechanism. Congestion control mechanisms such as SCReAM or NADA may be more appropriate for media. "Congestion Control Requirements for Interactive Real-Time Media" is a useful reference. Awkwardly, the live media use cases described in live somewhere in the middle, and work will be needed to understand the characteristics of an appropriate congestion control mechanism for these use cases.

Support Lossless and Lossy Media Transport TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport.

Flow Directionality Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently but should only be negotiated at the start of the session.

WebTransport TODO: Unsure of the importance of this consideration for live media use cases. If this is critical, we have to consider two things:

• WebTransport supports HTTP/2, are we going to explicitly exclude it?
• Also, WebTransport has normative language around congestion control, which may be at odds with the considerations described in .

Authentication In order to allow hosts to authenticate one another, capabilities beyond what QUIC provides may be necessary. This should be kept simple but robust in nature to prevent attacks like credential brute-forcing. TODO: More details are required here

Considerations Implying QUIC Extensions Most of the discussion of protocol work in this document has avoided mentioning capabilities that may be useful for some use cases, but seem to imply the need for extensions to the QUIC protocol, beyond what is already being considered in the IETF QUIC working group. These are included in this section, for completeness' sake.

NAT Traversal From Section 8.2 of :

• Path validation is not designed as a NAT traversal mechanism. Though the mechanism described here might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one endpoint is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.

Although there are use cases that would benefit from a mechanism for NAT traversal, a QUIC protocol extention would be needed to support those use cases.

Multicast Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet support multicast, and a QUIC protocol extension would be needed to do so. In addition, the inclusion of multicast would introduce more complexity in both the specification and client implimentations. On the other hand, UDP multicast may be considered as the last mile delivery transport outside of QUIC transport, thus it would be beneficial for a protocol to provide such an opportunity (e.g. RTP/QUIC -> RTP/UDP).

IANA Considerations This document makes no requests of IANA.

Security Considerations As this document is intended to guide discussion and consensus, it introduces no security considerations of its own.

Informative 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 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. [STANDARDS-TRACK] This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK] This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. 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 a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol. 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. CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC. Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique. 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 loss detection and congestion control mechanisms for QUIC. 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. Google Google Google Google Google This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC793] and QUIC [RFC9000]. This document specifies version 2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2. Technical University Munich Technical University Munich 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 This note is to be removed before publishing as an RFC. 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 https://github.com/mengelbart/rtp-over-quic-draft. 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. Facebook Facebook Facebook Facebook RUSH is an application-level protocol for ingesting live video. This document describes core of the protocol and how it maps onto QUIC Discussion Venues This note is to be removed before publishing as an RFC. 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 https://github.com/afrind/draft-rush. Twitch This document defines the core behavior for Warp, a segmented live video transport protocol. Warp maps live media to QUIC streams based on the underlying media encoding. Media is prioritized to minimize latency during congestion. Technische Universitaet Muenchen Huawei University of Glasgow CALLSTATS I/O Oy QUIC is a UDP-based protocol for congestion controlled reliable data transfer, while RTP serves carrying (conversational) real-time media over UDP. This draft discusses design aspects and issues of carrying RTP over QUIC. Haivision Network Video Haivision Network Video Haivision Systems SK Telecom Co., Ltd. SK Telecom Co., Ltd. This document specifies Secure Reliable Transport (SRT) protocol. SRT is a user-level protocol over User Datagram Protocol and provides reliability and security optimized for low latency live video streaming, as well as generic bulk data transfer. For this, SRT introduces control packet extension, improved flow control, enhanced congestion control and a mechanism for data encryption. Haivision Network Video GmbH Haivision Network Video GmbH This document presents an approach to tunnelling SRT live streams over QUIC datagrams. QUIC [RFC9000] is a UDP-based transport protocol providing TLS encryption, stream multiplexing, and connection migration. It was designed to become a faster alternative to the TCP protocol [RFC7323]. An Unreliable Datagram Extension to QUIC [QUIC-DATAGRAM] adds support for sending and receiving unreliable datagrams over a QUIC connection, but transfers the responsibility for multiplexing different kinds of datagrams, or flows of datagrams, to an application protocol. SRT [SRTRFC] is a UDP-based transport protocol. Essentially, it can operate over any unreliable datagram transport. SRT provides loss recovery and stream multiplexing mechanisms. In its live streaming configuration SRT provides an end-to-end latency-aware mechanism for packet loss recovery. If SRT fails to recover a packet loss within a specified latency, then the packet is dropped to avoid blocking playback of further packets. The Datagram Extension to QUIC could be used as an underlying transport instead of UDP. This way QUIC would provide TLS-level security, connection migration, and potentially multi-path support. It would be easier for existing network facilities to process, route, and load balance the unified QUIC traffic. SRT on its side would provide end-to-end latency tracking and latency-aware loss recovery. Akamai Technologies, Inc. Networked Media Tencent America LLC This document provides an overview of operational networking issues that pertain to quality of experience when streaming video and other high-bitrate media over the Internet. Apple Inc. Apple Inc. Google LLC This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. 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 (mailto: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/quicwg/datagram. Akamai The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. 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. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http. Alibaba Inc. Alibaba Inc. UCLouvain UCLouvain Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. 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/mirjak/draft-lmbdhk-quic-multipath. Google The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. n.d. n.d. n.d.

Acknowledgements The authors would like to thank the many authors of the specifications referenced in for their work:

• Alan Frindell
• Colin Perkins
• Jake Weissman
• Joerg Ott
• Jordi Cenzano
• Kirill Pugin
• Maria Sharabayko
• Mathis Engelbart
• Maxim Sharabayko
• Roni Even
• Sam Hurst
• Varun Singh

The authors would like to thank Alan Frindell, Luke Curley, and Maxim Sharabayko for text contributions to this draft. James Gruessing would also like to thank Francesco Illy and Nicholas Book for their part in providing the needed motivation.