Internet DRAFT - draft-nandakumar-moq-transport

draft-nandakumar-moq-transport







Independent Submission                                     S. Nandakumar
Internet-Draft                                                     Cisco
Intended status: Informational                                C. Huitema
Expires: 14 September 2023                          Private Octopus Inc.
                                                                  W. Law
                                                                  Akamai
                                                           13 March 2023


    MoQ Transport (moqt) - Unified Media Delivery Protocol over QUIC
                 draft-nandakumar-moq-transport-00

Abstract

   This specification defined MoqTransport (moqt), an unified media
   delivery protocol over QUIC.  It aims at supporting multiple
   application classes with varying latency requirements including ultra
   low latency applications such as interactive communication and
   gaming.  It is based on a publish/subscribe metaphor where entities
   publish and subscribe to data that is sent through, and received
   from, relays in the cloud.  The data is delivered in the strict
   priority order.  The information subscribed to is named such that
   this forms an overlay information centric network.  The relays allow
   for efficient large scale deployments.

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 14 September 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
     1.1.  Terms and definitions
   2.  Object Model
     2.1.  Tracks
     2.2.  Objects
     2.3.  Object Groups
   3.  Concepts
     3.1.  Emission
     3.2.  Catalog
     3.3.  MoQ Session
   4.  Protocol Design
     4.1.  Control Stream and Messages
       4.1.1.  Subscribe Message
       4.1.2.  SUBSCRIBE_REPLY Message
       4.1.3.  PUBLISH REQUEST Message
       4.1.4.  PUBLISH_REPLY Message.
       4.1.5.  RELAY_REDIRECT MESSAGE
       4.1.6.  Catalog Message
     4.2.  Stream Considerations
       4.2.1.  Group Header
       4.2.2.  Object header
     4.3.  Datagram considerations
       4.3.1.  Fragment Message
   5.  Drop Priority
     5.1.  Applying drop-priorities through the QUIC stack
     5.2.  Applying drop-priorities through active scheduling
     5.3.  Tracking drops
     5.4.  Marking objects with priorities
   6.  Relays
     6.1.  Relay - Subscriber Interactions
     6.2.  Relay - Publisher Interactions
     6.3.  Relay Discovery and Failover
     6.4.  Restoring connections through relays
     6.5.  Examples
   7.  Transport Usages
     7.1.  MoQ over QUIC
     7.2.  MoQ over WebTransport
       7.2.1.  Catalog Retrieval
       7.2.2.  Subscribing to Media
       7.2.3.  Publishing Media
   8.  Normative References
   Appendix A.  TODO
   Appendix B.  Security Considerations
   Appendix C.  IANA Considerations
   Appendix D.  References
     D.1.  Normative References
     D.2.  Informative references
   Appendix E.  Acknowledgments
   Authors' Addresses

1.  Introduction

   Recently new use cases have emerged requiring higher scalability of
   delivery for interactive realtime applications and much lower latency
   for streaming applications and a combination thereof.  On one side
   are use cases such as normal web conferences wanting to distribute
   out to millions of viewers and allow viewers to instantly move to
   being a presenter.  On the other side are uses cases such as
   streaming a soccer game to millions of people including people in the
   stadium watching the game live.  Viewers watching an e-sports event
   want to be able to comment with minimal latency to ensure the
   interactivity aspects between what different viewers are seeing is
   preserved.  All of these uses cases push towards latencies that are
   in the order of 100ms over the natural latency the network causes.

   Interactive realtime applications, such as web conferencing systems,
   require ultra low latency (< 150ms) delivery.  Such applications
   create their own application specific delivery network over which
   latency requirements can be met.  Realtime transport protocols such
   as RTP over UDP provide the basic elements needed for realtime
   communication, both contribution and distribution, while leaving
   aspects such as resiliency and congestion control to be provided by
   each application.  On the other hand, media streaming applications
   are much more tolerant to latency and require highly scalable media
   distribution.  Such applications leverage existing CDN networks, used
   for optimizing web delivery, to distribute media.  Streaming
   protocols such as HLS and MPEG-DASH operates on top of HTTP and gets
   transport-level resiliency and congestion control provided by TCP.

   This specification defines MOQTransport, a publish and subscribe
   based media delivery protocol over QUIC, where the principal idea is
   entities publish unique named objects that are end-to-end encrypted
   and consume data by subscribing to the named objects.  The names used
   are scoped and authorized to the domain operating the application
   server (referred to as Origin/Provider in this specification).

   The published data carry metadata identifying relative priority,
   time-to-live and other useful metadata that's authenticated for
   components implementing Relay functions to make drop/forwarding
   decisions.  MoQTransport is designed to make it easy to implement
   relays so that fail over could happen between relays with minimal
   impact to the clients and relays can redirect a client to a different
   relay.

