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

From: Lars Eggert <[email-masked]>
Date: Fri, 03 Jul 2020 05:45:19 -0700

Discussion on this has stalled. Do I take this as a signal that this issue can be closed?

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

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 03 Jul 2020 06:30:25 -0700

My reading of the state of the discussion is that both use cases are understood. It is just that there is no agreed on way to resolve it, yet. @kazuho said he is not opposed to a signal in QUICv1 that says, "never actively migrate to another IP". I think this is an important use case and shall be done. I am happy to provide a PR; we just need to come up with how the signal will look like. It could be an attribute of Server Preferred Address, for example, or an attribute of disable_active_migration TP (if it had a value and it is 1), or another TP. I am fairly agnostic to the method. Do people have a preference? 

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 05 Jul 2020 18:28:24 -0700

I think that we were stuck on the meta-question, which is not about how to resolve the issue in a technical sense, but whether to resolve the issue in QUICv1 or an extension.  Given that we explicitly asked this question previously and resolved to defer to an extension, I think that the reason that this stalled is likely an unwillingness to say "no" again.  It's hard to look a use case in the eye and tell it that the bus is leaving without it.  But the bus is full.

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 09 Jul 2020 07:47:57 -0700

To use MT's analogy, it seems the bus's traffic information is stale and it isn't aware of a road accident ahead. Marking this as design so that the group can consider the information and decide an outcome.

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

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 09 Jul 2020 09:55:07 -0700

I think we actually can **almost** support the use cases I presented without a change, actually.

A server that does not desire a client to actively migrate can just avoid sending NEW_CONNECTION_ID frames.  Since migration to the SPA requires a change in CID, and a CID sent in preferred_address is the only additional CID available, that CID will be used up during SPA migration and no additional active migrations will be possible.

This **almost** solves the problem, because the client can combine active migration with SPA migration.  If we prohibit such active migration at the same time with SPA migration, if disable_active_migration TP is present (and, possibly, no NEW_CONNECTION_IDs have been received), it would solve the problem completely.

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Jul 2020 12:55:33 -0700

This discussion keeps coming up.  We decided before that wasn't a sufficient mechanism, because we want clients to be able to rotate CIDs periodically (especially after quiescence) and you can't do that without spare CIDs.

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

---

From: ianswett <[email-masked]>
Date: Mon, 13 Jul 2020 08:20:58 -0700

Thanks @igorlord that sounds like a fairly pragmatic way forward and makes doing nothing a more palatable option to me.  But I'm also fine to properly fix this and add a bool given the tiny behavior change.  But I'd like to do something(or nothing) soon.

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 13 Jul 2020 09:01:43 -0700

> But I'm also fine to properly fix this and add a bool given the tiny behavior change

Would someone like to prepare a PR so that the WG can get a feel for what this looks like?

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Jul 2020 14:03:49 -0700

#3898 is a first pass at this.

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 13 Jul 2020 15:42:15 -0700

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 16:19:46 -0700

+1 to the view that "disable_(active_)migration" is a property of each address, not the server itself. Therefore, if we are to make a change, that should come as a flag that designates that the address(es) offered by SPA cannot handle migration.

If we are to define such a flag in QUIC v2, I'd assume that it would make sense to define that flag as a new Transport Parameter that changes the definition of the preferred_address Transport Parameter.

OTOH, if we are to define such a flag in QUIC v1, it makes more sense to embed the flag in the preferred_address Transport Parameter, because, as stated, it is a property of the address being offered by the preferred_address Transport Parameter. This is what #3898 does, and I think it is on the right track (assuming that we'd be fixing the issue in QUIC v1).

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 16:59:47 -0700

Making `disable_active_migration` a property of an address allows for a lot of flexibility to innovate with routing and load-balancing and network deployments.  So +1 here.

@ekinnear,
> not all migrations need to be to a different network attachment

