Binding settings into session tickets

[martinthomson]

Session tickets might arrive before SETTINGS. If so, then clients will need to understand whether those settings apply when they resume.

I think that the right answer is to say that the first (and only?) SETTINGS is bound to all session tickets. Clients can then choose whether to remember settings with tickets and whether they wait for settings to arrive before saving tickets.

[nharper]

I don't think the clients should be choosing whether to remember SETTINGS with tickets.

Imagine the following connections (Cn), on which NewSessionTickets (NSTn) and SETTINGS (Sn) are received in these orders:

C1: NST1, S1
C2: S2, NST2
C3: S3

NST(n) is used to do 0-RTT resumption for C(n+1), and early data is accepted by the server in all cases. The server has correctly remembered the settings that applied to the previous connection to reuse in the new connection.

If the client remembers the tickets without the corresponding settings frames, then when it opens C2, the client will assume the default SETTINGS for early data, and then use S2 for the rest of the connection. Meanwhile, the server assumed S1 for the early data, and S1+S2 for the rest of the connection. In C2, the client sees S2 before NST2, so it saves its current SETTINGS state (which is S2) with the NST. Now, when the client opens C3, it uses S2 for early data, and S2+S3 for the rest of the connection. The server's perspective of settings for C3 is that S1+S2 applies for early data, and S1+S2+S3 applies for the rest of the connection.

If the SETTINGS frame is only optionally bound to tickets, then the client and server will have differing perspectives of which settings apply to a connection. Worse, this view will continue to diverge when tickets are issued and used on resumed connections, because the SETTINGS frame received on a 0-RTT resumed connection is a delta.

The right answer is that the first (and only) SETTINGS frame is bound to tickets. This means that a ticket received before a SETTINGS frame MUST wait for the SETTINGS frame, and also means the server MUST send a SETTINGS frame (if it is going to send NSTs).

[nharper]

There are a few more options here:

• When sending SETTINGS, send all values, not just the ones changed from the previous connection (i.e. don't send a delta). Once the client receives that SETTINGS frame, both sides agree on that state for the rest of the connection, but they might not agree on the SETTINGS for early data (it could be the default settings, or it could be the SETTINGS from any previous connection).
• Use the default settings for early data. Both peers will always agree on the settings state and there aren't any ordering concerns between SETTINGS and NST. However, this prevents using anything that depends on SETTINGS in early data, e.g. QPACK or future extensions. (Unless QPACK or a future extension defines some way to remember a value for early data on the next connection.)

[ianswett]

Using the defaults for early data would be unfortunate, because early(ie: 0RTT) requests are likely to want to insert QPACK entries into the dynamic table.

[DavidSchinazi]

And we would want to be able to use HTTP/3 extensions in 0-RTT.

[martinthomson]

I had reached the same conclusion as Nick: you have to wait for settings and you have to remember those along with the ticket. I had completely fail to act on that though. Good that we have an issue to track this now.