1.1.  Terms and definitions

   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.

   Commonly used terms in this document are described below:

   *  Provider/Origin: Entity capable of hosting media application
      session based on the MoQTransport.  It is responsible for
      authorizing the publishers/subscribers, managing the names used
      for Tracks and is scoped under domain for a specific application.
      In certain deployments, a provider is also responsible for
      establishing trust between clients and relays for delivering
      media.

   *  Emitter: Authorized entities that participate in a MoQTransport
      Session under an Provider.  Emitters are trusted with E2E
      encryption keys.  They operate on one or more uncompressed media
      inputs, compress and possible encrypt it and send over Data
      Streams.  Each such encoded and/or encrpyted stream corresponds to
      a Track within the MoQTransport.

   *  Catalog Maker: Entities performing Catalog Maker role compose or
      aggregate tracks from multiple emissions to form a new emission.
      Akin to the role of entities with the Relay role, Catalog Maker
      role entities are not trusted with the E2E keys and they perform
      publisher and subscriber roles.  Catalog Makers are allowed to
      publish tracks with a new name without changing the media content
      of the received tracks.

   *  Control Stream: QUIC Stream to exchange control message to setup
      appropriate context for media delivery and is scoped to a given
      QUIC Connection.  Functionally, Control Messages enable
      authorization of names for tracks, setting up media properties and
      starting/terminating media sessions.

   *  Data Stream: QUIC Stream or QUIC Datagram based transport for
      delivering end to end encrypted application media objects.  Such
      objects shall carry metadata (unencrypted) for Relays to make
      store/forwarding decisions along with the application payload.

2.  Object Model

   This section define various concepts that make up the object model
   enabling media delivery over QUIC.

2.1.  Tracks

   Tracks form the central concept within the MoQ Transport protocol for
   delivering media.  A Track identifies the namespace and the
   authorization scope under which MoQTransport objects Section 2.2 are
   delivered.

   A track is a transform of a uncompresss media using a specific
   encoding process, a set of parameters for that encoding, and possibly
   an encryption process.

   The MoQTransport is designed to transport tracks.

   Tracks have the following properties:

   *  Tracks MUST be owned by a single authorized MoQ Entity, such as an
      Emitter or a Catalog Maker, under a single provider domain.

   *  Tracks MUST have a single encoding configuration.

   *  Tracks MUST have a single security configuration.

   Tracks are identified by a globally unique identifier, called "Track
   ID".  Track ID MUST identify its owning provider by a standardized
   identifier, such as domain name or equivalent, then followed by the
   application context specific "Track Name", encoded a opaque string.

2.2.  Objects

   The binary content of a track is composed of a sequence of objects.
   An Object is the smallest unit that makes sense to decode and may not
   be independently decodable.  An Object MUST belong to a group
   Section 2.3

   Few examples include, for video media an object could be an H.264 P
   frame or could be just a single slice from inside the P Frame.  For
   audio media, it could be a single audio frame.  Or a catalog payload.

   Objects are not partially decodable.  The end to end encryption and
   authentication operations are performed across the whole object, thus
   rendering partial objects unusable.

   Objects MUST be uniquely identifiable within the MoQ delivery system.
   Objects carry associated header/metadata containining priority, time
   to live, and other information aiding the caching/forwarding decision
   at the Relays.  Objects MAY be optionally cached at Relays.  The
   content of the Objects are opaque to Relays and delivered on the
   strict priority order Section 5

2.3.  Object Groups

   An Object MUST belong to a group.  Groups are composition of objects
   and the objects within the group carry the necessary dependecy
   information needed to process the objects in the group.  Objects that
   carry information required to resolve dependencies are marked
   appropriately in their headers.  In cases where such information MAY
   NOT be available, the first object in the group MUST have all the
   dependency information needed to processs therest of the objects.

   A group shall provide following utilities

   *  A way for subscribers to specifiy the appropriate consumption
      point for enabling joins, rewinds and replay the objects, for
      certain media usecases.

   *  A way to specify refresh points within a group, serving as decode
      points, points of switching between qualties for audio/video media

   *  Serve as checkpoint for relays to implement appropriate congestion
      responses.

3.  Concepts

3.1.  Emission

   An Emission represents a collection of tracks sourced by an emission
   source (Emitter or Catalog Maker) and owned by an application
   Provider.  An Emitter MUST be authorized to publish objects of the
   tracks in a Emission.  An Emitter can have one or more emissions.

   Few example of Emissions include,

   *  Collection of audio and video tracks that makes up a broadcast for
      a live stream by OBS client, the Emitter, to the provider, say
      Twitch.

   *  Tracks from different participants (emitters) in a interactive
      video conference

3.2.  Catalog

   Catalog is a MOQ Object scoped to a MoQ Session Section 3.3 that
   provides information about tracks from one of more Emissions and is
   used by the subscribers for consuming tracks and for publishers to
   advertise the tracks.  The content of "Catalog" is opaque to the
   Relays and may be end to end encrypted in certain scenarios.

3.3.  MoQ Session

   A MoQ Session is a top level container under an application Provider
   that represents one or more emissions, optionally a set of
   participating relays, and set of publisher publishing content and
   subscribers that are interested in consuming the content being
   published.

4.  Protocol Design

   Media delivery is started by the publisher/subscriber setting up a
   "Control Stream" for one or more Tracks.  The control stream, which
   is based on QUIC stream, is used to configure and setup properties
   for the "Data Stream".  Track media objects is delivered over one or
   more "Data Streams" which can be unidirectional QUIC streams or over
   QUIC Datagrams.  The Control Channel can also be used to configure
   in-session parameters.

4.1.  Control Stream and Messages

   The client starts by opening a new bilateral stream, acting as the
   "control stream" for the exchange of data, carrying a series of
   control messages in both directions.

   The control stream is created for one or more tracks to be published
   or subscribed to and will remain open as long as the peers are still
   sending or receiving the media.  If either peer closes the control
   stream, the other peer will close its end of the stream and discard
   the state associated with the media transfer.

   Streams are "one way".  If a peer both sends and receive media, there
   will be different control streams for sending and receiving.

   The control channel carry series of messages, encoded as a length
   followed by a message value:

   message {
       length(16),
       value(...)
   }

   The length is encoded as a 16 bit number in big endian network order.

   Below sub-sections define various control messages defined in this
   specification.

4.1.1.  Subscribe Message

   Entities that intend to receive media will do so via subscriptions to
   one or more Tracks.

   enum subscribe_intent
   {
     immediate(0),
     catch_up(1),
     wait_up(2),
   }

   track_info {
     track_id_length(i),
     track_id(...)...,
     subscribe_intent intent
   }

   subscribe_message {
     message_type(i),
     tracks_length(i),
     track_info tracks (...),
   }

   The message type will be set to SUBSCRIBE (1). tracks identifies the
   list of tracks as defined by the track_info type.

   The track_id captures the Track ID and the intent field specifies the
   intended consumption point.

   Following options are defined for the intent

   *  immediate: Deliver any new objects it receives for a given track.

   *  catch_up: Deliver any new objects it receives and in addition send
      any previous objects it has received, beginning from the most
      recent group and matching the given track.

   *  wait_up: Wait until next group before delivering the objects.

   Subscriptions are typically long-lived transactions and they stay
   active until one of the following happens

   *  a client local policy dictates expiration of a subscription.

   *  optionally, a server policy dictates subscription expiration.

   *  the underlying transport is disconnected.

   The subscribe message is sent over the associated control stream and
   the same is closed when the subscriptions for the tracks included are
   no longer required.  This implies the termination of all associated
   data streams.

4.1.1.1.  Aggregating Subscriptions

   Subscriptions are aggregated at entities that perform Relay Function.
   Aggregating subscriptions helps reduce the number of subscriptions
   for a given track in transit and also enables efficient distribution
   of published media with minimal copies between the client and other
   relays, as well as reduce the latencies when there are multiple
   subscribers for a given track behind a Relay or the provider.

4.1.2.  SUBSCRIBE_REPLY Message

   A subscribe_reply provides results of the subscription and is sent on
   the control stream over which the subscribe control message was
   received.

   enum response
   {
     ok(0),
     expired(1),
     fail(2)
   }

   track_response {
     Response response,
     track_id_length(i),
     track_id(...)...,
     [ Reason Phrase Length (i) ],
     [ Reason Phrase (...) ],
     [ media_id(i) ]
   }

   subscribe_reply
   {
     message_type(i),
     track_response tracks(...)
   }

   The message type will be set to SUBSCRIBE_REPLY (2). tracks capture
   the result of subscription per track included in the subscribe
   message.

   For each track, the track_response provides result of subscription in
   the response field, where a response of ok indicates successful
   subscription.  For failed or expired responses, the "Reason Phrase"
   shall be populated with appropriate reason code.

   The media_id for a given track is populated for a successful
   subscription and represents an handle to the subscription to be
   provided by the peer over the data streams(s).  Given that the media
   corresponding to a track can potentially arrive over multiple data
   streams, the media_id provides the necessary mapping between the
   control stream and the corresponding data streams.  It also serves as
   compression identifier for containing the size of object headers
   instead of carrying complete track identifier information in every
   object message.

   While the subscription is active for a given name, the Relay(s) must
   send objects for tracks it receives to all the matching subscribers.
   Optionally, a client can refresh its subscriptions at any point by
   sending a new subscribe_message.

