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

From: ianswett <[email-masked]>
Date: Fri, 01 May 2020 12:19:02 -0700

@kazuho So your suggestion is that disable_active_migration applies only to the original address and the SPA must always support active migration, because it has to use CID routing?

I don't think that'd be a problem for our use cases, but I'm not sure about others.

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 01 May 2020 12:49:45 -0700

@ianswett 
> So your suggestion is that disable_active_migration applies only to the original address and the SPA must always support active migration, because it has to use CID routing?

Exactly. I think that that would be the correct thing to do, if we are to make changes.

I agree that existing clients might be applying `disable_active_migration` after migrating to SPA, and that they do not want change. But they can remain as they are, because the change in spec does not lead to interoperability issues.

To paraphrase, I think making the aforementioned change is strictly better than doing nothing, because it would be an improvement to some, while not hurting anybody.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 03 May 2020 22:41:23 -0700

A truth table might help here.

... | migration supported (no signal) | disable_active_migration set | 
---|---|---|
no preferred address | normal (migrate as you like);  | don't migrate |
preferred address | normal (migrate at your leisure) | don't migrate |

Right now, our definition of disable_active_migration is a simple "don't migrate".  But the argument here says that the server that provides a preferred address is *probably* capable of handling migrations on the basis that it has to support one.  We might insist on the source address not change, but the fact is that some NATs (those with address-dependent mappings) will change the source address.

Changing to a definition where disable_active_migration is instead "don't move to a new address unless you use a preferred address" is a little more complicated, but doable.

Is it worth the extra complexity this late in the process?  Is that complexity justified when it would be trivially possible to define another extension that said "I support migration on my 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/3608#issuecomment-623267502

---

From: ianswett <[email-masked]>
Date: Mon, 04 May 2020 03:50:13 -0700

I'd like to minimize changes, but I believe the status quo is that disable_active_migration applies to both the original address and SPA.  As such, all suggestions above seem like a change.

There is a mechanism to disable migration on the SPA, which is don't give out any more CIDs once they migrate.  I don't expect any hosts to support migration on the original path and not the SPA, so I don't think that's a use case worth supporting(or encouraging).

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 04 May 2020 19:04:48 -0700

My proposal is that we defer the ability to signal "I support migration, but only on my preferred address" to an extension.

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

---

From: ianswett <[email-masked]>
Date: Tue, 05 May 2020 06:39:52 -0700

@martinthomson And leave the current behavior of disable_active_migration applies to both the original address and SPA?

I'm a bit concerned that makes SPA somewhat useless.  Is this issue a candidate for parking and we can come back to and see if we can live with the status quo?

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 05 May 2020 10:54:09 -0700

> There is a mechanism to disable migration on the SPA, which is don't give out any more CIDs once they migrate.

Which, again, not only disables migration, it disables the ability to rotate CIDs.  That's not something we want servers to be doing.

@kazuho's argument is convincing that it's improbable for something which supports SPA to not be able to uniquely identify connections (whether by CID or because the SPA endpoint is unique).  Therefore, I'd support scoping disable_active_migration to the handshake address, and defer the ability to disable it on the SPA to an extension.

Loosening this definition doesn't make any current clients break, so I suspect it's bearable despite the schedule.

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

---

From: ianswett <[email-masked]>
Date: Tue, 05 May 2020 10:57:46 -0700

If we're going to make a change, I support @kazuho and @MikeBishop direction of scoping disable_active_migration to the handshake address.

And I agree that I don't expect this breaks many existing clients.

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 05 May 2020 13:19:11 -0700

I personally find the proposed change confusing. I'm not sure I find the use-case of "my original address doesn't support migration but my preferred address does" compelling. Since this can be easily solved by an extension with no downside over it being in the core docs, I don't see a reason to change the spec at this point 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/3608#issuecomment-624283935

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 May 2020 19:44:14 -0700

As this has sat here a while, I'll reiterate my proposal again: we defer the ability to signal "I support migration, but only on my preferred address" to an extension.

Which means that disable_active_migration applies to both the original address and SPA, so answer the question (sorry Ian, I missed that).

I realize that you could change the meaning of disable_active_migration to apply to the address the server uses in the handshake, but there are interesting corner cases and I don't think we need to concern ourselves with those.  For instance, if you connect over V4 and get disable_active_migration and server_preferred_address.  If that SPA includes a V6 address you can't use, along with the same V4 address, what then?  Does the server really support migration?

I know that the current situation is unappealing, and I think that disable_active_migration is not good for the protocol.  But it exists for very good reasons.  Trying to limit the scope is admirable, but as we haven't seen a concrete proposal, I think we need to move on.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 17 May 2020 20:52:54 -0700

@martinthomson 
> I realize that you could change the meaning of disable_active_migration to apply to the address the server uses in the handshake, but there are interesting corner cases and I don't think we need to…

If this example is concerning, I'd argue that is an issue that already exists, orthogonal to what we are discussing here. I am still not convinced that limiting the scope of disable_active_migration to just the original address is going to cause any _new_ issue.

That said, if nobody needs this change, I'm more than happy to move on with status-quo.

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

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 13:34:54 -0700

I've thought about this, and I don't believe we need this change, but I also think the change @kazuho suggested makes the current behavior better overall.

A server that supports migration on the SPA(ie: unicast) and not on the handshake address(ie: anycast) will end up not disabling migration and hoping that most clients migrate to the SPA or don't support migration of any sort.  That seems like a plausible hope, though I'm a bit leery of hope based protocol design.

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

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 13:38:27 -0700

Thinking about this more, a statement like:
"Migration is never guaranteed to succeed.  For servers that advertise a preferred address, it's expected migration is more likely to be successful when using the preferred address than the handshake 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/3608#issuecomment-631068965

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 May 2020 14:34:25 -0700

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 20 May 2020 21:12:12 -0700

I would rather not make the change in #3670. It assumes that migration is more likely to succeed when attempted to the preferred address as opposed to the handshake address. While this assumption might hold in some server deployments, it is not a fact. I'd rather we didn't bake this assumption into the core spec. I'd prefer to see this feature as an extension.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 20 May 2020 21:20:43 -0700

@DavidSchinazi 
> It assumes that migration is more likely to succeed when attempted to the preferred address as opposed to the handshake address. While this assumption might hold in some server deployments, it is not a fact.

Would you mind elaborating why a server, accepting connections on a preferred address, might not be able to disambiguate connections using CIDs?

As stated previously, when a client migrates to the preferred address, the client's address port tuple can change due to the existence of NATs. A server using preferred address need to take that into consideration. That means that a server has to disambiguate connections based on the CID, which in turn means that the server would be possible to support 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/3608#issuecomment-631869936

---

From: David Schinazi <[email-masked]>
Date: Wed, 20 May 2020 21:42:19 -0700

Hmmm thanks for that note @kazuho. Looking at things under that light, I agree that the assumption I described above is already part of the protocol. Please disregard my comment above https://github.com/quicwg/base-drafts/issues/3608#issuecomment-631867975 .

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