Skip to main content

Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design
draft-ietf-moq-requirements-00

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 "Expired".
Authors James Gruessing , Spencer Dawkins
Last updated 2023-06-06 (Latest revision 2023-06-05)
Replaces draft-gruessing-moq-requirements
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-moq-requirements-00
MOQ Mailing List                                            J. Gruessing
Internet-Draft                               Nederlandse Publieke Omroep
Intended status: Informational                                S. Dawkins
Expires: 7 December 2023                             Tencent America LLC
                                                             5 June 2023

    Media Over QUIC - Use Cases and Requirements for Media Transport
                            Protocol Design
                     draft-ietf-moq-requirements-00

Abstract

   This document describes use cases and requirements that guide the
   specification of a simple, low-latency media delivery solution for
   ingest and distribution, using either the QUIC protocol or
   WebTransport.

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 7 December 2023.

Gruessing & Dawkins      Expires 7 December 2023                [Page 1]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

Copyright Notice

   Copyright (c) 2023 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.  Note for MOQ Working Group participants . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Distinguishing between Interactive and Live Streaming Use
           Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases Informing This Proposal . . . . . . . . . . . . . .   5
     3.1.  Interactive Media . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Gaming  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.2.  Remote Desktop  . . . . . . . . . . . . . . . . . . .   6
       3.1.3.  Video Conferencing/Telephony  . . . . . . . . . . . .   7
     3.2.  Hybrid Interactive and Live Media . . . . . . . . . . . .   7
     3.3.  Live Media  . . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.1.  Live Media Ingest . . . . . . . . . . . . . . . . . .   8
       3.3.2.  Live Media Syndication  . . . . . . . . . . . . . . .   8
       3.3.3.  Live Media Streaming  . . . . . . . . . . . . . . . .   9
   4.  Requirements for Protocol Work  . . . . . . . . . . . . . . .   9
     4.1.  Notes to the Reader . . . . . . . . . . . . . . . . . . .   9
     4.2.  Specific Protocol Considerations  . . . . . . . . . . . .  10
       4.2.1.  Delivery Assurance vs. Delay  . . . . . . . . . . . .  10
       4.2.2.  Support Webtransport/Raw QUIC as media transport  . .  10
       4.2.3.  Media Negotiation & Agility . . . . . . . . . . . . .  10
     4.3.  Media Data Model  . . . . . . . . . . . . . . . . . . . .  11
     4.4.  Publishing Media  . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Naming and Addressing Media Resources . . . . . . . . . .  12
       4.5.1.  Scoped to an Origin/Domain, Application specific. . .  12
       4.5.2.  Allows subscribing or requesting for the data matching
               the name by the consumers . . . . . . . . . . . . . .  12
     4.6.  Packaging Media . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Media Consumption . . . . . . . . . . . . . . . . . . . .  13
     4.8.  Relays, Caches, and other MOQ Network Elements  . . . . .  13
       4.8.1.  Pull & Push . . . . . . . . . . . . . . . . . . . . .  13
     4.9.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  13

Gruessing & Dawkins      Expires 7 December 2023                [Page 2]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

       4.9.1.  Authentication & Authorisation  . . . . . . . . . . .  13
       4.9.2.  Media Encryption  . . . . . . . . . . . . . . . . . .  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   This document describes use cases and requirements that guide the
   specification of a simple, low-latency media delivery solution for
   ingest and distribution [MOQ-charter], using either the QUIC protocol
   [RFC9000] or WebTransport [WebTrans-charter] as transport protocols.

1.1.  Note for MOQ Working Group participants

   When adopted, this document is intended to capture use cases that are
   in scope for work on the MOQ protocol [MOQ-charter], and requirements
   that arise from these use cases.

   As of this writing, the authors have not planned to request
   publication on this document, based on our understanding of the
   IESG's statement on "Support Documents in IETF Working Groups"
   [IESG-sdwg], which says (among other things):

      While writing down such things as requirements and use cases help
      to get a common understanding (and often common language) between
      participants in the working group, support documentation doesn’t
      always have a high archival value.  Under most circumstances, the
      IESG encourages the community to consider alternate mechanisms for
      publishing this content, such as on a working group wiki, in an
      informational appendix of a solution document, or simply as an
      expired draft.

   It seems reasonable for the working group to improve this document,
   and then consider whether the result justifies publication as a part
   of the RFC archival document series.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Gruessing & Dawkins      Expires 7 December 2023                [Page 3]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

