Re: [quicwg/base-drafts] Limit RCID state (#3547)

Kazuho Oku <> Fri, 27 March 2020 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99B543A0969 for <>; Thu, 26 Mar 2020 23:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.901
X-Spam-Level: *
X-Spam-Status: No, score=1.901 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, GB_SUMOF=5, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JIR4SBJfu3Fx for <>; Thu, 26 Mar 2020 23:37:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1764F3A08AF for <>; Thu, 26 Mar 2020 23:37:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15C0B660031 for <>; Thu, 26 Mar 2020 23:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585291028; bh=2hEXvX94Rk8G9/DSYFoWE5MA7xqUxVjVVk6XseBjC20=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gMa5DsLLpL2lyHOxjGImmJoZPg2wqZyMNVgPhDhIAaVTAj4AgqHbwH4tVxrrofsBO Yw1Ialt5OHW3frXSUOeRy4rgdshyPwnXMhzFskeVgS1b1FwvONIEXByo/0iDEh61nJ KElqAleMjdm9sVLA+IsjuKjC9uuXumg+Zk7MY90A=
Date: Thu, 26 Mar 2020 23:37:08 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3547/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Limit RCID state (#3547)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7d9f145bb8_15f33faa906cd96c106047"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Fri, 27 Mar 2020 06:37:12 -0000

@kazuho commented on this pull request.

> @@ -1069,6 +1069,18 @@ to cease using the connection IDs when requested can result in connection
 failures, as the issuing endpoint might be unable to continue using the
 connection IDs with the active connection.
+An endpoint MAY elect to only send or retransmit RETIRE_CONNECTION_ID frames
+with sequence numbers greater than or equal to the highest Retire Prior To field
+received minus its advertised active_connection_id_limit. This bounds the

> I didn't have a specific limit in mind. I might consider active_connection_id_limit as the number (which bounds the total number of things you need to remember to 2 times that as you might also need to remember connection IDs for active use as well).

Thank you for the clarification. If that is the case, let my explain why I think `max_connection_id_limit * 2` is the correct value.

The draft currently allows an endpoint to request retirement of all the active CIDs that the peer retains at once. We explicitly define how the peer should behave in such case; see That means that the use of Retire Prior To might cause as much as *active_connection_id_limit* CIDs to be scheduled to be sent using RCID frames at once.

We also assume that the use of Retire Prior To is going to be infrequent.

Therefore, we need *active_connection_id_limit* in conjunction to the use of Retire Prior To.

Concurrently, the peer might be running business as usual, consuming CIDs as necessary. That means that we need some room for these too. We might argue that the active_connection_id_limit selected by the peer reflects the maximum pace that that peer is going to consume CIDs.

Based on this observation, my argument is that the sum of the two requirements makes sense; i.e. `max_connection_id_limit * 2`.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: