Subject: [quicwg/base-drafts] Prevent connection ID exhaustion (#1468)

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Jun 2018 17:49:59 -0700

In #1452, we realized that we need connection ID sequence numbers back, and it seems like the design in #1465 depends on symmetry: if you see connection ID X, then you have to use at least connection ID X (and not X-1).

In that case, there will never be a case where an endpoint is going to want to provide significantly more connection IDs than its peer.  If any of those are used, it won't be able to send anything in response.  So that suggests a simple solution to exhaustion: if you receive NEW_CONNECTION_ID, you are required to provide NEW_CONNECTION_ID frames up to the sequence number you have received.

Then, an endpoint that wants to maintain N spare connection IDs can simply issue NEW_CONNECTION_ID frames until it has made that many connection IDs available to its peer.  It's peer is then obligated to provide the same number in return.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Jun 2018 20:03:29 -0700

Am I correct in assuming that we would have a sequence number in this proposed approach?

I think that we need it, otherwise an eternal ping-pong might happen. Of course we can prevent eternal ping-pong from happening by having a `is_pong` flag. But I would assume that it would be more straightforward (and descriptive) to have a sequence number.

-- 
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/1468#issuecomment-399306505

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Jun 2018 20:26:16 -0700

Answering my question by myself: by reading https://github.com/quicwg/base-drafts/issues/1464#issuecomment-399286416 I now understand that the solution proposed here works together with sequence numbers.

-- 
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/1468#issuecomment-399309663

---

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

This doesn't solve the case where one side is using zero-length connection IDs, though.  Unless we permit sending NEW_CONNECTION_ID with sequence numbers and zero length, I suppose.  I'm not sure I prefer that to a new frame type.

-- 
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/1468#issuecomment-399512932

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 Jun 2018 16:37:25 -0700

You can't switch between requesting a connection ID and not, so if zero length is chosen, then you might assume that that peer has every connection ID it will ever need and they are always on the right connection ID.

-- 
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/1468#issuecomment-399798066

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 17:50:16 +0000 (UTC)

Right, but say I've chosen to receive a zero-length connection ID and you choose an eight-byte connection ID.  Because you're always going to send me a zero-length connection ID, you'll never need more -- you'll never change, and so I'm prohibited from sending you a NEW_CONNECTION_ID frame.

So how do *I* prompt *you* to send me more?

-- 
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/1468#issuecomment-400404919