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

Mike Bishop <> Fri, 08 November 2019 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABD4E12025D for <>; Fri, 8 Nov 2019 06:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 lTE3AQkzJ5JA for <>; Fri, 8 Nov 2019 06:58:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15FDE12021D for <>; Fri, 8 Nov 2019 06:58:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 448CB6A1DF7 for <>; Fri, 8 Nov 2019 06:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573225097; bh=g6q8c1F2BiBiU/6OT5JSjdKeVm7r5twgMUM5B0jWhr0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uXs7pTtael94terQhBFUS+SGHVqqaA+ehF9ry1H7Z8o9E9ySWkiFVGxjKJQYjh8qm 2TSwU8Y2e9HvWN35Az7tbzs19UqBe+3xBarrajyNCKtrnBHIq80V/tUCYGuyf1Owkk Bh++K/kU54hGmUgW4aI3e9Hx47jwtP90MdYlNmsE=
Date: Fri, 08 Nov 2019 06:58:17 -0800
From: Mike Bishop <>
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_5dc58289351e4_32f43fc8512cd964768d2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 08 Nov 2019 14:58:20 -0000

I'm going to contradict me-from-yesterday a little, or at least complicate the point.

The reason we have the 1-RTO window is that some implementations might not be able to actually retire CIDs instantly (packets are queued in hardware offloads, you want to avoid racing in-flight packets against the packet containing the RCID, etc.).  If we require the retirement to be done as part of processing the frame, processing the frame can take up to an RTO.  What happens to other frames in the packet?  Does this packet get ACK'd if you're not done with this process yet?  Plus, you can't actually send the RCID frames until you've got the new CID *unless* you have a race with one more RCID frame in a subsequent packet.  This can get sticky very quickly.

If I had an implementation where I couldn't retire CIDs right away, I would probably tag them for retirement upon receipt of this frame and say those that are tagged don't count toward the limit.  But that's not entirely compliant with the text in your commit, and also assumes I have some headroom I'm not telling the peer about, because I have to remember all of them temporarily.

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