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

Kazuho Oku <> Tue, 31 March 2020 04:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08CCE3A1AE9 for <>; Mon, 30 Mar 2020 21:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 0nimyO5gQeY8 for <>; Mon, 30 Mar 2020 21:54:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48C963A1AE8 for <>; Mon, 30 Mar 2020 21:54:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CE591C0785 for <>; Mon, 30 Mar 2020 21:54:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585630479; bh=0Yh73jRZ1bGce+B/DTxrJV+gVoAMoSSlWtz02ivRIBA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Gsh0EOMZ1ZwrLI1ApOyOLopGNWBDXQYc55zYdnPyX8MD2jVnoUmXX5wlpxKQjvPBn a4LqvVxMvNVVba/c1s7/w1D+wDc/+KR5vBwKsByqL0dYs9bDICRIUiQ+gYh1bNRZKe f+fBW1XY8J/uq/DQs17lVvmpcHLGAm1q1tXpi5PY=
Date: Mon, 30 Mar 2020 21:54:39 -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_5e82cd0f4e4cc_680b3fbab8ccd960299078"; 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: Tue, 31 Mar 2020 04:54:42 -0000

@kazuho commented on this pull request.

> @@ -1069,6 +1069,15 @@ 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 SHOULD limit the number of outstanding RETIRE_CONNECTION_ID frames
+to bound the necessary state. In order to allow a peer to retire all previously
+issued connection IDs, the limit on the number of outstanding
+RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit. An

> Note that if we also take Ian's #3550, then none of these RCID frames are necessary. You only use RCID for discretionary use (where you use a connection ID and find you no longer need it). That's why I think that's a nice addition.

I think I agree with this. Status quo is just confusing, as it requires endpoints to send RCID frames for the retired CIDs they have received, but does not require the frames to be sent for the CIDs that they receive afterwards.

This means that from the viewpoint of the endpoint that requests retirement, it cannot assume that it would see RCID frames for the CIDs that it has requested retirement, but in most cases it would see them. This could turn into a trap in some implementations.

I agree that we should adopt #3550, so that we would never assume to see RCID for the CIDs that we request retirement.

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