Subject: Re: [quicwg/base-drafts] Clarify zero-length CIDs and active_connection_id_limit TP (#3426)

From: MikkelFJ <[email-masked]>
Date: Wed, 11 Mar 2020 10:45:22 -0700

mikkelfj commented on this pull request.

> @@ -4697,11 +4697,12 @@ active_connection_id_limit (0x000e):
   to store. This value includes the connection ID received during the handshake,
   that received in the preferred_address transport parameter, and those received
   in NEW_CONNECTION_ID frames.
-  Unless a zero-length connection ID is being used, the value of the
-  active_connection_id_limit parameter MUST be no less than 2. If this
-  transport parameter is absent, a default of 2 is assumed.
-  When a zero-length connection ID is being used, the active_connection_id_limit
-  parameter MUST NOT be sent.
+  The value of the active_connection_id_limit parameter MUST be at least 2.
+  If this transport parameter is absent, a default of 2 is assumed.  If an
+  endpoint uses a zero-length connection ID, the active_connection_id_limit
+  value received from its peer is ignored and not used, as
+  NEW_CONNECTION_ID frames cannot be sent by an endpoint that opts for a
+  zero-length connection ID.

Is I wrote in comment to #3425, I'm not sure how 0-length is remembered for future connections when the 0-length value is to be ignored. Does it mean 0-length values are not remembered?

-- 
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/pull/3426#discussion_r391151980

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Mar 2020 15:53:50 -0700

martinthomson commented on this pull request.

If the new connection includes a zero-length connection ID, then the value of the transport parameter is not relevant.  It should still be remembered though.

-- 
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/pull/3426#discussion_r391315397

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Mar 2020 16:51:11 -0700

kazuho approved this pull request.

-- 
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/pull/3426#pullrequestreview-373199613

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Mar 2020 06:37:53 -0700

I just found the following in PR #3201 : "When a zero-length connection ID is being used, the active_connection_id_limit  parameter MUST NOT be sent.".

I take it that it is then not possible to remember 0 length?

-- 
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/pull/3426#discussion_r391625005

---

From: Nick Harper <[email-masked]>
Date: Thu, 12 Mar 2020 10:57:44 -0700

nharper commented on this pull request.

The text "When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent." is removed in this PR.

If 0-length CIDs are used, then this TP is irrelevant. The endpoints still need to remember what value was sent for this TP (or remember the default of 2). Remembering this could be a hardcoded configuration, e.g. if the client always sends 0-length CIDs then it doesn't actually need to remember it.

-- 
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/pull/3426#discussion_r391796066

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Mar 2020 16:41:37 -0700

Well, remembering can't be hard-coded as this is a property of the behaviour of a peer and we don't really allow for implementations to only work if a peer uses zero-length connection IDs.  But the central point remains.

Clients don't really have to remember this transport parameter as much as servers unless they intend to send NEW_CONNECTION_ID during 0-RTT.  But putting that in the spec is perhaps a little detailed - we can rely on no one really knowing if they don't remember it.  Just like clients might choose not to remember the limit on unidirectional streams on the basis that they might assume that servers will always provide the small fixed number needed for HTTP to function.

-- 
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/pull/3426#discussion_r391960617