4.1.3.  PUBLISH REQUEST Message

   The publish_request message provides one or more tracks that the
   publisher intends to publish data.

   track_info {
     track_id_length(i),
     track_id(...)...,
     media_id(i),
   }

   publish_request {
     message_type(i),
     track_info tracks(...),
   }

   The message type will be set to PUBLISH_REQUEST (3). tracks
   identifies the list of tracks.  The media_id represents an handle to
   the track to be used over the data streams(s).  Given that media
   corresponding to the track can potentially be sent over multiple data
   streams, the media_id provides the necessary mapping between the
   control stream and the associated data streams. media_id also serves
   as compression identifier for containing the size of object headers
   instead of carrying full formed Track Id in every object.

   The publish_request message is sent on its own control stream and
   akin to subscribes, the control stream's lifecycle bounds the media
   transfer state.  Terminating the control stream implies closing of
   all the associated data streams for the tracks included in the
   request.

4.1.4.  PUBLISH_REPLY Message.

   publish_reply provides the result of request to publish on the
   track(s) in the publish_request.  The publish_reply control message
   is sent over the same control stream the request was received on.

   publish_reply {
     message_type(i),
     track_response tracks(...),
   }

   The message_type is set to PUBLISH_REPLY (4).

   tracks capture the result of publish request per track included in
   the publish_request message.  The semantics of track_response is same
   as defined in Section 4.1.2 except the media_id is optionally
   populated in the case where the media_id in the request cannot be
   used.

4.1.5.  RELAY_REDIRECT MESSAGE

   relay_redirect control message provides an explicit signal to
   indicate relay failover scenarios.  This message is sent on all the
   control streams that would be impacted by reduced operations of the
   Relay.

   relay_redirect
   {
     message_type(i),
     relay_address_length(i),
     relay_address(...)...
   }

   The message_type is set to RELAY_REDIRECT (5). relay_address
   identifies the address of the relay to setup the new subscriptions or
   publishes to.

4.1.6.  Catalog Message

   Catalog message provides information on tracks for a given MoQ
   Session.

   catalog {
     message_type(i),
     catalog_length(i),
     data(...)...
   }

   The message_type is set to CATALOG (6). data is container specific
   encoding of catalog information.

4.2.  Stream Considerations

   Certain applications can choose to send each group in their own
   unidirectional QUIC stream.  In such cases, stream will start with a
   "group header" message specifying the media ID and the group ID,
   followed for each object in the group by an "object header"
   specifying the object ID and the object length and then the content
   of the objects (as depicted below)

   +--------+------------+-------+------------+-------+------
   | Group  | Object     | Bytes | Object     | Bytes |
   | header | header (0) |  (0)  | header (1) |  (1)  | ...
   +--------+------------+-------+------------+-------+------

   The first object in the stream is object number 0, followed by 1,
   etc.  Arrival of objects out of order will be treated as a protocol
   error.

   TODO: this strict "in order" arrival is not verified if there is one
   stream per drop-priority level.  Add text to enable that.

   Alternatively, certain applications can choose to send each object in
   its own unidirectional QUIC stream.  In such cases, each stream will
   start with a "group header" message specifying the media ID and the
   group ID, followed by a single "object header" and then the content
   of the objects (as depicted below).

   +--------+------------+-------+
   | Group  | Object     | Bytes |
   | header | header (n) |  (n)  |
   +--------+------------+-------+

   The MOQTransport doesn't enforce a rule to follow for the
   applications, but instead aims to provide tools for the applications
   to make the choices appropriate for their use-cases.

4.2.1.  Group Header

   The group header message is encoded as:

   group_header {
     message_type(i),
     media_id(i),
     group_id(i)
   }

   The message type is set to GROUP_HEADER, 11. media_id MUST correspond
   to the one that was setup as part of publish_request control message
   exchange Section 4.1.3. group_id always starts at 0 and increases
   sequentially at the original media publisher.

4.2.2.  Object header

   Each object in the stream is encoded as an Object header, followed by
   the content of the object.  The Object header is encoded as:

   object_header {
     message_type(i),
     object_id(i),
     [nb_objects_previous_group(i),]
     flags[8],
     object_length(i)
   }

   The message type is set to OBJECT_HEADER, 12. object_id is identified
   by a sequentially increasing integer, starting at 0.

   The nb_objects_previous_group is present if and only if this is the
   first fragment of the first object in a group, i.e., object_id and
   offset are both zero.  The number indicates how many objects were
   sent in the previous group.  It enables the receiver to check whether
   all these objects have been received.

   The flags field is used to maintain low latency by selectively
   dropping objects in case of congestion.  The flags field is encoded
   as:

   {
       maybe_dropped(1),
       drop_priority(7)
   }

4.3.  Datagram considerations

   MoQ objects can be transmitted as QUIC datagrams, if the datagram
   transmission option has been validated during the subscribe or
   publish transaction.  Such a option is chosen for non-relaible media
   delivery scenarios.

   When sent as datagrams, the object is split into a set of fragments.
   Each fragment is sent as a separate datagram.  The fragment header
   contains enough information to enable reassembly.  If the complete
   set of fragments is not received in a reasonable time, the whole
   object shall be considered lost.

