Subject: [quicwg/base-drafts] Disagreement about Path Liveness (#1495)

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jun 2018 20:52:58 +0000 (UTC)

Follow-on issue from #1465 and #1484. The existing text says that for the first transmission on a new path, you have to use a higher-order CID (greater sequence number) than you've ever used before; once a path exists, you can't use a lower-order CID than you've ever sent or received on the network.

Two scenarios:

> A client has probed an alternate path, but not migrated, and then sends no traffic on that path for a prolonged period of time.  The client considers the path to be idle; the server considers the path to have timed out.  After some time, the client decides to re-probe.  It's permitted to use the same CID that it had previously used.  However, if the server has considered the path closed, it might not remember the old CID that had been bound to a path.
> 
> This will provoke a Stateless Reset from the server in response to the probe, even though the server considers the connection itself to be valid, and would accept the probe if a fresh CID were used.
-------------
> An endpoint has advanced to a new CID; the peer, seeing the new CID, now considers older CIDs invalid after a certain period.  A packet with an old CID is severely delayed.  The peer, upon receipt of the delayed packet, considers it to belong to an unknown connection and generates a Stateless Reset.

Possible solution:  We might need to have the side forgetting CIDs explicitly inform the peer that it will no longer use or accept CIDs older than a certain cutoff.  You have to remember old CIDs you've issued until this frame is acknowledged; upon receipt of this frame, you no longer consider the stateless reset tokens valid.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 28 Jun 2018 15:20:35 -0700

The ACK requirement does not handle malicous intent to drain resources. Could there be a negotiated limit that relates to how many migrations are being excercised that both sides can influence?

-- 
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/1495#issuecomment-401190673

---

From: ianswett <[email-masked]>
Date: Thu, 28 Jun 2018 22:35:25 +0000 (UTC)

Given your recent PR and the 3 open issues, I think it makes sense to talk about CIDs in Montreal.  Mike, would you be willing the present on the relevant issues 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/1495#issuecomment-401193547

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jun 2018 15:35:41 -0700

Maybe I should amend it to SHOULD accept the packets and MUST NOT Stateless Reset them, because that's really the limitation.  You can't respond to old CIDs with a Stateless Reset until you're sure the other side has gotten the retirement packet, but there's nothing seriously wrong with dropping them.

If you just keep sending `RETIRE_CID` and start dropping packets with old CIDs, you'll either reach a stable state again or eventually the connection will time out and die because no packets are getting acknowledged.

-- 
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/1495#issuecomment-401193605

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jun 2018 22:36:00 +0000 (UTC)

@ianswett, sure.

-- 
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/1495#issuecomment-401193672

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 28 Jun 2018 19:09:24 -0700

@MikeBishop 
> Possible solution: We might need to have the side forgetting CIDs explicitly inform the peer that it will no longer use or accept CIDs older than a certain cutoff. You have to remember old CIDs you…

FWIW, an alternative approach will be to let each endpoint declare the maximum number of spare CIDs that the endpoint is going to keep.

An endpoint can request new connection IDs when the number of spares goes below the threshold that has been advertised by the peer, either by sending a `REQUEST_CONNECTION_ID` frame (which is proposed in #1496) or defining offering of CID as a reciprocal action (i.e. a client who wants more CID requests that by sending a new connection ID to the server; IIRC @martinthomson suggested that approach somewhere).

-- 
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/1495#issuecomment-401226177

---

From: MikkelFJ <[email-masked]>
Date: Thu, 28 Jun 2018 23:12:04 -0700

A limit was also what I was trying to suggest in the above. But a limit must somehow be sensitive to the rate of migrations - or future multi-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/1495#issuecomment-401257925

---

From: Mike Bishop <[email-masked]>
Date: Fri, 29 Jun 2018 10:23:32 -0700

One more scenario is load balancer key rotation.  We've already sketched the possible scheme where the CID includes a key phase indicator and the CID itself is some encrypted payload.  At whatever point the key identifier wraps (every key change, if it's a single bit), you need to bulk purge all CIDs issued under the soon-to-be-removed key.

Probably largely irrelevant for short-lived connections, but long-lived connections could easily run afoul of 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/1495#issuecomment-401420026