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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4532F3A1AC7 for <>; Mon, 30 Mar 2020 21:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.038
X-Spam-Status: No, score=-0.038 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, HTML_OBFUSCATE_10_20=1.162, 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 4_l_pFYAJYWp for <>; Mon, 30 Mar 2020 21:46:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 049273A1AC6 for <>; Mon, 30 Mar 2020 21:46:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C627520774 for <>; Mon, 30 Mar 2020 21:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585629977; bh=2CtpjXVLQlLy2WwC79A1Wllh6825mtMBzjwT5O1QpDI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YHyeo1TY4qneXAzR2IYN4kowzbjeiTqkYrwKYV5o3UN6L4IsgPNxEVuKNsnIk1skW HgnLc7+wO0elULJEcnH92/b2EiH/Dn1Udg6ITFg8lmWbwOa0p9NuRX9n/oPYRHs8R6 rXGaX4ffTtoY8xdS33isRWG9myedrpp8KC4qd2o0=
Date: Mon, 30 Mar 2020 21:46:16 -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_5e82cb18f0661_64943f909b2cd95c48540"; 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:46:19 -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

I agree that we do not need to care about sufficiency.

> if you track min(unacknowledged RCID) and max(RPT) then you can track as few RCID frames as you like. It might be nice if people used active_connection_id_limit*2, but that number only optimizes for a complete turnover of connection IDs every round trip.

This observation is what I disagree with. The intent of the change I proposed right above is to allow an endpoint to retire all the CID at once, without being concerned about the peer losing track of some sequence numbers carried by CID frames already inflight, or the peer considering the endpoint to be doing something malicious.

Assuming that an endpoint that retires CIDs track each of the RCID frame it sends, the safe number is _active_connection_id_limit_ (the number of CIDs that might be retired at once by RPT) plus _the number of retirements that that endpoint might initiate at once_.

To give a specific example, consider the following case.
* A client, with max_connection_id_limit = 2, is using CID<sub>0</sub> for the main path, and is probing a new path using CID<sub>1</sub>.
* Server sends NCID(CID<sub>2</sub>, RPT=2), NCID(CID<sub>3</sub>, RPT=2).
* Client receives these NCID frames, and assigns CID<sub>2</sub> to the main path, CID<sub>3</sub> to the path being probed. The client sends RCID(CID<sub>0</sub>), RCID(CID<sub>1</sub>).
* Before receiving ACK for the two RCID frames, the client decides to abandon the path being probed. It needs to send RCID(CID<sub>2</sub>).

At this point, the client is required to track the flight of RCID frames carrying *three* CIDs. And it has to make sure that RCID(CID<sub>2</sub>) reaches the peer, otherwise it would not receive a CID that substitutes CID<sub>2</sub>.

The recommendation in this PR now (i.e. "the limit on the number of outstanding RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit") fails to cover this case.

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