Subject: [quicwg/base-drafts] CID ratcheting language is imprecise (#1452)

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jun 2018 10:45:11 -0700

As currently written, each endpoint MUST switch to a new CID when it sees its peer do so.  If taken literally by each peer, this will cause a change of CID by each peer every round trip; unless a sufficient stream of NCID frames is kept up, they'll exhaust the supply and #1276 would have the connection be closed.  That seems both unnecessarily fragile and not actually the intent of this requirement.

Intuitively, you want to switch when:
- You see the peer do so
- It's not in response to your own switch

Not marking this design, because I'm fairly sure this is the intent of the existing text, albeit not what it actually says.  I'm having trouble coming up with a concise way of wording the second piece of the condition, however.

Ironically, this would have been simple when CIDs had sequence numbers -- you MUST always use a CID with a sequence number >= the sequence number of the CID you're receiving from the peer.  But we weren't actually using them for that.  We could do something similar, though, saying you must count the number of times the peer has changed CIDs post-handshake and you must have changed at least as many times.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 12:20:27 -0700

Packet loss makes this even harder, similar to the case in #1464.  Using the counter approach, if you don't un-count a CID where all packets using it were lost, you'll fail to change CIDs the next time the peer changes.  However, if you *do* un-count it, but any of the packets were declared lost in error, then you wind up in the same loop where your delayed packet causes the peer to change, which causes you to change, which causes the peer to change....

I'm starting to think we need the sequence numbers back to make this work, but with some additional text about probing packets on a different path being handled a bit differently.

-- 
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/1452#issuecomment-398866138

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:12:27 -0700

Closed #1452 via #1465.

-- 
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/1452#event-1702592718