Does the Client have to speak first?

[ianswett]

When establishing a session, particularly over QUIC directly without 0-RTT, the Server can speak first. The current text indicates the client always speaks first, but I'm not sure if that's a requirement or just a convenient mental model?

[afrind]

I thought #242 was tracking something like this, but it was closed by #499, possibly inadvertently.

[yekuiwang]

The definitions of Client and Server in the MOQT draft are as follows:

Client: The party initiating a Transport Session.
Server: The party accepting an incoming Transport Session.

Thus, in MOQT draft isn't by definition that the Client speaks first when establishing a session, as what speaks first is defined as the Client?

[vasilvv]

Those are not necessarily the same. For instance, in TLS (1.3), the client initiates the session, but the server can send application data first (since it's the first party that has data keys).

[yekuiwang]

Well, in the TLS spec there are no such (weird IMHO) definitions of "client" and "server" as in the MOQT draft. Actually, in TLS there are no definitions of "client" and "server", which imply that these two words are used in their plain meanings therein.

[afrind]

I think this issue is about whether the control stream should be a client-initiated bidirectional stream, as in the current draft, or a pair of unidirectional streams, as in HTTP/3. Decoupling the streams means that the server can send its SERVER_SETUP negotiation parameters (and non-extended control messages) as soon as the TLS handshake is complete from its side, even if it has not received CLIENT_SETUP.

It does mandate a certain kind of extension negotiation, which is essentially declarative (I support X, Y and Z) and has deterministic algorithms for each peer to run based on what it sent and what it received. The current design allows the server to wait to see the client setup before indicating what extensions it wants to use.

[LPardue]

https://datatracker.ietf.org/doc/html/rfc8446#section-1.1

client: The endpoint initiating the TLS connection.

server: The endpoint that did not initiate the TLS connection.

[yekuiwang]

https://datatracker.ietf.org/doc/html/rfc8446#section-1.1

client: The endpoint initiating the TLS connection.

server: The endpoint that did not initiate the TLS connection.

Oh, thanks! I looked at https://datatracker.ietf.org/doc/html/rfc5246.

[kixelated]

I think with WebTransport, the server should speak first? Meanwhile with QUIC 1-RTT then yeah the client should speak first.

Another option is similar to HTTP/3 SETTINGS, where both sides would open a control stream simultaneously. It would mean no need to shard request ID by client/server, but I guess that might go away anyway.

[afrind]

In QUIC 1-RTT the server can send in 0.5-RTT, I think.

[kixelated]

In QUIC 1-RTT the server can send in 0.5-RTT, I think.

I think you're right?

Either way with ALPN, the server should probably speak first because it knows the selected version first.