MOQT uses a pair of unidirectional streams for creating the session and exchanging control messages. Each peer opens one control stream beginning with a SETUP message. Using a pair of unidirectional streams rather than a single bidirectional stream allows either peer to send data as soon as it is able. Depending on whether 0-RTT is available on the QUIC connection, either the client or the server might be able to send stream data first.
In addition to the control streams, this specification uses bidirectional streams
to carry requests. A request stream begins with one of these seven message types:
TRACK_STATUS, SUBSCRIBE, PUBLISH, FETCH, PUBLISH_NAMESPACE,
SUBSCRIBE_NAMESPACE, and SUBSCRIBE_TRACKS. Bidirectional streams MUST NOT
begin with any other message type unless negotiated. If they do, the peer MUST
close the Session with a PROTOCOL_VIOLATION. Objects are sent on unidirectional
streams.
As such, a client can initiate a MOQT session, subscribe, and start publishing Objects all in parallel. When this is done before the handshake completes using 0-RTT, the security implications described in Section 6.3.1 apply.
Unidirectional streams containing Objects or bidirectional stream(s) beginning with a request message could arrive prior to the control streams, in which case the data SHOULD be buffered until both control streams arrive and setup is complete. If an implementation does not want to buffer or if the message type is not supported, it MAY reset such bidirectional streams before the session and control streams are established.
A control stream MUST NOT be closed at the underlying transport layer during the
session's lifetime. Doing so results in the session being closed as a
PROTOCOL_VIOLATION.
Prior to receiving the peer's SETUP message, it's unknown what extensions a peer will support. Message Parameters requiring negotiation SHOULD NOT be used prior to receiving the peer's SETUP message unless the application requires the extension or the endpoint knows the peer supports the extension. If an unsupported Message Parameter is used, the peer will be unable to process it and the session will be terminated. See Section 9.20.
6.3.1. 0-RTT
QUIC supports 0-RTT (Section 2.3 of [RFC8446]), but WebTransport over QUIC is not expected to use 0-RTT, because initializing a WebTransport session uses CONNECT, which is not a safe method. [RFC8470] describes the use of 0-RTT with HTTP in more detail. If 0-RTT is used with an existing or future version of WebTransport, the following would apply to it as well as QUIC.
MOQT Messages and Objects as defined in this draft are safe to replay in most circumstances.
-
TRACK_STATUS gets the Largest Object and Track Properties, but does not change the state of a Track or any Object in the Track.
-
SUBSCRIBE requests Objects be delivered, but does not change the Objects being requested.
-
PUBLISH initiates a Subscription. Objects can be immediately sent to the Subscriber. Processing the same Objects multiple times is idempotent, as the subscriber or relay can identify and discard duplicates based on the Group ID and Object ID.
-
SUBSCRIBE_NAMESPACE requests a list of namespaces and the establishment of new subscriptions, but does not change the available Namespaces, Tracks, or Objects contained within a Track.
-
PUBLISH_NAMESPACE requests that Subscriptions under the namespace be sent to that Publisher. If a Subscription was sent to the replaying endpoint, it would fail because the endpoint cannot complete the handshake.
Some potential side effects of replay are:
-
Publishing Objects that were previously published could cause those Objects to be distributed to active Subscriptions if the relays do not identify them as already having been published. This re-distribution could also make them available in cache again after they previously expired.
Replays could increase load on the MOQT network. For relay to client traffic, this is no worse than 0-RTT in HTTP/3, since the server is limited by the amplification factor until address validation. However, it could cause the relay to initiate new upstream Subscriptions. For a SUBSCRIBE_TRACKS request, sending that upstream could cause the Relay to receive a number of new Subscriptions on the replaying client's behalf.
Relays MAY defer initiating upstream subscriptions until the handshake is complete or reject 0-RTT entirely to mitigate resource exhaustion from replayed packets.
6.3.2. Extension Negotiation
Endpoints use the exchange of Setup messages to negotiate MOQT extensions. Extensions can define new Message types, new Parameters, new Properties, new Parameter values, or new framing for Streams and Datagrams.
The client and server MUST include all Setup Options Section 9.1 required for the negotiated MOQT version in SETUP.
Each endpoint declares the extensions it supports and provides any initial values required by those extensions as Setup Options in SETUP. Once an endpoint has both sent and received SETUP messages, it determines the set of negotiated extensions.
New versions of MOQT MUST specify which existing extensions can be used with that version. New extensions MUST specify the existing versions with which they can be used.