2.1.  Distinguishing between Interactive and Live Streaming Use Cases

   The MOQ charter [MOQ-charter] lists three use cases as being in scope
   of the MOQ protocol

      use cases including live streaming, gaming, and media conferencing

   but does not include (directly or by reference) a definition of "live
   streaming" or "interactive" (a term that has been used to describe
   gaming and media conferencing, as distinct from "live streaming").
   It seems useful to describe these two terms, as classes of use cases,
   before we describe individual use cases in more detail.

   MOQ participants have discussed making this distinction based on
   quantitative measures such as latency, but since MOQ use cases can
   include an arbitrary number of relays, we offer a distinction that is
   based on how users experience that distinction.  If two users are
   able to interact in the way that seems interactive, as described in
   the proposed definitions, the use case is interactive; if two users
   are unable to interact in that way, the use case is live streaming.

   We propose these definitions:

   *Interactive*:  a use case with coupled bidirectional media flows

   Interactive use cases have bidirectional media flows sufficiently
   coupled with each other, that media from one sender can cause the
   receiver to reply by sending its own media back to the original
   sender.

   For instance, a speaker in a conferencing application might make a
   statement, and then ask, "but what do you folks think?"  If one of
   the listeners is able to answer in a timeframe that seems natural,
   without without waiting for the current speaker to explicitly "hand
   over" control of the conversation, this would qualify as
   "Interactive".

   *Live Streaming*:  a use case with unidirectional media flows, or
      uncoupled bidirectional flows

   Live Streaming use cases allow consumers of media to "watch
   together", without having a sense that one consumer is experiencing
   the media before another consumer.  This does not require the
   delivery of live media to be strictly synchronized between media
   consumers, but only that from the viewpoint of individual consumers,
   media delivery *appears to be* synchronized.

Gruessing & Dawkins      Expires 7 December 2023                [Page 4]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   It is common for live streaming use cases to send media in one
   direction, and "something else" in the other direction - for
   instance, a video receiver might be returning requests that the
   sender change the media encoding or media rate in use, or reorgient a
   camera.  This type of feedback doesn't qualify as "bidirectional
   media".

   If two sender/receivers are each sending media to the other, but
   what's being carried in one direction has no relationship with what's
   being carried in the other direction, this would not qualify as
   "Interactive".

   *Note: these descriptions are a starting point.  Feedback and
   pushback are both welcomed.*

3.  Use Cases Informing This Proposal

   Our goal in this section is to understand the range of use cases that
   are in scope for "Media Over QUIC" [MOQ-charter].

   For each use case in this section, we also describe

   *  the number of senders or receiver in a given session transmitting
      distinct streams,
   *  whether a session has bi-directional flows of media from senders
      and receivers, which may also include timely non-media such as
      haptics or timed events.

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

3.1.  Interactive Media

   The use cases described in this section have one particular attribute
   in common - the target the lowest possible latency as can be achieved
   at the trade off of data loss and complexity.  For example,

   *  It may make 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 round trips in order to recover from packet loss.
   *  It's generally infeasible to use congestion control schemes like
      BBR [I-D.draft-cardwell-iccrg-bbr-congestion-control] in many
      deployments, since BBR has probing mechanisms that rely on
      temporarily inducing delay, but these mechanisms can then amortize
      the consequences of induced delay over multiple RTTs.

Gruessing & Dawkins      Expires 7 December 2023                [Page 5]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   This may help to explain why interactive use cases have typically
   relied on protocols such as RTP [RFC3550], which provide low-level
   control of packetization and transmission, with addtional support for
   retransmission as an optional extension.

3.1.1.  Gaming

                   +=====================+============+
                   | Attribute           | Value      |
                   +=====================+============+
                   | *Senders/Receivers* | One to One |
                   +---------------------+------------+
                   | *Bi-directional*    | Yes        |
                   +---------------------+------------+

                                 Table 1

   In this use case the computation for running a video game (single or
   multiplayer) is performed externally on a hosted service, with user
   inputs from input devices sent to the server, and media, usually
   video and audio of gameplay returned.  This may also include the
   client receiving other types of signaling, such as triggers for
   haptic feedback, as well as the client sending media such as
   microphone audio for in-game chat with other players.  Latency may be
   considerably important in this use case as updates to video occur in
   response user input, with certain genres of games having high
   requirements in responsiveness and/or a high frequency of user input.