4.3.1.  Fragment Message

   In the datagram variants, instead of sending a series of whole
   objects on a stream, objects are sent as series of fragments, using
   the Fragment message:

   fragment {
     message_type(i),
     [ media_id(i) ],
     [ group_id(i) ],
     [ object_id(i) ],
     fragment_offset(i),
     object_length(i),
     fragment_length(i),
     data(...)
   }

   The message type will be set to FRAGMENT (13).  The optional fields
   media_id, group_id and object_id are provided in the cases where they
   cannot be obtained from the context where the fragment message is
   published.  For typical cases, the group_header and the object_header
   messages preceed the series of fragment messages and thus provide the
   necessary context to tie the data to the object.

   The fragment_offset value indicates where the fragment data starts in
   the object designated by group_id and object_id.  Successive messages
   are sent in order, which means one of the following three conditions
   must be verified:

   *  The group id and object id match the group id and object id of the
      previous fragment, the previous fragment is not a last fragment,
      and the offset matches the previous offset plus the previous
      length.

   *  The group id matches the group id of the previous message, the
      object id is equal to the object id of the previous fragment plus
      1, the offset is 0, and the previous message is a last fragment.

   *  The group id matches the group id of the previous message plus 1,
      the object id is 0, the offset is 0, and the previous message is a
      last fragment.

   The nb_objects_previous_group is present if and only if this is the
   first fragment of the first object in a group, i.e., object_id and
   offset are both zero.  The number indicates how many objects were
   sent in the previous groups.  It enables the receiver to check
   whether all these objects have been received.

   The flags field is used to maintain low latency by selectively
   dropping objects in case of congestion.  The value must be the same
   for all fragments belonging to the same object.

   The flags field is encoded as:

   {
       maybe_dropped(1),
       drop_priority(7)
   }

   The high order bit maybe_dropped indicates whether the object can be
   dropped.  The drop_priority allows nodes to selectively drop objects.
   Objects with the highest priority as dropped first.

   When an object is dropped, the relays will send a placeholder, i.e.,
   a single fragment message in which:

   *  offset_and_fin indicates offset=0 and fin=1

   *  the length is set to zero

   *  the flags field is set to the all-one version 0xff.

   Sending a placeholder allows node to differentiate between a
   temporary packet loss, which will be soon corrected, and a deliberate
   object drop.

5.  Drop Priority

   In case of congestion, the MoQ nodes may have to drop some traffic in
   order to avoid building large queues.  The drop algorithm must
   respect the relative importance of objects within a track, as well as
   the relative importance of tracks within an MoQ connection.  Relays
   base their decisions on two properties of objects:

   *  a "droppable" flag, which indicates whether the application would
      rather see the object queued (droppable=False) or dropped
      (droppable=True) in case of congestion.

   *  a "drop-priority" value, which indicates the relative priority of
      this object versus other objects in the track or other tracks in
      the connection.

   Higher values of the drop-priority field indicate higher drop
   priorities: objects mark with priority 0 would be the last to be
   dropped, objects marked with priority 3 would be dropped before
   dropping objects with priority 2, etc.  Nodes support up to 8 drop-
   priority levels, numbered 0 to 7.

   Nodes may use drop-priorities in two ways: either by delegating to
   the QUIC stack, or by monitoring the state of congestion and
   performing their own scheduling.

5.1.  Applying drop-priorities through the QUIC stack

   Many QUIC stack allow application to associate a priority with a
   stream.  The MoQ transports can use that feature to delegate priority
   enforcement to the QUIC stack.  The actual delegation depends on the
   transport choice.

   If the MoQ transport uses the strategy where each object is
   transmitted on a separate unidirectional QUIC stream, then that
   stream should be marked with the object's priority.  The QUIC API
   should be set to request FIFO ordering of streams within a priority
   layer.

   If all the objects of a given group, say GOP, within a track are sent
   in a single unidirectional QUIC stream.  This strategy can be
   modified to be priority aware.  In a priority aware strategy, there
   will be one unidirectional stream per group and per priority level,
   and the priority of the unidirectional stream will match that level.

   In both cases, if congestion happens, objects marked as "droppable"
   will have be dropped by resetting the corresponding unidirectional
   streams.  This decision will happen separately for each track,
   typically at the end of a group.  At that point, the decision depends
   on whether the content of the unidirectional streams have been sent
   or not:

   *  if all objects have been sent, the stream can be closed normally.

   *  if some objects have not been sent, or not acknowledged, the
      stream shall be reset, causing the corresponding objects to be
      dropped.

   These policies will normally ensure that for any congestion state,
   only the most urgent objects are sent.

