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

[David Benjamin <[e-mail]>]

It's not really optional right now. This bit here is a problem: "The server MAY omit settings from its SETTINGS frame which are unchanged from the initial value". That means, if the client doesn't remember the SETTINGS information, due to, say, packet ordering, it won't apply this SETTINGS frame delta correctly. Having both sides disagree on how to interpret a SETTINGS frame is rather poor. Moreover, this mismatch is sticky. If you get out of a sync once, you stay out of sync as you renew tickets.

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.

Putting SETTINGS in the transport parameters gives it an ordering: it's guaranteed to be processed before NewSessionTicket. (And HTTP requests[*], for that matter, so it's an improvement in the 1-RTT case too.)

[*] More accurately, it's guaranteed to be processed before 1-RTT HTTP requests, but 0-RTT HTTP requests get the remembered one, so you still get to rely on some form of SETTINGS.

-- 
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-519348492