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

[Eric Kinnear <[e-mail]>]

I think I have a very different perspective on what @igorlord is saying above. From my perspective, if I'm 95% of the way done fetching a resource that I would need to restart from the beginning, I'm more than willing to have a suboptimal experience finishing that 5% than start over from the beginning. I would imagine that network attachment changes will result in the following behavior: 

1. Migrate currently active (not idle) connections to the new attachment
2. Bring up new connections from scratch on the new attachment for new requests
3. Transition everything we can to those new connections and close down the old ones once their transfers have completed
4. Have some threshold (likely bytes, but maybe percentage) beyond which we will just use the new connection and not the migrated one if it's not providing equivalent performance to what we had before

Prohibiting us from migrating here (especially in the embedded CDN node case) is probably something that we should discuss elsewhere as it's a bit orthogonal to this topic.

However, I think the key here, as we talk about use cases that are important to handle and cannot be handled via an extension, is that I don't think `disable_active_migration` was introduced to be an advisory "you probably shouldn't try to migrate because I don't think you'll have a good time if you do", we were pretty clear that this was a "disallow this, if you do it we will ignore your packets and that might break your connection". Clients are already expected to probe (if they can) and use those measurements to make good choices, it's already understood that some network topologies might result in a bad time if you attempt to migrate, and often the choice will be between a connection that's going to fail vs. a suboptimal connection.

Someone who doesn't want to allow migration to a different network attachment can simply ignore the probing packets that come in from those other attachments. Prohibiting migration entirely (or building a whole new scheme for prohibiting different types of migration) seems quite excessive in that case.

To summarize: 
- While I think it would be fine to generalize the "disable_active_migration" flag to cover SPA per-address as well, I don't think that we need the additional levels (although thank you @MikeBishop as it's really nice to see them listed out) outside of an extension. 

- Again, that's _if_ we decide there's a reason to do something other than the consensus already reached.

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