don't require the client to send the WEBTRANSPORT_MAX_SESSIONS setting

[marten-seemann]

There's no need for the client to send the WEBTRANSPORT_MAX_SESSIONS setting. The server doesn't need to know that a client supports WebTransport until it receives the first Extended CONNECT request that attempts to establish a WebTransport session.

Similar to #140, this requirement technically requires servers to buffer incoming requests until they have received the SETTINGS frame, if they want to check that the client actually sent the setting.

[vasilvv]

It's a version negotiation mechanism. You can't figure out what version of WebTransport is being used until you see what version the client supports, and what version the server supports, since the version used is max(client versions ∩ server versions).

Similar to https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/140, this requirement technically requires servers to buffer incoming requests until they have received the SETTINGS frame, if they want to check that the client actually sent the setting.

Correct.

[ekinnear]

For extra context, see also #125, #84, and especially #130 where it was proposed that the client not send the setting.

[ekinnear]

If we can get to a place (and not run into issues with some of the other settings that get exchanged) that means we don't need to add any roundtrips before we can get going with WebTransport application data, I think we'll be very happy, so I would generally support anything that gets us closer to that goal.

[vasilvv]

None of this causes any additional latency unless there is packet loss, and since you'd usually bundle your settings with ServerHello (for the server) or the CONNECT request (for the client), that should normally not matter for the client either.

[marten-seemann]

None of this causes any additional latency unless there is packet loss, and since you'd usually bundle your settings with ServerHello (for the server) or the CONNECT request (for the client), that should normally not matter for the client either.

I'm not worried about roundtrips here. The server sends SETTINGS in 0.5-RTT data, so they should be available as soon as the handshake completes. What I'm worried about are resource exhaustion attacks if the server has to buffer requests until it receives the client's SETTINGS. A malicious client could withhold sending of this frame for an arbitrarily long time.

It's a version negotiation mechanism. You can't figure out what version of WebTransport is being used until you see what version the client supports, and what version the server supports, since the version used is max(client versions ∩ server versions).

In my HTTP/3 implementation, every HTTP request is handled immediately. There's no buffering of requests. I believe this is a reasonable design for defending against a variety of resource exhaustion attacks. WebTransport version negotiation seems to be the only occurrence that breaks this design. Note that this however is only needed if you want to support multiple draft versions. If you only offer a single WebTransport draft version, you know that the client will have to use that version, as the client MUST wait for the SETTINGS frame.

[DavidSchinazi]

Chair: we didn't discuss this specific issue in the WG session at IETF 118, but see related issues https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/135, https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/140, and https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/143.

[ekinnear]

So the proposal here is to say that the client including the "webtransport" upgrade token is sufficient.

• For version negotiation we cannot offer multiple upgrade tokens (yet).
• Moving it to the request might be interesting as an idea, but the issue with that is that we change the meaning of certain frames and you need the entire HTTP/3 connection to agree on what the stream formats are.
• Especially if we're trying to avoid having the server have to buffer some of the frames, that seems sub-optimal.

The alternative is that the server has to buffer until it gets SETTINGS.

Fundamentally, it seems like if we want to avoid buffering, but we also need the server to have a piece of information from the client, the only way to ensure that we don't have to buffer is to ensure that the information from the client arrives atomically with the thing that we'd be buffering.

Editor's meeting led us to one way to tackle this:

1. Client never sends a SETTING indicating what it supports.
2. Server sends a SETTING indicating every version that it supports.
3. We commit to changing the code points for all special WT frames, etc. with each version.
4. The server can always tell based on what's coming in what version it's talking, and it can enforce that we talk a single version on each connection.
5. The server only has to buffer things that it would have to buffer today (i.e. no waiting for SETTINGS, but you do have to buffer if you get in STREAM frames for a WT session that isn't yet open, just like today).

@vasilvv took an action to identify why we rejected this in the past.

Same story for #143.

[ekinnear]

Discussed in editor's meeting, @vasilvv cleared previous concerns.

[DavidSchinazi]

Chair: discussed in editor's meeting. Plan is to write one PR that resolves #135, #140, #141, and #143. That PR would say:

• client MUST wait for server settings
• endpoints MUST send SETTINGS_H3_DATAGRAM (however servers that want to validate this MUST need to take into account the fact that the request might arrive before the client's SETTINGS)
• client no longer sends the WEBTRANSPORT_MAX_SESSIONS setting
• Add a "Considerations for future versions of WebTransport" section that explain that if a future version of WebTransport changes the syntax of the request, it'll need to change the Upgrade Token. Similarly, changes to stream formats will require changes to the Unidirectional Stream Type and Bidirectional Stream Signal Value.

[marten-seemann]

I'm very happy with this solution, thank you @DavidSchinazi!

• endpoints MUST send SETTINGS_H3_DATAGRAM (however servers that want to validate this MUST need to take into account the fact that the request might arrive before the client's SETTINGS)

Is it valid for a server implementation to do this validation retroactively? A server could first accept the WebTransport session assuming that the client's settings will be valid, and if / once the settings are received, it performs the required checks and kills the QUIC connection if the client didn't offer SETTINGS_H3_DATAGRAM.

[DavidSchinazi]

That's a good point - yeah from my perspective (as individual contributor) I'd say that it's totally OK for the server to accept the request and reply with 200 before it receives the client's settings, and then abort the stream or connection when it receives the settings if SETTINGS_H3_DATAGRAM is missing