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

[Nick Harper <[e-mail]>]

I was thinking of asymmetry (client sends SETTINGS in an H3 frame, server sends them in TP in EE), though collapsing them entirely to TP and half a round trip earlier has some appeal. (My biggest concern with that is the client's SETTINGS are sent in the clear.)

In thinking about how to implement #2790 (and how to specify/clarify some of that language), there's quite a bit of interaction between the H3 layer and TLS layer. I see how it's tempting to move the TLS session ticket to an H3 frame. However, this means that any application that wants to use QUIC for its transport has to provide some mechanism to convey session tickets (otherwise that application can't use 0-RTT), which seems like a large downside.

Having everything at one layer for handling session tickets sounds like it would work best, and I think the transport layer (instead of the application layer) is the right place for that. The server's transport parameters already need to be remembered by both peers for 0-RTT resumption, so we're stuck with the transport-layer interaction with tickets. If we add an "application layer parameters" field to transport parameters, we can put the server's SETTINGS in there (and possibly the client's), and we get all of the logic for remembering SETTINGS for free. Also all of the ordering problems between SETTINGS and the NewSessionTicket go away.

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