Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

[David Benjamin <[e-mail]>]

I think the proposal for moving it into the handshake only affects the server SETTINGS frame (that's the asymmetry that people are unhappy about), so it's fine. At the time the server sends it, it has decided on ALPN.

You do raise a good point about the ALPN dependency, however. That's a further complication to the QUIC/TLS interface: as long as we remember the server SETTINGS frame across 0-RTT, the QUIC/TLS interface must allow the server to pass the SETTINGS frame into TLS *after* TLS negotiates ALPN and *before* TLS sends tickets, likely in the ALPN callback. This happens independent of when the SETTINGS frame is sent (status quo, handshake, or something else). The only way to avoid that complexity is to stop remembering the SETTINGS frame across 0-RTT.

> There are a couple interwoven issues here. Let's try to untangle them:

I think your two issues are still interwoven. We can't do the second bullet point without the first, otherwise the client and server will get out of sync. But, yeah, this is the "yet another option" I suggested above.

> To that end, I guess there's yet another option: strike that sentence. The server must encode the SETTINGS de novo, and the client can start with either the initial value or the cached value. That ambiguity is odd, but the client already starts with the initial value at 1-RTT, so I think that's less of a nuisance.

-- 
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/2945#issuecomment-521037864