| Internet-Draft | MoQ Requirements and Use Cases | October 2021 |
| Gruessing & Dawkins | Expires 28 April 2022 | [Page] |
This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a real-time media transport protocol as a payload in the QUIC protocol.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 April 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a real-time media transport protocol as a payload in the the QUIC protocol [RFC9000].¶
Protocol developers have been considering the implications of the QUIC protocol ([RFC9000]) on media transport for several years, but the initial focus on QUIC in the IETF was to support web applications that used the HTTP/3 protocol [I-D.draft-ietf-quic-http]. The completion of the initial versions of the QUIC specifications, and the adoption of [I-D.draft-ietf-quic-datagram], have cleared the way for proposals to use QUIC as a media transport. This document considers a number of proposals for "Media Over QUIC", and analyzes them to understand requirements and considerations.¶
For the purposes of this document, it is assumed that we are starting with a protocol stack that looks like this:¶
Media Transport Protocol | Media
¶
and the goal is to provide a protocol stack that looks like this:¶
QUIC | Media Transport Protocol | Media
¶
Several existing draft specifications and protocols already exist which base their implementation around using existing Media Transport Protocols on top of QUIC, or define their own. With the exception of RUSH (Section 3.3), it is unknown if the other specifications have had any deployments or interop with multiple implementations.¶
[I-D.draft-hurst-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.¶
[I-D.draft-engelbart-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 uses its own frame types on top of QUIC as it pre-dates the datagram specification; 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.¶
An early draft in the "media over QUIC" space, [I-D.draft-rtpfolks-quic-rtp-over-quic], defined several key use cases. The following sections are taken from that draft, with minimal editing.¶
Interactive peer-to-peer applications, such as telephony or video conferencing. Such applications operate in a trapezoid topology using a client-server signalling channel running SIP or WebRTC, and an associated peer-to-peer media path and/or data channel. Mappings of SIP and WebRTC onto QUIC are possible, but outside the scope of this memo. It might be desirable to transport the peer-to-peer RTP media path and data channel using QUIC, to leverage QUIC's security, stream demultiplexing, and congestion control features running over a single UDP port. This would simplify media demultiplexing, and potentially obviate the need for the congestion control work being done in the RMCAT working group. The design of QUIC makes it difficult however, since QUIC does not support peer-to-peer NAT traversal using STUN and ICE (and indeed uses a packet format that conflicts with STUN). These applications require low latency congestion control, and would benefit from unreliable delivery modes.¶
Interactive client-server applications. For example, a "click here to speak to a representative" button on a website that starts an interactive WebRTC call. Such applications avoid the NAT traversal issues that complicate peer-to-peer use of QUIC, and can benefit from stream demultiplexing and (if appropriate algorithms are provided) congestion control. They would benefit from unreliable delivery modes to reduce latency.¶
Client-server video on demand applications using WebRTC or RTSP. These benefit from QUIC stream demultiplexing in the same way as interactive client-server applications, but with relaxed latency bounds that make them fit better with existing congestion control algorithms and reliable delivery.¶
Live video streaming from a server can also benefit from stream demultiplexing. If designed carefully, it should be easier to gateway RTP over QUIC into multicast RTP for scalable delivery than to gateway HTTP adaptive video over QUIC into multicast.¶
The use cases that are most applicable today given the existing and known future capabilities of QUIC are included in this section.¶
Editor Note: this section is a work in progress, and is based on the opinions of the draft authors. We are happy to be guided by discussion about other use cases.¶
Unidirectional live stream contribution. Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or going on to an audience in real time in relatively low bitrates (~1-5Mbit). The second scenario is larger bitrate contribution feeds in broadcast. This can be an OB feed "back to base" into playout gallery, or from playout facilities to online distribution platforms.¶
Distribution from platform to audience. Whilst use of WebRTC or RTSP today for On-Demand media streaming is not typical with adaptive streaming like HLS and DASH being predominantly used as WebRTC is more applicable in latency sensitive contexts such as live sporting events. Instead use cases where there is live streaming of TV linear output, or live streaming such as Twitch or Facebook, or non-UGC services like OTT offerings made by broadcasters.¶
Even a cursory examination of the existing proposals listed in Section 3 shows that there are fundamental differences in the approaches being used - for instance, whether a proposal uses RTP as its Media Transport Protocol.¶
In this section, we attempt to focus on high-level requirements for real time media streaming over a QUIC connection, recognizing that¶
When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details based on capabilities and preferences.¶
TODO: confirm requirements for latency¶
[I-D.draft-ietf-mops-streaming-opcons] describes these latency requirements for streaming media.¶
TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement.¶
TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport.¶
Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently.¶
TODO: Unsure if this should be a requirement. If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to explicitly exclude it? Also, WebTransport [I-D.draft-ietf-webtrans-overview] has normative language around congestion control which may be at odds with our potential requirements.¶
The encapsulation SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing.¶
TODO: More details are required here¶
This section covers topics that are explicitly out of scope for the time being.¶
From Section 8.2 of [RFC9000]:¶
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 required to support those use cases today.¶
The creation of new media transport protocols should be avoided, and instead we should make use of RTP [RFC3550] and the existing ecosystem of payload formats and methods of signalling where possible. Work on QUIC encapsulation may reveal a need to extend these specificiations; in which case we should work with the relevant working groups and present our use-cases.¶
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 would require a QUIC protocol extension to do so. In addition, the inclusion of multicast would introduce more complexity in both the specification and client implimentations.¶
This document makes no requests of IANA.¶
As this document is intended to guide discussion and consensus, it introduces no security considerations of its own.¶
The authors would like the thank the many authors of of the specifications referenced in Section 3 for their work:¶
James Gruessing would also like to thank Francesco Illy and Nicholas Book for their part in providing the needed motivation.¶