Re: Going STEK-less with QUIC?

[Christian Huitema <[e-mail]>]

On 7/27/2021 6:28 PM, Martin Thomson wrote:

> On Wed, Jul 28, 2021, at 09:02, Kazuho Oku wrote:
>> [...] I think the same result can be achieved in practice
>> by designing a format of NEW_TOKEN tokens that is to be shared by the
>> load balancer and the server. That token would contain the server-id.
>> When the load balancer receives an Initial packet conveying such a
>> token, it can parse the server-id contained in that token, and forward
>> the packet to the specified backend.
> Yep, that would work.  And the load balancer might choose not to honour the server selection choice if that instance was looking a little overloaded.
>
> In other words, no standard needed in all cases, but maybe another something for QUIC-LB to manage.

It is a matter of expectations. Suppose that the server goes STEK-less. 
It is only capable of honoring 0-RTT if the resumed session is routed to 
the same server as the initial server. Yes, the clients can unilaterally 
decide to reuse one of the NEW TOKENS as Initial CID, no new standard 
required there. But if they don't, and pick a random ID, the resumed 
connections will arrive at a random server, and 0-RTT will fail. So, if 
we want to encourage the "new token as initial" behavior, we may want to 
write something.

-- Christian Huitema