Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)

Eric Kinnear <> Wed, 06 November 2019 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84C1E120C0F for <>; Wed, 6 Nov 2019 00:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 7EQz_uP7yYzD for <>; Wed, 6 Nov 2019 00:17:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABED3120C0C for <>; Wed, 6 Nov 2019 00:17:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CFCC9C62019 for <>; Wed, 6 Nov 2019 00:17:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573028270; bh=2Av5VKBC41mF9BuiAzxkAucSNmMxn8SyvzsNbUkPv0U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vGUGKPhdP+6W4aFl/sIiYLKxDDIzvrNWNV/+5oYqppdRISVjWSdJ74xKEgF+92EVJ XLNpyX9zQFC4gbPXr5/bo4VJhnvfNd/ZT7qVnBkjW8dVWBWPLMVdug8Gy6BVgylUMt a+5UT2TGNjT6a626DGDwdxgJSbg60DEsDRtk3D8c=
Date: Wed, 06 Nov 2019 00:17:50 -0800
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3193/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc281aec092b_1cd53fa82a8cd964466688"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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: Wed, 06 Nov 2019 08:17:54 -0000

>  it seems like the reasonable thing to do would be to silently drop the CID on the floor

That was the previous recommendation if the peer provided too many CIDs and you didn't want to maintain any more, and I think that still applies if the peer doesn't respect the TP.

For context, this came up in several issues, the TP came in via #1994, with the [conclusion from Tokyo]( being that it would be advisory only (hence the SHOULD).

PR #1998 actually made the change which included that SHOULD, and also resolved the concerns from #2403. #2428 helped to clarify some rate-limiting around how quickly you should cycle through CIDs.

All that is to say, if you want to use the limit and explicitly communicate it with the TP, then you SHOULD do that. Everyone SHOULD do that.

If not, or if your peer doesn't respect it, you can always dump those extra CIDs on the floor, with all the potential for running out that comes from taking that action. In this case, you end up maintaining as many as you wanted, probably the same value that you sent in the TP that the other side ignored...

If/when the peer sends RetirePriorTo and requests that you retire them, you retire the ones you haven't yet retired and still know about. Generally, that means that you get a replacement for those, so now you still have `active_connection_id_limit` CIDs. (Side note: The place this gets messy is if the peer suddenly decides to respect the value you put in the TP and doesn't replace them. This has always been a potential consequence of dropping them, though.)

For the ones that you discarded, the peer should discard those 3PTO after it sent RetirePriorTo. From [Section 5.1.2](
An endpoint MAY discard a connection ID for which retirement has been requested 
once an interval of no less than 3 PTO has elapsed since an acknowledgement is 
received for the NEW_CONNECTION_ID frame requesting that retirement. Until 
then, the endpoint SHOULD be prepared to receive packets that contain the 
connection ID that it has requested be retired. Subsequent incoming packets 
using that connection ID could elicit a response with the corresponding 
stateless reset token.

So the peer that requested retirement can discard any state about them, and you're back to having everyone on the same page about how many are outstanding. 

That generally seems sufficient, although it would be great to cover another scenario or add some text that could be added to explain this better? If the issuing endpoint doesn't use RetirePriorTo then you're fine holding as many as you wanted to maintain forever. If they do use RetirePriorTo, then you're reset back to a good state.

And if you ever get RetirePriorTo indicating an old value, you're also happy since you don't need to do anything.

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