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

Eric Kinnear <> Mon, 18 November 2019 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 771CE12095A for <>; Mon, 18 Nov 2019 01:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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, RCVD_IN_MSPIKE_H2=-0.001, 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 t3Lvq0OiIYxO for <>; Mon, 18 Nov 2019 01:37:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0851812096A for <>; Mon, 18 Nov 2019 01:37:16 -0800 (PST)
Date: Mon, 18 Nov 2019 01:37:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1574069835; bh=3DG1mrwq558Am/26lIVxySDLyG9BlkQTs/Of7cw9kBk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CDQtU0cy5qNC6BzhANmR6zwzqVwIeRUogVOOybYlYzP3G86xDXXASLwqbwAA5hrP+ ubjjJcCtf3y20kG5+SM5mYB2kUG6IXuPu3TAXQ5pFuqELD9IuTpo88D93eQGLCO9OY LiZQloVQiWj4D5l/OtbTxE0NH/j45Fk3m0Rw5zvg=
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_5dd2664b32c7d_74e43fd3e36cd968335d1"; 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: Mon, 18 Nov 2019 09:37:23 -0000

Proxying from the PR in regards to enforcing MUST error if the limit is exceeded: 
> "MUST error" requires tracking. It's possible that an implementation might decide to drop some CIDs and reduce the number it keeps without closing the connection. "SHOULD/MAY error" provides the same deterrent effect for the issuer's misbehavior without placing a requirement on the receiver.

> We're requiring other limit checks (e.g. for STREAM_LIMIT_ERROR and for FLOW_CONTROL_ERROR), so I'd prefer to keep this a requirement as well.
>I don't think dropping should be regarded as acceptable behavior (although you can't prevent implementations from doing it), since a CID issued by an endpoint consumes state on that endpoint as well.

> I'm in agreement with @MikeBishop -- I would suggest changing this to a SHOULD error. This is different than the flow control errors, since an endpoint does not have to store all connection IDs that have been received.

> I might suggest having a design discussion in the issue (i.e. #3193) rather than here. There has been certain amount of discussion in that issue, and it seems to me that we have preference for MUST NOT.

> I'm not sure that I'm against the SHOULD, but I think the idea behind enforcing this was that an endpoint would indeed now need to store every CID it receives, and if it's not willing to store X amount, then it shouldn't have advertised a limit of X.
> And even if you still didn't store them all, you technically don't need to store them to keep track of how many you've been issued, which you'll probably need in order to cope with getting Retire Prior To anyways.

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