Re: [quicwg/base-drafts] disable_active_migration with SPA (#3765)

[Eric Kinnear <[e-mail]>]

At first glance #3898 seemed a bit backwards to me in terms of which "disable" bit applied to which address, but upon thinking it through I think it's the only way to handle if -- if we want to handle it. Trying to put that thinking into words below. 

Moving to the preferred address is essentially a migration, but of the server. Instead of trying to send packets directly to the client from a different server address (a naive form of "server migration"), we just tell the client, "please switch over here". 

In doing so, as @kazuho pointed out on the PR (#3898), the server has the opportunity to offer other address families, and a CID to use on the new address. We don't want to restrict the client from being able to connect to the preferred address with a different address family on the client.

---
_Example, feel free to skip ahead_

1. Client connects from v6 source address to v6 destination address
2. Server gives preferred v4 address + CID
3. Client connects from v4 source address to new v4 destination address

If you had NAT64, you could take an extra hop to the NAT64 box to keep using your original v6 source address, but we've got plenty of data showing that a "native" v6 or v4 connection is going to be much happier there.

---

This is great, since we use connection IDs instead of addresses, and we're giving the client at least one connection ID to use with the new server (we've already discussed the concerns about the rest of the CID pool and kept those out of QUICv1, I think that likely remains reasonable regardless of what we do here). This means that the packets which go to the preferred address are likely to get there since they're routed via a CID that was selected by the server handing out the SPA.

However, one of the reasons that you might want to use disable_active_migration is if you're bad at connection IDs, and instead need to prevent the client from changing addresses. 
This is now awkward because we can't really assume both things are true at the same time.

*It would be great to get some concrete examples of how things could go wrong if you allow the client to change source address when sending packets to the preferred address.*

We specified in #3670 when fixing #3608 that `disable_active_migration` only applied to the address used during the handshake, in part via the thinking that if you're migrating to a new address, that has to be able to handle such a client address change when the client switches and therefore must be okay with at least one migration.

Then, we've got what #3898 does, which is add a new bit you can set to say "please don't migrate after you get to the preferred address", which seems quite reasonable, if we think that there's a situation where a server can handle that "first" migration but then somehow not handle the rest.

@janaiyengar made the comment (which I linked below) on #3608 that: 
> 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.

Which I think makes a lot of sense, so if we choose to move ahead with providing this here instead of via an extension, #3898 should probably give a separate flag for each address.

---

So, to summarize, it seems like we'd want the following things: 

- Some concrete examples of how a server might not be able to handle that local address change when the client moves to the SPA address. If that's going to be a problem we should discuss it here rather than half-fix this again. 

- A reason to reevaluate the consensus we reached for #3608.

The original issue above is: 
> For example, a server is a backend in front of a load balancer (and hence wants to use a preferred address that does not go via the load balancer for improved performance and reliability). However, the server is in a network location that is unlikely to be accessible or be a logical choice when changing to a different network attachment provider.

This doesn't seem to be a reason to set `disable_active_migration` -- not all migrations need to be to a different network attachment and if you take the most common case of this, a CDN node embedded within an ISP's network that isn't accessible from other networks, then the client can happily migrate all it wants within that ISP's network. If it tries to probe (or even migrate if there are no other options) from a different network attachment, then it will simply see the server as not accessible.

Disabling active migration here would likely be harmful to the client but provide little benefit to either the client or the server.

Further along in [@janaiyengar's comment](https://github.com/quicwg/base-drafts/issues/3608#issuecomment-631095059) on #3608 that described much of the path forward that was taken: 

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

Since this doesn't seem to be a case where we would be deficient without specifying this, and it would be easy enough to do in an extension, is there any case where we _do_ need it and can't do it as an extension?

All that said, since this keeps coming up, it does seem that completeness would suggest that we'd want a way to set `disable_active_migration` for each address that the server has, in which case I think we can modify #3898 to get there.


-- 
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/3765#issuecomment-657832215