5.2.  Applying drop-priorities through active scheduling

   Some transport strategies prevent delegation of priority enforcement
   to the QUIC stack.  For example, if the policy is to use a single
   QUIC stream or a single stream carrying objects of different
   priorities.  In such cases, nodes react to congestion by scheduling
   some objects for transmission and explicitly dropping other objects.

   Node should schedule objects as follow:

   *  if congestion is noticed, the node will delay or drop first the
      numerically higher priority level.  The node will drop all objects
      marked at that priority, from the first dropped object to the end
      of the group.

   *  if congestion persists despite dropping or delaying the "bottom"
      level, the node will start dropping the next level, and continue
      doing so until the end of the group.

   *  if congestion eases, the node will increase the delay or drop
      level.

   While the "drop level" is computed per connection, specific actions
   will have to be performed at the "track" level:

   *  for a given track, the node remembers the highest priority level
      for which objects were dropped in the current group.  That level
      will be maintained for that track until the end of the group.

   *  at the beginning of a group, the priority level is set to the
      currently computed value for the connection.

5.3.  Tracking drops

   For management purposes, it is important to indicate which objects
   have been dropped, as in "there was supposed to be here an object
   number X or priority P but it has been dropped."  In the scheduling
   approach, this can be achieved by inserting a small placeholder for
   the missing object.  In the delegating approach, we need another
   solution.  One possibility would be to send a "previous group
   summary" at the beginning of each group, stating the expected content
   of the previous group.

5.4.  Marking objects with priorities

   The publishers mark objects with sequence numbers within groups and
   with drop and priority values according to the need of the
   application.  This marks must be consistent with the encoding
   requirements, making sure that:

   *  objects can only have encoding dependencies on other objects in
      the same group,

   *  objects can only have encoding dependencies on other objects with
      equal or or numerically lower priority levels.

   With these constraints, applications have broad latitude to pick
   priorities in order to match the desired user experience.  When using
   scalable video codecs, this could mean for example chosing between
   "frame rate first" or "definition first" priorities, or some
   compromise.

6.  Relays

   The Relays play an important role for enabling low latency media
   delivery within the MoQ architecture.  This specification allows for
   a delivery protocol based on a publish/subscribe metaphor where some
   endpoints, called publishers, publish media objects and some
   endpoints, called subscribers, consume those media objects.  Some
   relays can leverage this publish/subscribe metaphor to form an
   overlay delivery network similar/in-parallel to what CDN provides
   today.  While this type of overlay is expected to be a major
   application of relays, other types of relays can also be defined to
   offer various types of services.

   Objects are received by "subscribing" to it.  Objects are identified
   such that it is unique for the relay/delivery network.

   Relays provide several benefits including

   *  Scalability - Relays provide the fan-out necessary to scale up
      streams to production levels (millions) of concurrent subscribers.

   *  Reliability - relays can improve the overall reliability of the
      delivery system by providing alternate paths for routing content.

   *  Performance - Relays are usually positioned as close to the edge
      of a network as possible and are well-connected to each other and
      to the Origin via high capacity managed networks.  This topography
      minimizes the RTT over the unmanaged last mile to the end-user,
      improving the latency and throughput compared to the client
      connecting directly to the origin.'

   *  Security - Relays act to shield the origin from DDOS and other
      malicious attacks.

6.1.  Relay - Subscriber Interactions

   Subscribers interact with the "Relays" by sending a "subscribe"
   Section 4.1.1 command for the tracks of interest.

   Relays MUST be willing to act on behalf of the subscriptions before
   they can forward the media, which implies that the subscriptions MUST
   to be authorized and it is done as follows:

   1.  Provider serving the tracks MUST be authorized.  Track IDs
       provide the necessary information to identify the Origin/
       Provider.

   2.  Subscriptions MUST be authorized.  This is typically done by
       either subscriptions carrying enough authorization information or
       subscriptions being forwarded to the Origin for obtaining
       authorization.  The mechanics of either of these approaches are
       out of scope for this specification.

   In all the scenarios, the end-point client making the subscribe
   request is notified of the result of the subscription.

6.2.  Relay - Publisher Interactions

   Publishers MAY be configured to publish the objects to a relays based
   on the application configuration and topology.  Publishing set of
   tracks through the relay starts with a "publish_request" transaction
   that describes the track identifiers.  That transaction will have to
   be authorized by the Origin, using mechanisms similar to authorizing
   subscriptions.

   As specified with subscriber interactions, Relays MUST be authorized
   to serve the provider and the publish_request MUST be authorized
   before the Relays are willing to forward the published data for the
   tracks.

   Relays makes use of priority order and other metadata properties from
   the published objects to make forward or drop decisions when reacting
   to congestion as indicated by the underlying QUIC stack.  The same
   can be used to make caching decisions.

6.3.  Relay Discovery and Failover

   Relays are discovered via application defined ways that are out of
   scope of this document.  A Relay that wants to shutdown can send a
   message to the client with the address of new relay.  Client moves to
   the new relay with all of its Subscriptions and then Client
   unsubscribes from old relay and closes connection to it.

