Subject: [quicwg/base-drafts] Clarify response to a non-probing migration when no CIDs are available (#4788)

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 14:13:07 -0800

Section 9.3 of Transport(https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3) says:

"If the recipient permits the migration, it MUST send subsequent
   packets to the new peer address and MUST initiate path validation
   (Section 8.2) to verify the peer's ownership of the address if
   validation is not already underway."

In section 9.5(https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.5)

"Similarly, an endpoint MUST NOT reuse a connection ID when sending to
   more than one destination address.  Due to network changes outside
   the control of its peer, an endpoint might receive packets from a new
   source address with the same destination connection ID, in which case
   it MAY continue to use the current connection ID with the new remote
   address while still sending from the same local address."

So as long as it's an unintentional change, everything is clear.  But if the destination address changes and the incoming CID changes, but the sender(ie: server) doesn't have any more CIDs, it's not clear what should be done, as the two MUSTs seem to contradict one another.  Or maybe they imply the server can't send anything?

-- 
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/4788

---

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 14:16:18 -0800

Later in 9.5, there's also this text that is relevant, but I don't think it clarifies how to resolve the MUSTs.

"   An endpoint that exhausts available connection IDs cannot probe new
   paths or initiate migration, nor can it respond to probes or attempts
   by its peer to migrate.  To ensure that migration is possible and
   packets sent on different paths cannot be correlated, endpoints
   SHOULD provide new connection IDs before peers migrate; see
   Section 5.1.1.  If a peer might have exhausted available connection
   IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
   all packets sent on a new network path."

-- 
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/4788#issuecomment-763985965

---

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 15:49:22 -0800

It may also be worth clarifying that if the peer migrates and doesn't change CID, either it's already linkable or not, so there's not point in changing CID in response.

-- 
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/4788#issuecomment-764036081

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 15:56:08 -0800

So the second quotation has that clarification (with emphasis):

> an endpoint might receive packets from a new source address with *the same destination connection ID*, in which case it MAY continue to use the current connection ID

Isn't this all coherent?

-- 
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/4788#issuecomment-764041871

---

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 15:58:37 -0800

Yes, that clarifies the issue when the CID does not change.  But that does not clarify the case when the CID does change and the responder has no more 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/4788#issuecomment-764044065

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 16:00:55 -0800

Isn't that addressed by this:

>  An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to migrate

?

-- 
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/4788#issuecomment-764046043

---

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 16:02:17 -0800

So the answer is:
1) It can't send anything
2) It can send on the old path, but not the new one

-- 
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/4788#issuecomment-764047215

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 16:19:24 -0800

It can probe the old path - but that is all it can do.

-- 
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/4788#issuecomment-764062360

---

From: ianswett <[email-masked]>
Date: Wed, 20 Jan 2021 16:40:08 -0800

Why would it probe the old path that it's already validated?

-- 
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/4788#issuecomment-764089225

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 16:43:31 -0800

I didn't say that it was *useful*, just *possible* :)

-- 
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/4788#issuecomment-764096151

---

From: mjoras <[email-masked]>
Date: Wed, 20 Jan 2021 18:16:10 -0800

I don't see a pressing reason to do anything about this. That said, it's an unfortunate edge case, perhaps we could call it out explicitly, mentioning that this shouldn't arise if the other parts of the migration machinery are followed?

-- 
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/4788#issuecomment-764186112

---

From: ianswett <[email-masked]>
Date: Thu, 21 Jan 2021 06:19:25 -0800

To be clear, I'm not looking for a fix as much as clarity on what is supposed to occur.  I'll write a PR that I think will clarify it some and call out the edge 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/4788#issuecomment-764673314

---

From: ianswett <[email-masked]>
Date: Thu, 21 Jan 2021 06:32:48 -0800

I'd argue this is really a MUST unless case, but people tend not to like those, so I tried to stick to the facts in my PR.

-- 
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/4788#issuecomment-764682108