Client and/or server initiated handshake

[kixelated]

Splitting discussion in #212 into a separate issue.

The current draft states that the client initiates the session via a CLIENT_SETUP message and then server replies with a SERVER_SETUP. The client sends a list of supported versions and its role, while the server chooses a version and reaffirms the role. This is done via a bidirectional stream opened by the client.

However, depending on the underlying transport, the client won't always be the first endpoint allowed to send a flight, so this incurs a half-RTT of latency:

• WebTransport: Client is allowed to send first (before CONNECT response), but most implementations will let the server send first (after 2xx CONNECT response)
• QUIC: Client sends first with 0-RTT, while the server sends first with 1-RTT (most common).

[kixelated]

I think we should emulate HTTP/3 SETTINGS. That means endpoints can send the SETUP in parallel.

SETUP
supported_versions: [ 1, 3, 4, ... ]
supported_roles: "publisher" | "subscriber" | "both" 

As far as I understand, this doesn't support from version negotiation attacks, since it's over an established QUIC connection.

Alternatively, QUIC could use the ALPN to transmit this SETUP information. Unfortunately no such mechanism exists for WebTransport (yet).

[fluffy]

so I am working on the assumption the vast majority of connections, measured by numbers of connection, will be 0-RTT, not 1. I was assuming this because what the MoQ client sends in that would be "SAFE" in the HTTP replay sen. I realize other on this thread have thought about this lots. Any particular reason 0-RTT would not be common in MoQ ?

[kixelated]

so I am working on the assumption the vast majority of connections, measured by numbers of connection, will be 0-RTT, not 1. I was assuming this because what the MoQ client sends in that would be "SAFE" in the HTTP replay sen. I realize other on this thread have thought about this lots. Any particular reason 0-RTT would not be common in MoQ ?

Well, WebTransport does not support 0-RTT. Even if it did, MoQ would be subject to a replay attacks depending on how authentication is performed.

[vasilvv]

Note that in case of WebTransport, the question of 0-RTT is orthogonal to the question of which side speaks first (it just lets you skip a round trip that occurs before the WebTransport session is established).

[ianswett]

We now have a clearer definition of Role, so the 'server' from the perspective of a QUIC connection could initiate a MoQ session with a CLIENT_SETUP message I believe?

I'm going to park this for now unless this is currently causing problems. Currently the control stream is bidi and unidirectional streams are for Objects, so this would be a non-trivial change.

[afrind]

the 'server' from the perspective of a QUIC connection could initiate a MoQ session with a CLIENT_SETUP message

Did we intend to allow this?

[martinduke]

@kixelated: this will require a new version negotiation design, because SERVER_SETUP currently depends on CLIENT_SETUP. So you can progress this issue by (1) closing it, (2) starting a discussion a new design, or (3) filing a PR.

[martinduke]

Reassigning to @ianswett, as the author of the ALPN PR.