Re: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)

[Nick Harper <[e-mail]>]

I disagree that moving this from H3 to the transport makes the transport more complicated than it simplifies H3.

The additional complexity to the transport is setting on the client a map of ALPN identifiers to application layer blobs of data (opaque to the transport), on the server setting a blob of data based on the ALPN, and getting the params sent by the peer.

Making this change to H3 means we remove the complexity of migrating from the default SETTINGS for a connection to the SETTINGS received some time later. It also reduces the complexity of binding SETTINGS to the NST for 0-RTT: on the server the SETTINGS is now in TP which already needs to be remembered, and the client now doesn't need to wait for SETTINGS to arrive after a NST to store them. It also removes the edge case where a client might do 0-RTT resumption without any remembered SETTINGS. This also removes the need for an H3 client to decide whether to send a request under default SETTINGS or wait for SETTINGS to arrive from the server.

I also disagree that this change introduces new meaningful complexity to generating the server's transport parameters message. The server needs to read the client's ALPN list and choose one that the server is configured for (this isn't new), and now it needs to when choosing the ALPN also choose the appropriate application parameters to go with that ALPN. For H3, the server will need those SETTINGS shortly after in the handshake when sending a NST so it can bind the SETTINGS to the NST. Likely the SETTINGS are constant, so it can be configured before accepting the connection with what the SETTINGS are and do a lookup to get those SETTINGS when sending ALPN.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541216958