AVTCORE/MMUSIC Working Groups J. Gruessing Internet-Draft Intended status: Informational S. Dawkins Expires: 28 April 2022 Tencent America LLC 25 October 2021 QUIC Encapsulation for Media over RTP - Requirements and Use Cases draft-gruessing-moq-requirements-00 Abstract 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. 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 (https://github.com/fiestajetsam/draft-gruessing-moq-requirements). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Gruessing & Dawkins Expires 28 April 2022 [Page 1] Internet-Draft MoQ Requirements and Use Cases October 2021 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Prior and Existing Specifications . . . . . . . . . . . . . . 3 3.1. QRT: QUIC RTP Tunnelling . . . . . . . . . . . . . . . . 3 3.2. RTP over QUIC . . . . . . . . . . . . . . . . . . . . . . 4 3.3. RUSH - Reliable (unreliable) streaming protocol . . . . . 4 3.4. Tunnelling SRT over QUIC . . . . . . . . . . . . . . . . 4 3.5. Comparison of Existing Specifications . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Use Cases From I-D.draft-rtpfolks-quic-rtp-over-quic . . 5 4.1.1. Interactive peer-to-peer applications . . . . . . . . 5 4.1.2. Interactive client-server applications . . . . . . . 5 4.1.3. Client-server video on demand applications using WebRTC or RTSP . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.4. Live video streaming from a server . . . . . . . . . 6 4.2. Suggested Use Cases for "Media Over QUIC" Going Forward . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Unidirectional live stream contribution . . . . . . . 6 4.2.2. Distribution from platform to audience . . . . . . . 6 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Codec Agility . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Support a range of Latencies . . . . . . . . . . . . . . 7 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . 7 5.4. Support Lossless and Lossy Media Transport . . . . . . . 7 5.5. Flow Directionality . . . . . . . . . . . . . . . . . . . 7 5.6. WebTransport . . . . . . . . . . . . . . . . . . . . . . 7 5.7. Authentication . . . . . . . . . . . . . . . . . . . . . 8 6. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 8 6.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 8 6.2. New Media Transport Protocols . . . . . . . . . . . . . . 8 6.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Gruessing & Dawkins Expires 28 April 2022 [Page 2] Internet-Draft MoQ Requirements and Use Cases October 2021 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. 2. Terminology 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 3. Prior and Existing Specifications 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. 3.1. QRT: QUIC RTP Tunnelling [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. Gruessing & Dawkins Expires 28 April 2022 [Page 3] Internet-Draft MoQ Requirements and Use Cases October 2021 3.2. RTP over QUIC [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. 3.3. RUSH - Reliable (unreliable) streaming protocol [I-D.draft-kpugin-rush] 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. 3.4. Tunnelling SRT over QUIC [I-D.draft-sharabayko-srt-over-quic] Secure Reliable Transport (SRT) ([I-D.draft-sharabayko-srt]) itself is a general purpose transport protocol primarily for contribution 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. 3.5. Comparison of Existing Specifications * Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP unlike RUSH and SRT, as well as using existing Datagram frames * RUSH introduces new frame types as its development pre-dates Datagram frames * All drafts take differing approaches to flow/stream identification and management; some address congestion control and others just omit the subject and leave it to QUIC to handle Gruessing & Dawkins Expires 28 April 2022 [Page 4] Internet-Draft MoQ Requirements and Use Cases October 2021 * Both QRT and RUSH specify ALPN identification; the Engelbart and SRT drafts do not. 4. Use Cases 4.1. Use Cases From [I-D.draft-rtpfolks-quic-rtp-over-quic] 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. 4.1.1. Interactive peer-to-peer applications 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. 4.1.2. Interactive client-server applications 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. 4.1.3. Client-server video on demand applications using WebRTC or RTSP 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. Gruessing & Dawkins Expires 28 April 2022 [Page 5] Internet-Draft MoQ Requirements and Use Cases October 2021 4.1.4. Live video streaming from a server 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. 4.2. Suggested Use Cases for "Media Over QUIC" Going Forward 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. 4.2.1. Unidirectional live stream contribution 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. 4.2.2. Distribution from platform to audience 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. 5. Requirements 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 * additional analysis will be required, and Gruessing & Dawkins Expires 28 April 2022 [Page 6] Internet-Draft MoQ Requirements and Use Cases October 2021 * we are starting with requirements that are apparent for RTP-based proposals 5.1. Codec Agility 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. 5.2. Support a range of Latencies TODO: confirm requirements for latency [I-D.draft-ietf-mops-streaming-opcons] describes these latency requirements for streaming media. * 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) 5.3. Congestion Control TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement. 5.4. 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. 5.5. Flow Directionality Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. 5.6. WebTransport 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. Gruessing & Dawkins Expires 28 April 2022 [Page 7] Internet-Draft MoQ Requirements and Use Cases October 2021 5.7. Authentication 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 6. Non-requirements This section covers topics that are explicitly out of scope for the time being. 6.1. NAT Traversal 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. 6.2. New Media Transport Protocols 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. 6.3. 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 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. Gruessing & Dawkins Expires 28 April 2022 [Page 8] Internet-Draft MoQ Requirements and Use Cases October 2021 7. IANA Considerations This document makes no requests of IANA. 8. Security Considerations As this document is intended to guide discussion and consensus, it introduces no security considerations of its own. 9. References 9.1. Normative References [I-D.draft-ietf-mops-streaming-opcons] Holland, J., Begen, A., and S. Dawkins, "Operational Considerations for Streaming Media", Work in Progress, Internet-Draft, draft-ietf-mops-streaming-opcons-07, 14 September 2021, . [I-D.draft-ietf-quic-datagram] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", Work in Progress, Internet- Draft, draft-ietf-quic-datagram-06, 5 October 2021, . [I-D.draft-ietf-webtrans-overview] Vasiliev, V., "The WebTransport Protocol Framework", Work in Progress, Internet-Draft, draft-ietf-webtrans-overview- 02, 28 July 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 9.2. Informative References [I-D.draft-engelbart-rtp-over-quic] Ott, J. and M. Engelbart, "RTP over QUIC", Work in Progress, Internet-Draft, draft-engelbart-rtp-over-quic- 00, 12 July 2021, . Gruessing & Dawkins Expires 28 April 2022 [Page 9] Internet-Draft MoQ Requirements and Use Cases October 2021 [I-D.draft-hurst-quic-rtp-tunnelling] Hurst, S., "QRT: QUIC RTP Tunnelling", Work in Progress, Internet-Draft, draft-hurst-quic-rtp-tunnelling-01, 28 January 2021, . [I-D.draft-ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- quic-http-34, 2 February 2021, . [I-D.draft-kpugin-rush] Pugin, K., Frindell, A., Cenzano, J., and J. Weissman, "RUSH - Reliable (unreliable) streaming protocol", Work in Progress, Internet-Draft, draft-kpugin-rush-00, 12 July 2021, . [I-D.draft-rtpfolks-quic-rtp-over-quic] Ott, J., Even, R., Perkins, C., and V. Singh, "RTP over QUIC", Work in Progress, Internet-Draft, draft-rtpfolks- quic-rtp-over-quic-01, 1 September 2017, . [I-D.draft-sharabayko-srt] Sharabayko, M., Sharabayko, M., Dube, J., Kim, J., and J. Kim, "The SRT Protocol", Work in Progress, Internet-Draft, draft-sharabayko-srt-01, 7 September 2021, . [I-D.draft-sharabayko-srt-over-quic] Sharabayko, M. and M. Sharabayko, "Tunnelling SRT over QUIC", Work in Progress, Internet-Draft, draft-sharabayko- srt-over-quic-00, 28 July 2021, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . Gruessing & Dawkins Expires 28 April 2022 [Page 10] Internet-Draft MoQ Requirements and Use Cases October 2021 Appendix A. Acknowledgements The authors would like the thank the many authors of of the specifications referenced in Section 3 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 James Gruessing would also like to thank Francesco Illy and Nicholas Book for their part in providing the needed motivation. Authors' Addresses James Gruessing Email: james.ietf@gmail.com Spencer Dawkins Tencent America LLC United States of America Email: spencerdawkins.ietf@gmail.com Gruessing & Dawkins Expires 28 April 2022 [Page 11]