Subject: [quicwg/base-drafts] The number of Connection ID is unbounded to NEW_CONNECTION_ID sender (#2403)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 02 Feb 2019 18:18:20 -0800

Specification says that endpoint should provide new connection ID when it sees unused connection ID in the received packet or remote endpoint retires a connection ID.
Because remote endpoint can use any received connection ID without retiring any connection IDs, and local endpoint has to provide new connection ID when it sees these events and must accept any connection ID not retired yet, the number of connection ID which local endpoint has to remember is effectively unbounded.

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

---

From: MikkelFJ <[email-masked]>
Date: Sat, 02 Feb 2019 22:17:38 -0800

See #1994

-- 
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/2403#issuecomment-460026612

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 02 Feb 2019 22:35:40 -0800

I'm not sure #1994 is related to this.  But the its resolution might fix this issue.  I wait for the outcome of the 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/2403#issuecomment-460027365

---

From: Martin Thomson <[email-masked]>
Date: Sun, 03 Feb 2019 15:56:11 -0800

The state exposure for the issuer of connection IDs is the number of NEW_CONNECTION_ID frames it sends minus the number of RETIRE_CONNECTION_ID frames it receives (in both cases, excluding any retransmissions).  The design requires that connection IDs be remembered indefinitely, but the number is bounded by how many NEW_CONNECTION_ID frames the endpoint is willing to send.

The resolution to #1994 will allow an endpoint to send fewer (or more) than its peer requests.

-- 
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/2403#issuecomment-460100970

---

From: erickinnear <[email-masked]>
Date: Sun, 03 Feb 2019 20:01:26 -0800

To add to this, I think the fundamental design (which, admittedly, a TP confuses a bit) is that the issuer should issue (and maintain with new ones when retired) as many connection IDs as it’s willing to maintain state for. 

So, if the consumer of the CIDs uses all the new ones and doesn’t retire them, it will eventually run out of new ones to use. 

My understanding of the suggestion to replenish when a new one is observed is simply to lower the chance of having the consumer of the CIDs run out while RETIRE_ frames are in flight (or potentially lost). If the issuer is already at the max they’re willing to maintain, then only issue new ones when old ones are retired. The associated assumption here is that a consumer would not be advised to retire all CIDs at the same time.  

-- 
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/2403#issuecomment-460125027

---

From: ianswett <[email-masked]>
Date: Sun, 03 Feb 2019 21:57:04 -0800

The resolution to #2101 was that you can't retire a connection ID in a packet using that CID, which prevents retiring all of them.

-- 
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/2403#issuecomment-460139104

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 04 Feb 2019 13:17:07 +0000 (UTC)

If server can stop sending NEW_CONNECTION_ID, it surely fixes this issue.
The problem of current wording is that server MUST send NEW_CONNECTION_ID when it sees unused connection ID.  Meanwhile, client can use all connection ID without retiring none of them and call it a standard compliant.

-- 
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/2403#issuecomment-460246381

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Feb 2019 05:49:07 -0800

@tatsuhiro-t 
> The problem of current wording is that server MUST send NEW_CONNECTION_ID when it sees unused connection ID.

Isn't it a SHOULD?

I ask this, because I see the following text in [section 5.1.1 of the transport draft](
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.1.1): _An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs. While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs._

Having that said, I think I agree that we have an issue.

The minimum length of CID is 32 bits, based on the assumption that the space is capable of supporting multiple connections across certain time-space (remember the fact that CID cannot be reused more frequently than updating the secret used to calculate stateless reset tokens). OTOH, we do not prohibit (or discourage) endpoints from updating the CID aggressively.

For example, an endpoint might try to use a new CID whenever one is available in order to achieve "maximum privacy." That would mean that it would consume ~8 CIDs per round-trip, and in case the RTT is 10ms, it would be consuming around 2<sup>16</sup> CIDs every minute.

I do not think we would like to see clients being such aggressive against a server that tries to use minimally-size CIDs.

Therefore, I think we should discourage endpoints from changing CIDs when it is likely that it's tuple is stable.

-- 
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/2403#issuecomment-460255684

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 04 Feb 2019 14:35:32 +0000 (UTC)

@kazuho You are right, it is SHOULD.  I was probably confused by other places of MUST, or cosmic ray affected my browser to display MUST instead of SHOULD.

-- 
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/2403#issuecomment-460270993

---

From: erickinnear <[email-masked]>
Date: Mon, 04 Feb 2019 13:04:52 -0800

@kazuho Yeah, I don't think that endpoints should necessarily do that, but I'm not sure we need more text or at least that specific recommendation. The issuer is in control of how much it's willing to give out and how much state it's willing to maintain. A consumer that wants to rotate through CIDs that quickly might try regardless of what we recommend, and if the issuer isn't willing to maintain that much state, then at some point it will stop issuing new ones. 

Since we can no longer retire the last CID, then that just means that the consumer ends up stuck on a single CID. That seems like a reasonable outcome to me. If any new text were necessary, it seems like it would be to expand "only issue how *much* you're willing to maintain" to be "only issue how *much* you're willing to maintain however *often* you're willing to issue it".

In other words, it seems like it could be nice to avoid adding more recommendations for consumers that take into account the tuple as well. Folks should be free to change their CID whenever they want, with the understanding that doing excessive things in any direction (requesting too many now that we have a TP, retiring too often, etc.) is gated upon whatever the issuer is willing to support.  

-- 
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/2403#issuecomment-460412266

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 19:23:05 -0800

@erickinnear Thank you for the comment. I can understand the hesitation to having another requirement for the consumer of CIDs.

I think I agree to your conclusion that simply clarifying that the issuer might cap the limit the total number of CIDs it assigns for each connection would be sufficient (FWIW, I am considering of capping the total to 256 CIDs per connection).

My complaint is simply that the current text can be interpreted to assume that it is the issuer's fault when the client aggressively using new CIDs runs out of spares.

-- 
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/2403#issuecomment-460888623