3.1.2.  Remote Desktop

                   +=====================+=============+
                   | Attribute           | Value       |
                   +=====================+=============+
                   | *Senders/Receivers* | One to Many |
                   +---------------------+-------------+
                   | *Bi-directional*    | Yes         |
                   +---------------------+-------------+

                                  Table 2

   Similar to the gaming use case in many requirements, but where a user
   wishes to observe or control the graphical user interface of another
   computer through local user interfaces.  Latency requirements with
   this use case are marginally different than the gaming use case as
   greater input latency may be more tolerated by users.  This use case
   may also include a need to support signalling and/or transmitting of
   files or devices connected to the user's computer.

Gruessing & Dawkins      Expires 7 December 2023                [Page 6]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

3.1.3.  Video Conferencing/Telephony

                  +=====================+==============+
                  | Attribute           | Value        |
                  +=====================+==============+
                  | *Senders/Receivers* | Many to Many |
                  +---------------------+--------------+
                  | *Bi-directional*    | Yes          |
                  +---------------------+--------------+

                                 Table 3

   Where media is both sent and received; This may include audio from
   both microphone(s) and/or cameras, 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 200ms or more for some media
   types such as audio, but other media types in this use case have much
   more stringent latency targets.

3.2.  Hybrid Interactive and Live Media

   For the video conferencing/telephony use case, there can be
   additional scenarios where the audience greatly outnumbers the
   concurrent active participants, but any member of the audience could
   participate.  As this has a much larger total number of participants
   - as many as Live Media Streaming Section 3.3.3, but with the bi-
   directionality of conferencing, this should be considered a "hybrid".
   There can be additional functionality as well that overlap between
   the two, such as "live rewind", or recording abilities.

   Another consideration is the limits of "human bandwidth" - as the
   number of sources are included into a given session increase, the
   amount of media that can usefully understood by a single person
   diminishes.  To put it more simply - too many people talking at once
   is much more difficult to understand than one person speaking at a
   time, and this varies on the audience and circumstance.  Subsequently
   this will define some limitations in the number of potential
   concurrent or semi-concurrent, bidirectional communications that
   occur.

Gruessing & Dawkins      Expires 7 December 2023                [Page 7]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

3.3.  Live Media

   The use cases in this section like those in Section 3.1 do set some
   expectations to minimise high and/or highly variable latency, however
   their key difference is that are seldom bi-directional as their basis
   is on mass-consumption of media or the contribution of it into a
   platform to syndicate, or distribute.  Latency is less noticeable
   over loss, and may be more accepting of having slightly more latency
   to increase guarantee of delivery.

3.3.1.  Live Media Ingest

                   +=====================+============+
                   | Attribute           | Value      |
                   +=====================+============+
                   | *Senders/Receivers* | One to One |
                   +---------------------+------------+
                   | *Bi-directional*    | No         |
                   +---------------------+------------+

                                 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 signaling of connection information (bandwidth, latency) based on
   data sent by the receiver, and the media may go through additional
   steps of transcoding or transformation before being distributed.

3.3.2.  Live Media Syndication

                   +=====================+============+
                   | Attribute           | Value      |
                   +=====================+============+
                   | *Senders/Receivers* | One to One |
                   +---------------------+------------+
                   | *Bi-directional*    | No         |
                   +---------------------+------------+

                                 Table 5

   Where media is sent onwards to another platform for further
   distribution and not directly used for presentation to an audience,
   however may be monitored by operational systems and/or people.  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.

Gruessing & Dawkins      Expires 7 December 2023                [Page 8]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

3.3.3.  Live Media Streaming

                   +=====================+=============+
                   | Attribute           | Value       |
                   +=====================+=============+
                   | *Senders/Receivers* | One to Many |
                   +---------------------+-------------+
                   | *Bi-directional*    | No          |
                   +---------------------+-------------+

                                  Table 6

   Where media is received from a live broadcast or stream either as a
   broadcast with fixed duration or as ongoing 24/7 output.  The number
   of receivers may vary depending on the type of content; breaking news
   events may see sharp, sudden spikes, whereas sporting and
   entertainment events may see a more gradual ramp up with a higher
   sustained peak with some changes based on match breaks or interludes.

   Such broadcasts may comprise of multiple audio or video outputs with
   different codecs or bitrates, and 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 between the live edge and trailing 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.

4.  Requirements for Protocol Work

   Our goal in this section is to understand the requirements that
   result from the use cases described in Section 3.

4.1.  Notes to the Reader

   *  Note: the intention for the requirements in this document is that
      they are useful for MOQ working group participants, to recognize
      constraints, and useful for readers outside the MOQ working group
      to understand the high-level functionality of the MOQ protocol, as
      they consider implementation and deployment of systems that rely
      on the MOQ protocol.

Gruessing & Dawkins      Expires 7 December 2023                [Page 9]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

4.2.  Specific Protocol Considerations

   In order to support the various topologies and patterns of media
   flows with the protocol, the protocol MUST support both sending and
   receiving of media streams, as separate actions or concurrently in a
   given connection.

4.2.1.  Delivery Assurance vs. Delay

   Different use cases have varying requirements with respect to the
   tradeoffs associated in having guarantee of delivery vs delay - in
   some (such as telephony) it may be acceptable to drop some or all of
   the media as a result of changes in network connectivity, throughput,
   or congestion whereas in other scenarios all media must arrive at the
   receiving end even if delayed.  There SHOULD be support for some
   means for a connection to signal which media may be abandoned, and
   behaviours of both senders receivers defined when delay or loss
   occurs.  Where multiple variants of media are sent, this SHOULD be
   done so in a way that provides pipelining so each media stream may be
   processed in parallel.

4.2.2.  Support Webtransport/Raw QUIC as media transport

   There should be a degree of decoupling from the underlying transport
   protocols and MoQ itself despite the "Q" in the name, in particular
   to provide future agility and prevent any potential ossification
   being tied to specific version(s) of dependant protocols.

   Many of the use cases will be deployed in contexts where web browsers
   are the common application runtime; thus the use of existing
   protocols and APIs is desireable for implementations.  Support for
   WebTransport [I-D.draft-ietf-webtrans-overview] will be defined,
   although implementations or deployments running outside browsers will
   not need to use WebTransport, thus support for the protocol running
   directly atop QUIC should be provided.

   Considerations should be made clear with respect to modes where
   WebTransport "falls back" to using HTTP/2 or other future non-QUIC
   based protocol.

4.2.3.  Media Negotiation & Agility

   All entities which directly process media will have support for a
   variety of media codecs, both codecs which exist now and codecs that
   will be defined in the future.  Consequently the protocol will
   provide the capability for sender and receiver to negotiate which
   media codecs will be used in a given session.

Gruessing & Dawkins      Expires 7 December 2023               [Page 10]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   The protocol SHOULD remain codec agnostic as much as possible, and
   should allow for new media formats and codecs to be supported without
   change in specification.

   The working group should consider if a minimum, suggestive set of
   codecs should be supported for the purposes of interop, however this
   SHOULD avoid being strict to simplify use cases and deployments that
   don't require certain capability e.g. telephony which may not require
   video codecs.

4.3.  Media Data Model

   As the protocol will handle many different types of media,
   classifications, and variations when all entities describe the media
   a model should be defined which represents this, with a clear
   addressing scheme.  This should factor in at least, but not limited
   to allow future types:

   Media Types  Video, audio, subtitles, ancillary data

   Classifications  Codec, language, layers

   Variations  For each stream, the resolution(s), bitrate(s).  Each
      variant should be uniquely identifiable and addressable.

   Considerations should be made to addressing of individual audio/video
   frames as opposed to groups, in addition to how the model
   incorporates signalling of prioritisation, media dependency, and
   cacheability to all entities.

4.4.  Publishing Media

   Many of the use cases have bi-directional flows of media, with
   clients both sending and receiving media concurrently, thus the
   protocol should have a unified approach in connection negotiation and
   signalling to send and received media both at the start and ongoing
   in the lifetime of a session including describing when flow of media
   is unsupported (e.g. a live media server signalling it does not
   support receiving from a given client).

   In the initiation of a session both client and server must perform
   negotiation in order to agree upon a variety of details before media
   can move in any direction:

   *  Is the client authenticated and subsequently authorised to
      initiate a connection?
   *  What media is available, and for each what are the parameters such
      as codec, bitrate, and resolution etc?

Gruessing & Dawkins      Expires 7 December 2023               [Page 11]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   *  Can media move bi-directionally, or is it unidirectional only?

