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
