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

Marten Seemann <> Wed, 06 November 2019 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 554D912087E for <>; Wed, 6 Nov 2019 05:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 fCMoqYSQjzAF for <>; Wed, 6 Nov 2019 05:42:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3E2B12010C for <>; Wed, 6 Nov 2019 05:42:32 -0800 (PST)
Date: Wed, 06 Nov 2019 05:42:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573047751; bh=iydDzPLc95OinCvoGopsuGYEtH3OMfxE0vEOJ24CuWA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=A1Nw0g8Yo3yKRQBPa8hdCTUSSSWMVXsDTL+vmXv8AzdrH49s8ilmjF7aC+ubqbmtF rSrGg8bYD/m6e6/82zbc3q4mbwSIDfkaq/7CGfpO3+krZfBoBR0jextrdwMARCRAVs Z+t/OFB+Xxo/UcdnD8fj/zObz+WvdECcbVkyRhwA=
From: Marten Seemann <>
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_5dc2cdc7782c6_5c5d3feaf6acd96c401597"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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 13:42:35 -0000

It seems like the problem we're facing here is that 3 things can happen with a new CID:
1. It is stored for later use.
2. It is retired via a RETIRE_CONNECTION_ID frame.
3. It is silently dropped.

For the endpoint providing the CIDs, 1. and 3. are indistinguishable, which might lead to a mismatching view of how many CIDs are actually active. In the extreme case, this mismatch might mean that an endpoint believes that its peer has enough CIDs available, while it actually doesn't have any CIDs besides the one it is currently using, which would then make it impossible to migrate.
At the very least, the indistinguishability between 1. and 3. leads to some non-trivial reasoning about what the peer might or might not have done, if you provide more CIDs than the peer advertised at any point in the connection.

I agree with @kazuho that changing the "SHOULD NOT" to a "MUST NOT" would lead to a significant simplification here, since it would eliminate 3. from the list. With that change, a newly provided CID is active until it is retired. 

Furthermore, I don't think that there's any additional complexity here. On the receiver side, you'll need some logic to protect against a peer that is sending too many CIDs anyway. On the sender side, limiting the number to a constant value seems a lot easier than reasoning about which CIDs might have been dropped.

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