4.5.  Naming and Addressing Media Resources

   As multiple streams of media may be available for concurrent sending
   such as multiple camera views or audio tracks, a means of both
   identifying the technical properties of each resource (codec,
   bitrate, etc) as well as a useful identification for playback should
   be part of the protocol.  A base level of optional metadata e.g. the
   known language of an audio track or name of participant's camera
   should be supported, but further extended metadata of the contents of
   the media or its ontology should not be supported.

4.5.1.  Scoped to an Origin/Domain, Application specific.

4.5.2.  Allows subscribing or requesting for the data matching the name
        by the consumers

4.6.  Packaging Media

   Packaging of media describes how raw media will be encapsulated.
   There are at a high level two approaches to this:

   *  Within the protocol itself, where the protocol defines the
      ancillary data required to decode each media type the protocol
      supports.
   *  A common encapsulation format such as there are advantages to
      using an existing generic media packaging format (such as CMAF
      [CMAF] or other ISOBMFF [ISOBMFF] subsets) which define a generic
      method for all media and handles ancillary decode information.

   The working group must agree on which approach should be taken to the
   packaging of media, taking into consideration the various technical
   trade offs that each approach provides.

   *  If the working group decides to describe media encapsulation as
      part of the MOQ protocol, this will require a new version of the
      MOQ protocol in order to signal the receiver that a new media
      encapsulation format may be present.
   *  If the working group decides to use a common encapsulation format,
      the mechanisms within the protocol SHOULD allow for new
      encapsulation formats to be used.  Without encapsulation agility,
      adding or changing the way media is encapsulated will also require
      a new version of the MOQ protocol, to signal the receiver that a
      new media encapsulation format may be present.

   MOQ protocol specifications will provide details on the supported
   media encapsulation(s).

Gruessing & Dawkins      Expires 7 December 2023               [Page 12]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

4.7.  Media Consumption

   Receivers SHOULD be able to as part of negotiation of a session
   Section 4.2.3 specify which media to receive, not just with respect
   to the media format and codec, but also the varient thereof such as
   resolution or bitrate.

4.8.  Relays, Caches, and other MOQ Network Elements

4.8.1.  Pull & Push

   To enable use cases where receivers may wish to address a particular
   time of media in addition to having the most recently produced media
   available, both "pull" and "push" of media SHOULD be supported, with
   consideration that producers and intermediates SHOULD also signal
   what media is available (commonly referred to as a "DVR window").
   Behaviours around cache durations for each MoQ entity should be
   defined.

4.9.  Security

4.9.1.  Authentication & Authorisation

   Whilst QUIC and conversely TLS supports the ability for mutual
   authentication through client and server presenting certificates and
   performing validation, this is infeasible in many use cases where
   provisioning of client TLS certificates is unsupported or infeasible.
   Thus, support for a primitive method of authentication between MoQ
   entities SHOULD be included to authenticate entities between one
   another, noting that implementations and deployments should determine
   which authorisation model if any is applicable.

4.9.2.  Media Encryption

   End-to-end security describes the use of encryption of the media
   stream(s) to provide confidentiality in the presence of unauthorized
   intermediates or observers and prevent or restrict ability to decrypt
   the media without authorization.  Generally, there are three aspects
   of end-to-end media security:

   *  Digital Rights Management, which refers to the authorization of
      receivers to decode a media stream.
   *  Sender-to-Receiver Media Security, which refers to the ability of
      media senders and receivers to transfer media while protected from
      authorized intermediates and observers, and

Gruessing & Dawkins      Expires 7 December 2023               [Page 13]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   *  Node-to-node Media Security, which refers to security when
      authorized intermediaries are needed to transform media into a
      form acceptable to authorized receivers.  For example, this might
      refer to a video transcoder between the media sender and receiver.

   **Note: "Node-to-node" refers to a path segment connecting two MOQ
   nodes, that makes up part of the end-to-end path between the MOQ
   sender and ultimate MOQ receiver.

   Support for encrypted media SHOULD be available in the protocol to
   support the above use cases, with key exchange and decryption
   authorisation handled externally.  The protocol SHOULD provide
   metadata for entities which process media to perform key exchange and
   decrypt.

5.  IANA Considerations

   This document makes no requests of IANA.

6.  Security Considerations

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

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [CMAF]     "Information technology — Multimedia application format
              (MPEG-A) — Part 19: Common media application format (CMAF)
              for segmented media", 2020.

