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

Kazuho Oku <> Fri, 27 March 2020 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14DE73A08E7 for <>; Fri, 27 Mar 2020 05:50:42 -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 N40T_Tz1psUi for <>; Fri, 27 Mar 2020 05:50: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 93DE43A03EF for <>; Fri, 27 Mar 2020 05:50:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B0BA28C1524 for <>; Fri, 27 Mar 2020 05:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585313439; bh=BSu7pixgWDabniRXNDpVI51Qdt9C8xWdFHJok2y2tOA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jm9SE/lxXagSGEQaqPCZ8derJ6GNPDx/P5mv3xWn8ZcX4kWPJtjiNg1qX51Qli+4F wa7EG27L1KotUnwky3MGr3S3oeFW0rTX9H5QLeL6sPx3du/Wnwep4KySVKlEN6FnyI 9aeiwwm38/paiCfWZSQLPNuBquZaFSuJF9JKupdE=
Date: Fri, 27 Mar 2020 05:50: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_5e7df69fa07be_46223fe5aaecd96466418"; 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 12:50:43 -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

Consider the case where  client has sent an RCID frame. The server has received that frame and has sent an NCID frame carrying a replacement. But that server has not sent an ACK yet, or the ACK it has sent has been lost.

At this moment, the server might decide to update the CID encryption key, and try to retire all the CIDs that has been provided to the client. When the NCID frame carrying the request to retire reaches the client, the client is now required to track retirement of `max_connection_id_limit + 1` CIDs.

I agree that this is a corner case. But our previous consensus has been to allow an endpoint to request retirement of all the CIDs that have been provided at once. Assuming that we want to retain that consensus, requiring endpoints to track *more* than `max_connection_id_limit` is IMO the logical choice.

The effect of *not* requiring that would be that an endpoint that decides to retire the CIDs that it has provided to the peer has to do retirement in multiple phases; e.g., first request retirement of half of them, wait for RCID frames, then retire the other half. That's much more complicated than just saying recommending endpoints to track something like `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: