Media Over QUIC - Use Cases and Considerations for Media Transport Protocol Design
draft-gruessing-moq-requirements-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | James Gruessing , Spencer Dawkins | ||
| Last updated | 2022-03-06 | ||
| Replaced by | draft-ietf-moq-requirements | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gruessing-moq-requirements-01
MOQ Mailing List J. Gruessing
Internet-Draft Nederlandse Publieke Omroep
Intended status: Informational S. Dawkins
Expires: 8 September 2022 Tencent America LLC
7 March 2022
Media Over QUIC - Use Cases and Considerations for Media Transport
Protocol Design
draft-gruessing-moq-requirements-01
Abstract
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
(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
(https://www.ietf.org/mailman/listinfo/moq).
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 8 September 2022.
Gruessing & Dawkins Expires 8 September 2022 [Page 1]
Internet-Draft MoQ Use Cases and Considerations March 2022
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. For The Impatient Reader . . . . . . . . . . . . . . . . 3
1.2. Why QUIC For Media? . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Many Meanings of "Media Over QUIC" . . . . . . . . . 5
2.2. Media Transport Protoccol . . . . . . . . . . . . . . . . 5
2.3. Latency Requirement Categories . . . . . . . . . . . . . 6
3. Prior and Existing Specifications . . . . . . . . . . . . . . 7
3.1. QRT: QUIC RTP Tunnelling . . . . . . . . . . . . . . . . 7
3.2. RTP over QUIC . . . . . . . . . . . . . . . . . . . . . . 7
3.3. RUSH - Reliable (unreliable) streaming protocol . . . . . 7
3.4. Tunnelling SRT over QUIC . . . . . . . . . . . . . . . . 7
3.5. Warp - Segmented Live Video Transport . . . . . . . . . . 8
3.6. Comparison of Existing Specifications . . . . . . . . . . 8
4. Use Cases Informing This Proposal . . . . . . . . . . . . . . 8
4.1. Interactive Media . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Gaming . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Remote Desktop . . . . . . . . . . . . . . . . . . . 10
4.1.3. Video Conferencing/Telephony . . . . . . . . . . . . 10
4.2. Live Media . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Live Media Ingest . . . . . . . . . . . . . . . . . . 11
4.2.2. Live Media Syndication . . . . . . . . . . . . . . . 12
4.2.3. Live Media Streaming . . . . . . . . . . . . . . . . 12
4.3. On-Demand Media . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. On-Demand Ingest . . . . . . . . . . . . . . . . . . 13
4.3.2. On-Demand Media Streaming . . . . . . . . . . . . . . 13
5. Proposed Scope for "Media Over QUIC" . . . . . . . . . . . . 14
5.1. Analysis for Interactive Use Cases . . . . . . . . . . . 14
5.2. Analysis for Live Media Use Cases . . . . . . . . . . . . 14
5.3. Analysis for On-Demand Use Cases . . . . . . . . . . . . 14
6. Considerations for Protocol Work . . . . . . . . . . . . . . 15
6.1. Here Be Dragons . . . . . . . . . . . . . . . . . . . . . 15
Gruessing & Dawkins Expires 8 September 2022 [Page 2]
Internet-Draft MoQ Use Cases and Considerations March 2022
6.2. Codec Agility . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Support an Appropriate Range of Latencies . . . . . . . . 16
6.4. Migration of Sessions . . . . . . . . . . . . . . . . . . 16
6.5. Appropriate Congestion Control . . . . . . . . . . . . . 16
6.6. Support Lossless and Lossy Media Transport . . . . . . . 17
6.7. Flow Directionality . . . . . . . . . . . . . . . . . . . 17
6.8. WebTransport . . . . . . . . . . . . . . . . . . . . . . 17
6.9. Authentication . . . . . . . . . . . . . . . . . . . . . 17
6.10. Considerations Implying QUIC Extensions . . . . . . . . . 17
6.10.1. NAT Traversal . . . . . . . . . . . . . . . . . . . 18
6.10.2. Multicast . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. 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.
1.1. For The Impatient Reader
* Our proposal is to focus on live media use cases, as described in
Section 5, rather than on interactive media use cases or on-demand
use cases.
* The reasoning behind this proposal can be found in Section 5.1.
* The considerations for protocol work to satisfy the proposed use
cases can be found in Section 6.
Most of the rest of this document provides background for these
sections.
1.2. 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 ([RFC9000]) was chartered
([QUIC-goals]), the key goals for QUIC were:
Gruessing & Dawkins Expires 8 September 2022 [Page 3]
Internet-Draft MoQ Use Cases and Considerations March 2022
* 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 ([I-D.draft-ietf-quic-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 ([I-D.draft-ietf-quic-datagram]),
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".
2. Terminology
Gruessing & Dawkins Expires 8 September 2022 [Page 4]
Internet-Draft MoQ Use Cases and Considerations March 2022
2.1. The Many Meanings of "Media Over QUIC"
Protocol developers have been considering the implications of the
QUIC protocol ([RFC9000]) 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 ([RFC3550])
* 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 (Section 2.2) in
a QUIC payload
* an IETF mailing list ([MOQ-ml]), 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
[AVTCORE-2022-02], although no drafts in this space have yet been
adopted by the AVTCORE working group.
2.2. 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:
Gruessing & Dawkins Expires 8 September 2022 [Page 5]
Internet-Draft MoQ Use Cases and Considerations March 2022
Media
---------------------------
Media Format
---------------------------
Media Transport Protocol(s)
---------------------------
QUIC
where "Media Format" would be something like RTP payload formats or
ISOBMFF [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.
2.3. Latency Requirement Categories
Within this document, we extend the latency requirement categories
for streaming media described in
[I-D.draft-ietf-mops-streaming-opcons]:
* 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 [I-D.draft-ietf-mops-streaming-opcons], 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.
Gruessing & Dawkins Expires 8 September 2022 [Page 6]
Internet-Draft MoQ Use Cases and Considerations March 2022
3. 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 (Section 3.3), it is unknown if the other
specifications listed in this section 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.
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]
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.
3.4. Tunnelling SRT over QUIC
[I-D.draft-sharabayko-srt-over-quic]
Gruessing & Dawkins Expires 8 September 2022 [Page 7]
Internet-Draft MoQ Use Cases and Considerations March 2022
Secure Reliable Transport (SRT) ([I-D.draft-sharabayko-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.
3.5. Warp - Segmented Live Video Transport
[I-D.draft-lcurley-warp]
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 [I-D.draft-ietf-webtrans-overview].
3.6. 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.
4. 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.
Gruessing & Dawkins Expires 8 September 2022 [Page 8]
Internet-Draft MoQ Use Cases and Considerations March 2022
An early draft in the "media over QUIC" space,
[I-D.draft-rtpfolks-quic-rtp-over-quic], 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 Section 2.
It is likely that we should add other characteristics, as we come to
understand them.
4.1. 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 [RFC6363] and codec-level packet loss concealment
[RFC6716], 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
[I-D.draft-cardwell-iccrg-bbr-congestion-control], 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 [RFC3550], which provide low-level control of
packetization and transmission.
Gruessing & Dawkins Expires 8 September 2022 [Page 9]
Internet-Draft MoQ Use Cases and Considerations March 2022
4.1.1. Gaming
+=====================+============+
| Attribute | Value |
+=====================+============+
| *Senders/Receivers* | One to One |
+---------------------+------------+
| *Bi-directional* | Yes |
+---------------------+------------+
| *Latency* | Ull-50 |
+---------------------+------------+
Table 1
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.
4.1.2. Remote Desktop
+=====================+============+
| Attribute | Value |
+=====================+============+
| *Senders/Receivers* | One to One |
+---------------------+------------+
| *Bi-directional* | Yes |
+---------------------+------------+
| *Latency* | Ull-50 |
+---------------------+------------+
Table 2
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.
4.1.3. Video Conferencing/Telephony
+=====================+===================+
| Attribute | Value |
+=====================+===================+
| *Senders/Receivers* | Many to Many |
+---------------------+-------------------+
| *Bi-directional* | Yes |
+---------------------+-------------------+
Gruessing & Dawkins Expires 8 September 2022 [Page 10]
Internet-Draft MoQ Use Cases and Considerations March 2022
| *Latency* | Ull-50 to Ull-200 |
+---------------------+-------------------+
Table 3
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.
4.2. Live Media
The use cases in this section, unlike the use cases described in
Section 4.1, 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 Section 4.1,
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.
4.2.1. Live Media Ingest
+=====================+======================+
| Attribute | Value |
+=====================+======================+
| *Senders/Receivers* | One to One |
+---------------------+----------------------+
| *Bi-directional* | No |
+---------------------+----------------------+
| *Latency* | Ull-200 to Ultra-Low |
+---------------------+----------------------+
Table 4
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.
Gruessing & Dawkins Expires 8 September 2022 [Page 11]
Internet-Draft MoQ Use Cases and Considerations March 2022
4.2.2. Live Media Syndication
+=====================+======================+
| Attribute | Value |
+=====================+======================+
| *Senders/Receivers* | One to One |
+---------------------+----------------------+
| *Bi-directional* | No |
+---------------------+----------------------+
| *Latency* | Ull-200 to Ultra-Low |
+---------------------+----------------------+
Table 5
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.
4.2.3. Live Media Streaming
+=====================+======================+
| Attribute | Value |
+=====================+======================+
| *Senders/Receivers* | One to Many |
+---------------------+----------------------+
| *Bi-directional* | No |
+---------------------+----------------------+
| *Latency* | Ull-200 to Ultra-Low |
+---------------------+----------------------+
Table 6
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.
Gruessing & Dawkins Expires 8 September 2022 [Page 12]
Internet-Draft MoQ Use Cases and Considerations March 2022
4.3. 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.
4.3.1. On-Demand Ingest
+=====================+=============+
| Attribute | Value |
+=====================+=============+
| *Senders/Receivers* | One to Many |
+---------------------+-------------+
| *Bi-directional* | No |
+---------------------+-------------+
| *Latency* | On Demand |
+---------------------+-------------+
Table 7
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.
4.3.2. On-Demand Media Streaming
+=====================+=============+
| Attribute | Value |
+=====================+=============+
| *Senders/Receivers* | One to Many |
+---------------------+-------------+
| *Bi-directional* | No |
+---------------------+-------------+
| *Latency* | On Demand |
+---------------------+-------------+
Table 8
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.
Gruessing & Dawkins Expires 8 September 2022 [Page 13]
Internet-Draft MoQ Use Cases and Considerations March 2022
5. Proposed Scope for "Media Over QUIC"
Our proposal is that "Media Over QUIC" discussions focus first on the
use cases described in Section 4.2, which are Live Media Ingest
(Section 4.2.1), Syndication (Section 4.2.2), and Streaming
(Section 4.2.3). Our reasoning for this suggestion follows.
Each of the above use cases in Section 4 fit into one of three
classifications of solutions.
5.1. Analysis for Interactive Use Cases
The first group, Interactive Media, as described in Section 4.1, and
covering gaming (Section 4.1.1), screen sharing (Section 4.1.2), and
general video conferencing (Section 4.1.3), are largely covered by
RTP, often in conjunction with WebRTC [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.
5.2. Analysis for Live Media Use Cases
The second group of classifications, in Section 4.2, covering Live
Media Ingest (Section 4.2.1), Live Media Syndication (Section 4.2.2),
and Live Media Streaming (Section 4.2.3) are likely the use cases
that will benefit most from this work.
Existing ingest and streaming protocols such as HLS [RFC8216] and
DASH [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.
5.3. Analysis for On-Demand Use Cases
The third group, Section 4.3, covering On-Demand Media Ingest
(Section 4.3.1) and On-Demand Media streaming (Section 4.3.2) 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.
Gruessing & Dawkins Expires 8 September 2022 [Page 14]
Internet-Draft MoQ Use Cases and Considerations March 2022
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 [RFC7230] and HTTP/2
[RFC7540], 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 [RFC7826] 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.
6. Considerations for Protocol Work
Even a cursory examination of the existing proposals listed in
Section 3 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 Section 4.2, although other
use cases are mentioned for comparison and contrast.
6.1. Here Be Dragons
The discussion in Section 6 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.
6.2. 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 [RFC4566].
Gruessing & Dawkins Expires 8 September 2022 [Page 15]
Internet-Draft MoQ Use Cases and Considerations March 2022
6.3. 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.
6.4. 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
[I-D.draft-ietf-quic-multipath] but support for full QUIC operation
over multiple paths between senders and receivers is by no means
essential.
6.5. 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 [RFC9002], Cubic [RFC8312], and
BBR [I-D.draft-cardwell-iccrg-bbr-congestion-control] 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 Section 4.3.
Conversely, for the interactive use cases described in Section 4.1,
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 [RFC8298] or NADA [RFC8698] may be more appropriate for media.
"Congestion Control Requirements for Interactive Real-Time Media"
[RFC8836] is a useful reference.
Gruessing & Dawkins Expires 8 September 2022 [Page 16]
Internet-Draft MoQ Use Cases and Considerations March 2022
Awkwardly, the live media use cases described in Section 4.2 live
somewhere in the middle, and work will be needed to understand the
characteristics of an appropriate congestion control mechanism for
these use cases.
6.6. 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.
6.7. 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.
6.8. 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 [I-D.draft-ietf-webtrans-overview] has
normative language around congestion control, which may be at odds
with the considerations described in Section 6.5.
6.9. 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
6.10. 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.
Gruessing & Dawkins Expires 8 September 2022 [Page 17]
Internet-Draft MoQ Use Cases and Considerations March 2022
6.10.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 needed to support
those use cases.
6.10.2. 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).
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. Informative References
[AVTCORE-2022-02]
"AVTCORE 2022-02 interim meeting materials", February
2022, <https://datatracker.ietf.org/meeting/interim-2022-
avtcore-01/session/avtcore>.
[DASH] "ISO/IEC 23009-1:2019: Dynamic adaptive streaming over
HTTP (DASH) -- Part 1: Media presentation description and
segment formats (2nd edition)", n.d.,
<https://www.iso.org/standard/79329.html>.
Gruessing & Dawkins Expires 8 September 2022 [Page 18]
Internet-Draft MoQ Use Cases and Considerations March 2022
[I-D.draft-cardwell-iccrg-bbr-congestion-control]
Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
Jacobson, "BBR Congestion Control", Work in Progress,
Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
control-01, 7 November 2021,
<https://datatracker.ietf.org/doc/html/draft-cardwell-
iccrg-bbr-congestion-control-01>.
[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-
01, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-engelbart-
rtp-over-quic-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-hurst-quic-rtp-tunnelling-01>.
[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-09, 1
March 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-mops-streaming-opcons-09>.
[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-10, 4 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-10>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
Gruessing & Dawkins Expires 8 September 2022 [Page 19]
Internet-Draft MoQ Use Cases and Considerations March 2022
[I-D.draft-ietf-quic-multipath]
Liu, Y., Ma, Y., Coninck, Q. D., Bonaventure, O., Huitema,
C., and M. Kuehlewind, "Multipath Extension for QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-
multipath-00, 2 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
multipath-00>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-webtrans-overview-02>.
[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, <https://datatracker.ietf.org/doc/html/draft-kpugin-
rush-00>.
[I-D.draft-lcurley-warp]
Curley, L., "Warp - Segmented Live Video Transport", Work
in Progress, Internet-Draft, draft-lcurley-warp-00, 9
February 2022, <https://datatracker.ietf.org/doc/html/
draft-lcurley-warp-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-rtpfolks-
quic-rtp-over-quic-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-sharabayko-
srt-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-sharabayko-
srt-over-quic-00>.
Gruessing & Dawkins Expires 8 September 2022 [Page 20]
Internet-Draft MoQ Use Cases and Considerations March 2022
[ISOBMFF] "ISO/IEC 14496-12:2022 Information technology — Coding of
audio-visual objects — Part 12: ISO base media file
format", January 2022,
<https://www.iso.org/standard/83102.html>.
[MOQ-ml] "Moq -- Media over QUIC", n.d.,
<https://www.ietf.org/mailman/listinfo/moq>.
[QUIC-goals]
"Initial Charter for QUIC Working Group", October 2016,
<https://datatracker.ietf.org/doc/charter-ietf-quic/01/>.
[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, <https://www.rfc-editor.org/rfc/rfc3550>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/rfc/rfc4566>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/rfc/rfc6363>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <https://www.rfc-editor.org/rfc/rfc6716>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/rfc/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <https://www.rfc-editor.org/rfc/rfc7826>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/rfc/rfc8216>.
Gruessing & Dawkins Expires 8 September 2022 [Page 21]
Internet-Draft MoQ Use Cases and Considerations March 2022
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
2017, <https://www.rfc-editor.org/rfc/rfc8298>.
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
RFC 8312, DOI 10.17487/RFC8312, February 2018,
<https://www.rfc-editor.org/rfc/rfc8312>.
[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-
Assisted Dynamic Adaptation (NADA): A Unified Congestion
Control Scheme for Real-Time Media", RFC 8698,
DOI 10.17487/RFC8698, February 2020,
<https://www.rfc-editor.org/rfc/rfc8698>.
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
Requirements for Interactive Real-Time Media", RFC 8836,
DOI 10.17487/RFC8836, January 2021,
<https://www.rfc-editor.org/rfc/rfc8836>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[WebRTC] "Web Real-Time Communications Working Group", n.d.,
<https://www.w3.org/groups/wg/webrtc>.
Appendix A. Acknowledgements
The authors would like to thank the many authors 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
Gruessing & Dawkins Expires 8 September 2022 [Page 22]
Internet-Draft MoQ Use Cases and Considerations March 2022
* 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.
Authors' Addresses
James Gruessing
Nederlandse Publieke Omroep
Netherlands
Email: james.ietf@gmail.com
Spencer Dawkins
Tencent America LLC
United States of America
Email: spencerdawkins.ietf@gmail.com
Gruessing & Dawkins Expires 8 September 2022 [Page 23]