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

martinduke <> Tue, 31 March 2020 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BC963A1A35 for <>; Mon, 30 Mar 2020 21:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Status: No, score=-0.474 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_IMAGE_ONLY_28=0.726, 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 gBoplti1IUPl for <>; Mon, 30 Mar 2020 21:04: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 ADE0F3A1A2E for <>; Mon, 30 Mar 2020 21:04:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9235F6E1290 for <>; Mon, 30 Mar 2020 21:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585627479; bh=9aQ4iCaBXpDrg1tec+RnwW3ddJPSci8/co2ULTipO5c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PDO+7/MLBV+fJa/fsWaxtYwxaK7MZ4ZTY1filFz+1uaKH8W/+BIG7LFJXQCDclXwP 2dZLNb3xq4qgK4cz60S3vldH1dKtU8eQNgFw1WF1cHCsLRG8slRrAh782EUsz7gEWz DMfl8RDCBZWS5zKjPMEgE1AP48Zn+aSTi0qv7Vis=
Date: Mon, 30 Mar 2020 21:04:39 -0700
From: martinduke <>
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_5e82c15780e37_68253fbab8ccd960112742"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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:04:42 -0000

@martinduke 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

It occurred to me that we might be talking about two entirely different ideas.

1) The "Maximum number of outstanding RCIDs" is a momentary restriction. I might send only 10 at a time, or whatever, but eventually I will send all of the RCIDs that the protocol required before any of these PRs.

2) I need only send N RCIDs at a time, and can assume all other (earlier) sequence numbers have been de facto retired.

If my limit is 10 and I get 100 NCIDs that increment RPT by 1 in rapid succession, option (1) would have us send all 100 RCIDs over 10 RTTs, assuming no loss. option (2) would have us send 10 and be done with it. Which are we describing here?

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