Except for a change to an address in another IP family, a different network attachment is by far the most common case to actively change to another IP address.  If the client knows that it is not changing the network attachment in a way that is relevant to the server, it can try to ignore the `disable_active_migration` hint on the SPA.  I think it is correct to have all normative language regarding `disable_active_migration` a SHOULD, since unintentional migrations will happen.

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

If the CDN node is, indeed, inaccessible from outside of the network, the client would be burning an rtt (or some timeout).  However, the node may actually be accessible from outside of the network, but have a poor performance from there.

Theoretically, I can see a case of some large enterprise campus creating a network with dozens of access points, all acting as independent NATs, and someone running around constantly connecting and disconnecting from the APs, getting new addresses with each AP migration.  But who actually builds networks like that?! It is much more likely that your address will stay with you for as long as you are connected to that network.  For someone running around a large campus, getting a new address on their device will pretty much only happen when they lose WiFi and reconnect via cellular (or hop on a bus via WiFi onboard) -- neither are likely be to great for the original embedded CDN node.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 17:13:05 -0700

@igorlord While I think I can follow your argument, it sounds to me that the issue you are describing is shared among all use-cases of SPA. To paraphrase, it an orthogonal problem to this issue (that is trying to solve the reachability problem of the preferred address).

Assuming that is the case, I am not sure if it is a good idea to add a restriction on how clients choose the source address, specific to the "disabled_migration" field of the preferred_address transport parameter.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 17:51:09 -0700

@kazuho I would say that reachability/fitness-for-service is a shared problem for all _client migrations_, not a specific SPA problem.

We introduced `disable_active_migration` to warn clients of situation where there is a high risk to reachability/fitness-for-service due to migrations after network attachment changes.

SPA is an attempt to improve reachability.  It does help with reachability after migration for some important types of deployments, and it helps with reachability even without migration by removing load balancers as possible points of failure (I include BGP-based anycast in "load balancers").  SPA does _not_ help with fitness-for-service after a migration.

This discussion is about deployment where there is a high risk to fitness-for-service due to migrations after network attachment changes.  SPA can be helpful there (see above), but migrations after network attachment changes is still inadvisable.

In terms of practical considerations, embedded CDN nodes are certainly examples of deployments with high risk to reachability _and_ fitness-for-service due to migrations after network attachment changes.  However, even public-facing anycast CDN nodes can have a similar fitness-for-service risk due to attachment changes in areas with poor network interconnections (some parts of Asia, for example).

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 18:30:32 -0700

@igorlord 
> In terms of practical considerations, embedded CDN nodes are certainly examples of deployments with high risk to reachability and fitness-for-service due to migrations after network attachment changes. However, even public-facing anycast CDN nodes can have a similar fitness-for-service risk due to attachment changes in areas with poor network interconnections (some parts of Asia, for example).

Thank you for elaborating. Good to know that we agree that the if the client should be using the same source address is an orthogonal issue to if the server disables migration for the preferred address.

My argument is, based on our shared view, that the issue should be discussed separately from disabling active migration the preferred address, because it is a separate problem (and that the current state of PR is incorrect in sense that it requires the client to use the same source address _only when_ migration is disabled for the preferred address).

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 18:44:04 -0700

The issue is telling the client that it should avoid changing the source address/network attachment (active client migration) during a connection while still allowing for SPA (destination address change).  Is that what you agree with?

Before the change in `disable_active_migration` semantics, `disable_active_migration` was such a signal.  Now, there is not one.  The semantics were changed to accomodate a useful use case, for sure.  Looking for a replacement signal...

> the current state of PR is incorrect in sense that it requires the client to use the same source address only when migration is disabled for the preferred address

I am not sure what "only" is emphasizing.  I read the current PR as stating that when Migration Disable flag is set, the handshake source address MUST/SHOULD be used when changing destination to SPA and thereafter.  It still needs work to clarify whether one can set Migration Disable flag, when `disable_active_migration` is not set.  And it needs to clarify how to perform address family change when Migration Disable flag is set.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 19:17:14 -0700