6.4.  Restoring connections through relays

   The transmission of a track can be interrupted by various events,
   such as loss of connectivity between subscriber and relay.  Once
   connectivity is restored, the subscriber will want to resume
   reception, ideally with as few visible gaps in the transmission as
   possible, and certainly without having to "replay" media that was
   already presented.

   There is no guarantee that the restored connectivity will have the
   same characteristics as the previous instance.  The throughput might
   be lower, forcing the subscriber to select a media track with lower
   definition.  The network addresses might be different, with the
   subscriber connecting to a different relay.

6.5.  Examples

   Let’s consider the example as show in the picture below, where a
   large number of subscribers are interested in media streams from the
   publisher Alice.  In this scenario, the publisher Alice has a live
   broadcast on channel8 with video streams at 3 different quality (HD,
   4K and SD)

   More specifically,

   1.  Subscriber - S1 is interested in the just the low quality version
       of the media, and asks for the all the media groups/objects under
       the specific representation for "sd" quality.

   2.  Subscriber - S2 is fine with receiving highest quality video
       streams published by Alice, hence asks for the all the media
       objects under these representations 4k.

   3.  Rest of the Subscribers (say Sn,...) are fine with getting just
       the Hi-def and low quality streams of the video from Alice, and
       asks for the representations "sd" and "hd" qualities.

   The Relay must forward all these subscription requests to the ingest
   server in order to receive the content.

   Note: The notation for identifying the resources for subscription are
   for illustration purposes only.

                        sub: acme.tv/brodcasts/channel8/alice/sd
                                                       .─────.
                                               ┌──────(  S1   )
                                               │       `─────'
                                               │
      sub: acme.tv/broadcasts/channel8/alice/4 |
      sub: acme.tv/brodcasts/channel8/alice/sd |
      sub: acme.tv/brodcasts/channel8/alice/hd |
          │                                    | sub: acme.tv/
   ┌──────────────┐          ┌──────────────┐  │      broadcasts/
   │              │          │              │  |      channel8/
   |              |          |              |  |      alice/4k
   │   Ingest     │ ◀────────| Relay-Edge   │◀─┘   .─────.
   │              │          │              │◀────(  S2   )
   └──────▲───────           └────────────── ◀──┐  `─────'
          │                                     │     ◉
          │                                     │     ◉
       .─────.                                  │     ◉
      ( Alice )                                 │
       `─────'                                  │  .─────.
   pub: acme.tv/broadcasts/channel8/alice/hd    └─(  SN   )
   pub: acme.tv/broadcasts/channel8/alice/sd       `─────'
   pub: acme.tv/broadcasts/channel8/alice/4k

                           sub: acme.tv/brodcasts/channel8/alice/sd
                           sub: acme.tv/brodcasts/channel8/alice/hd

   The relay does not intercept and parse the CATALOG messages,
   therefore it does not know the entireity of the content being
   produced by Alice.  It simply aggregates and forwards all
   subscription requests that it receives.

   Similarly, below example shows an Interactive media session

     pub: acme.com/meetings/m123/bob/video
     pub: acme.com/meetings/m123/bob/audio

         .─────.     sub:acme.com/meetings/m123/alice/audio
        (  Bob  )
         `─────'     sub:acme.com/meetings/m123/alice/video
            │
            │        sub:acme.com/meetings/m123/bob/audio
            │
            │        sub:acme.com/meetings/m123/bob/video
            │
     ┌──────▼───────┐           ┌──────────────┐
     │              │           │              │
     │    Relay     │ ◀─────────┤    Relay     │◀───┐
     │              │           │              │    |
     └──────▲───────┘           └──────────────┘    |
            │                                       │
            │                                       │
            │                                       │
            │                                       │
         .─────.                                    │
        ( Alice )                                   │
         `─────'                                    │     .─────.
                                                    └────(  S1   )
        pub: acme.com/meetings/m123/alice/video           `─────'
        pub: acme.com/meetings/m123/alice/audio
                               sub:acme.com/meetings/m123/alice/audio
                               sub:acme.com/meetings/m123/alice/video
                               sub:acme.com/meetings/m123/bob/audio
                               sub:acme.com/meetings/m123/bob/video

   The above picture shows as sample media delivery, where a tree
   topography is formed with multiple relays in the network.  The
   example has 4 participants with Alice and Bob being the publishers
   and S1 being the subscribers.  Both Alice and Bob are capable of
   publishing audio and video identified by their appropriate names.  S1
   subscribes to all the streams being published.  The edge Relay
   forwards the unique subscriptions to the downstream Relays as needed,
   to setup the delivery network.

7.  Transport Usages

   Following subsections define usages of the MoQTransport over
   WebTransport and over raw QUIC.

7.1.  MoQ over QUIC

   MoQ can run directly over QUIC.  In that case, the following apply:

   *  Connection setup corresponds to the establishment of a QUIC
      connection, in which the ALPN value indicates use of MoQ.  For
      versions implementing this draft, the ALPN value is set to "moq-
      n00".

   *  Bilateral and unilateral streams are mapped directly to equivalent
      QUIC streams

   *  Datagrams, when used, are mapped directly to QUIC datagram frames.

7.2.  MoQ over WebTransport

   MoQ can benefit from an infrastructure designed for HTTP3 by running
   over WebTransport.

   WebTransport provides protocol framework that enables clients
   constrained by the Web security model to communicate with a remote
   server using a secure multiplexed transport.  WebTransport protocol
   also provides support for unidirectional streams, bidirectional
   streams and datagrams, all multiplexed within the same HTTP/3
   connection.

   Clients (publishers and subscribers) setup WebTransport Session via
   HTTP CONNECT request for the application provided MoQSession and
   provide the necessary authentication information (in the form of
   authentication token).  The ":protocol" value indicates use of MoQ.
   For versions implementing this draft, the :protocol value is set to
   "moq-n00".

   In case of any errors, the session is terminated and reported to the
   application.

   Bilateral and unilateral streams are opened and used through the
   WebTransport APIs.

7.2.1.  Catalog Retrieval

   On a successful connection setup, subscribers proceed by retrieving
   the catalog (if not already retrieved), subscribing to the tracks of
   their interest and consuming the data published as detailed below.

   Catalog provides the details of tracks such as Track IDs and
   corresponding configuration details (audio/video codec detail,
   gamestate encoding details, for example).

   Catalogs are identified as a special track, with its track name as
   "catalog".  Catalog objects are retrieved by subscribing to its
   TrackID over its own control channel and the TrackID is formed as
   shown below

   Catalog TrackID :=<provider-domain>/<moq-session-id>/catalog

   Ex: streaming.com/emission123/catalog

   A successfull subscription will lead to one or more catalog objects
   being published on a single unidirectional data stream.  Successfull
   subscriptions implies authorizaiton for subscribing to the tracks in
   the catalog.

   Unsuccessful subscriptions MUST result in closure of the WebTransport
   session, followed by reporting the error obtained to the application.

   Catalog Objects obtained MUST parse successfully, otherwise MUST be
   treated as error, thus resulting the closure of the WebTransport
   session.

7.2.2.  Subscribing to Media

   Once a catalog is successfully parsed, subscribers proceed to
   subscribe to the tracks listed in the catalog.  Applications can
   choose to use the same WebTransport session or multiple of them to
   perform the track subscriptions based on the application
   requirements.

   Also, It is typical for certain applications to group set of tracks
   in to a single prioritization relationship and transmit them over a
   single WebTransport Session.

   Tracks subscription is done by sending subscribe message as definedin
   Section 4.1.1

   On successful subscription, subscribers should be ready to consume
   media on one or more Data Streams as identified by their media_ids.

   Failure to subscribe MUST result on closure of the control stream
   associated with the track whose subscription failed and the error
   MUST be reported to the application.

7.2.3.  Publishing Media

   On successful setup of the WebTransport session, publishers send
   publish_request message listing the tracks they intend to publish
   data on.  Publisher MUST be authorized to publish on the tracks and
   Relays MUST be willing to participate in the media delivery.

   A sucessfull publish_reply allows publishers to publish on the tracks
   advertised.

   Publishing objects on the tracks follow the procedures defined in
   Section 4.2 and Section 4.3.

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

Appendix A.  TODO

   1.  Add authorization details for the protocol messages.

Appendix B.  Security Considerations

   This section needs more work

Appendix C.  IANA Considerations

   TODO: fill this section.  Register ALPN.  Register WebTransport
   protocol.  Open new registry for MoQ message types.  Possibly, open
   registry for MoQ errors.

Appendix D.  References

D.1.  Normative References

   [RFC XXX] Nandakumar, S "MoQ Base Protocol" Work in progress

D.2.  Informative references

   [RFC8126] Cotton, M., Leiba, B., and T.  Narten, "Guidelines for
   Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126,
   DOI 10.17487/RFC8126, June 2017, %gt;https://www.rfc-editor.org/info/
   rfc8126>.

   [QUIC] Iyengar, J., Ed. and M.  Thomson, Ed., "QUIC: A UDP-Based
   Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000,
   May 2021, %gt;https://www.rfc-editor.org/rfc/rfc9000>.

   [WebTransport] Frindell, A., Kinnear, E., and V.  Vasiliev,
   "WebTransport over HTTP/3", Work in Progress, Internet-Draft, draft-
   ietf-webtrans-http3-04, 24 January 2023,

   >https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-04>.

Appendix E.  Acknowledgments

   Cullen Jennings, the IETF MoQ mailing lists and discussion groups.

Authors' Addresses

   Suhas Nandakumar
   Cisco
   Email: snandaku@cisco.com


   Christian Huitema
   Private Octopus Inc.
   Email: huitema@huitema.net


   Will Law
   Akamai
   Email: wilaw@akamai.com