Gruessing & Dawkins      Expires 7 December 2023               [Page 14]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   [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-02, 7 March 2022,
              <https://datatracker.ietf.org/doc/html/draft-cardwell-
              iccrg-bbr-congestion-control-02>.

   [I-D.draft-ietf-webtrans-overview]
              Vasiliev, V., "The WebTransport Protocol Framework", Work
              in Progress, Internet-Draft, draft-ietf-webtrans-overview-
              05, 24 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-
              webtrans-overview-05>.

   [I-D.draft-jennings-moq-quicr-arch]
              Jennings, C. F. and S. Nandakumar, "QuicR - Media Delivery
              Protocol over QUIC", Work in Progress, Internet-Draft,
              draft-jennings-moq-quicr-arch-01, 11 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-jennings-moq-
              quicr-arch-01>.

   [I-D.draft-jennings-moq-quicr-proto]
              Jennings, C. F., Nandakumar, S., and C. Huitema, "QuicR -
              Media Delivery Protocol over QUIC", Work in Progress,
              Internet-Draft, draft-jennings-moq-quicr-proto-01, 11 July
              2022, <https://datatracker.ietf.org/doc/html/draft-
              jennings-moq-quicr-proto-01>.

   [I-D.draft-kpugin-rush]
              Pugin, K., Frindell, A., Ferret, J. C., and J. Weissman,
              "RUSH - Reliable (unreliable) streaming protocol", Work in
              Progress, Internet-Draft, draft-kpugin-rush-02, 10 May
              2023, <https://datatracker.ietf.org/doc/html/draft-kpugin-
              rush-02>.

   [I-D.draft-lcurley-warp]
              Curley, L., Pugin, K., Nandakumar, S., and V. Vasiliev,
              "Warp - Live Media Transport over QUIC", Work in Progress,
              Internet-Draft, draft-lcurley-warp-04, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-lcurley-warp-
              04>.

   [IESG-sdwg]
              "Support Documents in IETF Working Groups", November 2016,
              <https://www.ietf.org/about/groups/iesg/statements/
              support-documents/>.

Gruessing & Dawkins      Expires 7 December 2023               [Page 15]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   [ISOBMFF]  "Information Technology - Coding Of Audio-Visual Objects -
              Part 12: ISO Base Media File Format", 2022.

   [MOQ-charter]
              "Media Over QUIC (moq)", September 2022,
              <https://datatracker.ietf.org/wg/moq/about/>.

   [Prog-MOQ] "Progressing MOQ", October 2022,
              <https://datatracker.ietf.org/meeting/interim-2022-moq-
              01/materials/slides-interim-2022-moq-01-sessa-moq-use-
              cases-and-requirements-individual-draft-working-group-
              draft-00>.

   [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>.

   [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>.

   [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>.

   [WebTrans-charter]
              "WebTransport (webtrans)", March 2021,
              <https://datatracker.ietf.org/wg/webtrans/about/>.

Appendix A.  Acknowledgements

   The authors would like to thank several authors of individual drafts
   that fed into the "Media Over QUIC" charter process:

   *  Kirill Pugin, Alan Frindell, Jordi Cenzano, and Jake Weissman
      ([I-D.draft-kpugin-rush],
   *  Luke Curley ([I-D.draft-lcurley-warp]), and
   *  Cullen Jennings and Suhas Nandakumar
      ([I-D.draft-jennings-moq-quicr-arch]), together with Christian
      Huitema ([I-D.draft-jennings-moq-quicr-proto]).

Gruessing & Dawkins      Expires 7 December 2023               [Page 16]
Internet-Draft       MoQ Use Cases and Requirements            June 2023

   We would also like to thank Suhas Nandakumar for his presentation,
   "Progressing MOQ" [Prog-MOQ], at the October 2022 MOQ virtual interim
   meeting.  We used his outline as a starting point for the
   Requirements section (Section 4).

   We would also like to thank Cullen Jennings for suggesting that we
   distinguish between interactive and live streaming use cases based on
   the users' perception, rather than quantitative measurements.  In
   addition we would also like to thank Lucas Pardue, Alan Frindell, and
   Bernard Aboba for their reviews of the document.

   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
   Email: james.ietf@gmail.com

   Spencer Dawkins
   Tencent America LLC
   Email: spencerdawkins.ietf@gmail.com

Gruessing & Dawkins      Expires 7 December 2023               [Page 17]