> The issue is telling the client that it should avoid changing the source address/network attachment (active client migration) during a connection while still allowing for SPA (destination address c…

I understand that that is the issue that you are discussing alongside disabling migration after the client moves to the preferred address. I think we agree at least that they are "technically" orthogonal issues.

> Before the change in `disable_active_migration` semantics, `disable_active_migration` was such a signal. Now, there is not one.

Thanks. I now understand your view, but I wonder if that has ever been the intent of the text. The counterexample is that we have intentionally allowed servers to provide a preferred address using a different address family than the original address. Wouldn't it be more natural to assume that the existing text regarding a MUST NOT for changing the client address (when the disable_active_migration TP was used) was written under the assumption that server_preferred address was not used in such case?

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 21:00:05 -0700

> I wonder if that has ever been the intent of the text. 

That could be asked of those who wrote the text and whose who provided their consensus. SPA (server migration) is a separate feature from client migration, controlled by disable_active_migration.  SPA does not have to involve client migration and better be controlled separately from it.

Change of protocol families is a cute feature of SPA, and we will see if it proves useful. There is typically a reason why a client chose the "wrong" family. In any case, existence of this feature necisates an update to the disable_active_migration sematic during the feature interactions.

I am pretty happy with the direction of @MikeBishop 's PR, since it restores an ability to provide a signal that "connection resumption is recommended instead of migration to another attachment".

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Jul 2020 07:13:05 -0700

> This is now awkward because we can't really assume both things are true at the same time.

I think you're right that there are multiple levels of wanting to disable migration.

- There are the 4-tuple load balancers who really can't handle a change of anything in the tuple, so you'd better do your best to keep your NAT binding alive, because a rebind will toast your connection; forget moving to any other networks.
- There are 2-tuple load balancers who can handle NAT rebinds that leave you on the same IP (common, but not guaranteed); client might be okay to permit rebinding, but that's a risk if the IP changes, and you'd certainly better not change the IP yourself.
- There are servers that either will not (contracts) or should not (performance) serve you if you change to a totally different network attachment, but changes within the same network attachment (e.g. Ethernet to Wi-Fi, roaming to a different VLAN) would still be okay.  Those are probably rare enough we could abstract away to "don't change interface."

This makes me wonder how far we'd get if disable_active_migration could differentiate "don't change port" or "don't change interface."  Would we still need to give different answers based on handshake vs. SPA address?

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

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 14 Jul 2020 09:29:42 -0700

Thanks for showing the cases, @MikeBishop.

You can probably split second bullet into 2a (any change in 2-tuple can route to a different backend) and 2b (change to a different network can route to a different backend -- I am thinking of BGP-as-a-load-balancer).

So you have:

* (1) "don't change port" (but since clients are unlikely to deliberately try changing ports, it is "don't change address")
* (2a) "don't change address"
* (2b) "don't change network/interface"
* (3) "don't change network/interface"

Bullets 1/2a/2b are load balancer concerns, and are very different from bullet 3 case.  In fact, you can have deployments where both bullet 1/2a/2b and bullet 3 concerns are true at the same time.

SPA helps with bullet 1/2a/2b case by removing the load balancer from routing, when the server can provide its own direct IP address.  So bullet 1/2a/2b concerns no longer apply to any packet sent to SPA.

After/during a change to SPA, only case 3 ("don't change network/interface") can matter.

Before the change to SPA, what really matters is whether there is an SPA to change to.
* If there is an SPA, the client will likely change to it quickly, so it probably does not matter which option one chooses while on handshake address.
* If there is no SPA, "don't change network/interface" will probably be good enough, since changing addresses within the same network is rare.  But I can be easily persuaded to entertain a different pov here.

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

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 14 Jul 2020 11:31:50 -0700

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

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 14 Jul 2020 14:54:21 -0700

@ekinnear Thanks for a great discussion of the issue.  I agree, there are few problems that cannot be solved with a robust "happy eyeballs" implementation.

I'd say that if your client implements such "happy eyeballs" for every migration, establishing a new connection as well the migrating the original one, you do not need `disable_active_migration` in any of its forms.  I wonder what benefit `disable_active_migration`  can possibly offer for a robust "happy eyeballs" client like that.

But what are less sophisticated clients supposed to do?  I am thinking of clients that have only one connection to each host open at a time.

You say that you would prefer to finish downloading those 5% of the object from a slow server.  But what if that server knew that it would not serve any bytes to a client located in a different network (legally prohibited)?  Would you care to know about it before the migration?  How would that server let you know (either, ideally, before the migration or after the migration w/o forcing you to time out)?

P.S.
The current text says that after a receipt of `disable_active_migration`, the client MUST NOT migrate, but it does _not_ say that the server "will ignore your packets".  Instead, it says that the server may either drop packets or proceed with the path validation and allow the migration.

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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Jul 2020 15:03:01 -0700

@MikeBishop's PR exposes this issue that I don't see how we can get around trivially: Yeah, this is getting tricky. A server that wants to use SPA with a different address family and _does not support_ migration has to deal with the case of the client's address changing when speaking to the SPA on a different address family. This is not different than migration, FWIW, and you'd have to do (i) the PATH_CHALLENGE/RESPONSE dance, (ii) ensure that the interface is the same as it was (how does a server ensure this anyway?)

I'm not sure that we _need_ to take on this larger problem, which can be made into an extension, this late in the process.

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jul 2020 23:57:06 -0700

Please keep discussing, we need to push this to a resolution one way or another.

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

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 28 Jul 2020 19:02:23 -0700

To summarize, it seems that people are generally not philosophically opposed to fixing this issue, but the solution needs to be simple and be compatible with the current behavior.

@MikeBishop has a PR that has one point unresolved -- what to do about SPA that is of a different protocol family.

I would like to propose a simple but workable solution.  _When "disable [active] migration" bit is set on the SPA, the client has to use the handshake source address if it is of the same address family as the SPA address it is migrating to.  If SPA is of a different address family, the client will have to change the source address but then stick with it for the duration of the connection._

If the server's need to prohibit active migration with SPA is due to the client's need to keep the same source address, the server will only return an SPA of the same address family and set "disable [active] migration" bit.  If the server is only concerned with the client staying on the same network, it can return a different-family SPA (and set "disable [active] migration" bit), since the chances are excellent the client will stay with the same network when it migrates very soon after the handshake completes.  

(In case the client tries to migrate to another address family and ends up on an unacceptable network, the server can probe the original path. If the original path is valid, the server would ignore packets coming on the new path, and the client would fail back to the original path.  If the original path is no longer valid, the server would close the connection on the new path.  The result would be a hiccup for the client, but this would happen rarely.)

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 29 Jul 2020 03:54:51 -0700

@igorlord 
> To summarize, it seems that people are generally not philosophically opposed to fixing this issue, but the solution needs to be simple and be compatible with the current behavior.

FWIW, I am fine with adding a field to the SPA TP indicating if active migration is disabled on that address.

At the same time, I am wary about recommending endpoints to use the current local address when migrating to a server-preferred address. That is because it changes how QUIC endpoints can be implemented.

At the moment, developers can implement a QUIC client that follows all recommendations (i.e. SHOULD), by letting the operating system choose the local address. You can simply create a local socket that is bound to 0.0.0.0, and let the operating system choose the source address of the packets that will be sent.

That approach would no longer be considered as recommended, if we are to have a SHOULD (or MUST) that suggests client to use the same address when migrating to SPA. Clients would be recommended to track and intentionally select the source IP address of outgoing packets.

Therefore, while I am not necessarily opposed to suggesting clients to continue using the current local address, my preference goes to *not* using a RFC 2119 keyword for the purpose.

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2020 04:44:02 -0700

Discussed at IETF-108. Feeling in the room seems to have been to close with no action.

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