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 :=//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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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