Re: [quicwg/base-drafts] 5-tuple routing and SPA (#3608)

[Jana Iyengar <[e-mail]>]

This conversation has made it clear to me that an address, and not a server, is the thing that supports client migration. Which makes sense -- migration support at the server is entirely a question of routability, and it makes sense that it would be tied to the address in question and not the endpoint. So *if* we were to do anything, I think I would propose: 
- scoping disable_active_migration to the handshake address, and
- adding two disable_active_migration flags to the preferred_address TP, for the two addresses in the TP.

That said, this is a clean enough extension. A new extension can define a new TP that provides this granular interpretation of the three server addresses. A server that wishes to support this can send both the SPA and this newSPA TPs, with the SPA TP (with the current scoping of disable_active_migration applying to all server addresses) providing cover for legacy clients.

Also I expect that clients are likely to switch to using the SPA if provided. A server that has different routability properties for the two addresses can wait for some deployment and make decisions on whether to risk allowing migration based on data of what it sees as client behavior with SPA.

I would argue for doing nothing now. Experience will teach us the right way forward. If necessary, this extension will be easy enough to do, and importantly, the current interpretation of disable_active_migration gives us the right kind of cover in the meantime.


-- 
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/3608#issuecomment-631095059