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

Martin Thomson <> Thu, 12 March 2020 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CD2F3A0936 for <>; Thu, 12 Mar 2020 16:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b6CQPAmpLnkB for <>; Thu, 12 Mar 2020 16:41:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBEAB3A0938 for <>; Thu, 12 Mar 2020 16:41:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3BF382815FC for <>; Thu, 12 Mar 2020 16:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584056497; bh=yGV4KCLHHmG6lxkY2GtlTog2SXMMRDcZABLOLbPK8PI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oouoG3yJYIUYxz3tn4EB3I7KQhdBuHFZifmesLP09JZxNLw87gln74O/YN3uANGN6 XiiYZsA5rEK0jQ98iFVXL+yQjs34SCHs/Cy2mYNAcsdYU3Fxz0idIOj7d/vc3UNhZx rXLqnzZuWgNOul3QecZMmQfR1TW7Q4d1NhTPY11I=
Date: Thu, 12 Mar 2020 16:41:37 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3426/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify zero-length CIDs and active_connection_id_limit TP (#3426)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6ac8b12b753_2d903fbc342cd96018978b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Mar 2020 23:41:39 -0000

martinthomson 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.

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: