Proposal: Control and data streams

[kixelated]

Current

The client creates a bidirectional stream and sends the SETUP message. The server replies with its own SETUP message on the same stream. Afterwards, both endpoints can create any number of unidirectional streams containing any non-SETUP messages.

Problems

• Multiple OBJECTs per stream with different priorities #105 Messages with different priorities should not be mixed in the same stream, which means control messages should never be mixed with data messages.
• Messages during handshake #136 Messages can't be sent or have to be buffered until the receipt of the SETUP message.
• Control message ordering #137 Control messages over separate streams arrive in an unknown order.

Proposed

• The client creates a single bidirectional control stream. The control stream MUST start with a SETUP message, followed by any number of control messages (ex. SUBSCRIBE).
• The sender creates unidirectional data streams. The data streams MUST only contain OBJECT messages.

Pros:

• Partially fixes Multiple OBJECTs per stream with different priorities #105. Control messages are no longer intermingled with with data messages, and the control stream MUST always be the highest priority.
• Fixes Messages during handshake #136. Endpoints no longer have to buffer messages, as QUIC will automatically make sure SETUP arrives before any other control messages. Data streams MUST NOT be created until receipt of SETUP.
• Fixes Control message ordering #137. Control messages arrive in a specified, deterministic order.

Cons:

• Head-of-line blocking between control messages, which sometimes may not be desired.

[afrind]

The sender creates unidirectional data streams

While I was reading the requirements draft, I found some use cases mentioning bidirectionality. Is it expected/supported that there can be data flowing in both directions (eg: a p2p call)?

[kixelated]

The sender creates unidirectional data streams

While I was reading the requirements draft, I found some use cases mentioning bidirectionality. Is it expected/supported that there can be data flowing in both directions (eg: a p2p call)?

Yeah, my intent is that there's a "sender" and a "receiver" per track. The ROLE param in the SETUP message indicates if an endpoint (client/server) intends to send tracks, receive tracks, or both.

In the bidirectional case, both endpoints would say ROLE=BOTH. Then they could independently PUBLISH or SUBSCRIBE to tracks.

Alternatively, we could say that tracks may be bidirectional... but I don't think that makes any sense.

[wilaw]

We can simply say that data objects MUST NOT be sent over control streams, and remove any reference to whether data streams should be unidirectional or bidirectional. It doesn't matter and we can leave it to the end-points discretion.

[suhasHere]

The proposal above aligns pretty well with the idea in #96 , more specifically this section

I like the separation of control stream and data streams, the latter being unidirectional streams.

[fluffy]

I like the proposal for this.

I view the HOL blocking of control messages a feature not a bug. More specifically, I think that some of our messages need to be delivered in order. Specifically if a client is trying to stop and high res video subscription and start a low res subscription, it would be good to ensure that the subscribe to the low res track does not happen until after the end the end subscription to the high res track has happened. Sending the un-subscribe then subscribe on one quic stream allows these to be sent and same time to server ( we don't need a round trip between them ) but still be delivered in order.

I think it needs to be clear that multiple control messages can be outstanding at once. For example can send multiple subscribes before getting the response to the first subscribe.

[suhasHere]

The proposal above aligns pretty well with the idea in #96 , more specifically this section

I like the separation of control stream and data streams, the latter being unidirectional streams.

I would like to write up a PR based on the above ( basically resurrecting #96) that pertains to the control channels.

[VMatrix1900]

I like the idea of seperation of control stream and data stream.

[ianswett]

WG is ok with a single stream, with no critical use cases for multiple.

A single stream makes it easier to change bitrates 'atomically'.

People don't want Object messages allowed on the same stream as control messages.

People noted that this means the only bidi stream is used for the control stream in practice, and all unidirectional streams are used for objects, but people don't want to bake that into the spec.