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

Kazuho Oku <> Wed, 06 November 2019 13:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59B5612087E for <>; Wed, 6 Nov 2019 05:13:05 -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 qL44j6i2g27o for <>; Wed, 6 Nov 2019 05:13:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD624120835 for <>; Wed, 6 Nov 2019 05:13:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E88448C0C31 for <>; Wed, 6 Nov 2019 05:13:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573045982; bh=4Xk1Zydp70EByfSluaROO5Z+rE07a2F9WpUh+IdPlEM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2RLQVR4DjgwNK+AYzr3EZpHZAw+/niqBhdgsVWjIVytSYZbOVNdI71C55runyJu1s M88Aw44WX1nRIGStn0JlMHnOW+rOYyQXoHp0WpY1uqkHEdfN8qUm4mC7ZTaVef6ayQ uLyvXCBi6237yAfY4iNoV00haFPk7kxAJGvq1SeY=
Date: Wed, 06 Nov 2019 05:13:02 -0800
From: Kazuho Oku <>
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_5dc2c6ded6422_378e3fd4beecd95c212969"; 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: Wed, 06 Nov 2019 13:13:05 -0000

I think the model that @erickinnear's has described is accurate.

At the same time, it seems alarming to me  that we have failed to incorporate that model into the text.

Specifically, as @marten-seemann points out, we have the following text:
> Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.

and FWIW also:
> Connection IDs that are issued and not retired are considered active; any active connection ID can be used.

that both assume that all connections IDs are expected to be retired. But as @erickinnear points out, when the issuer provides more than what `active_connection_id_limit` recommends, those connection IDs are not expected to be retired.

I'd like to point out that the way we control the active CIDs sticks out from other "crediting schemes". For all other crediting schemes (i.e. MAX_DATA, MAX_STREAMS, MAX_STREAM_DATA), there is a hard limit. It is a protocol violation when the sender exceeds the allowed maximum. It is only for this active_connection_id_limit - RETIRE_CONNECTION_ID pair that we do not enforce the sender adhering the limit.

Considering these aspects, and the fact that implementors are complaining about the complexity caused by "SHOULD NOT," I think it's worth considering changing the "SHOULD NOT" of "an endpoint SHOULD NOT provide more connection IDs than the peer’s limit" to "MUST NOT."

The counterargument might be that it's an additional complexity; but I doubt if it's that important, compared to the importance of resolving the confusion that we have now.

As @erickinnear have stated, the issuer is excepted to stick to providing *N* active CIDs, where N is a constant throughout the lifetime of a connection. No other approach works. So the *complexity* that is to be added by changing the "SHOULD NOT" to "MUST NOT" is that the issuer would be required to set N to no greater than the value of "active_connection_id_limit" provided by the peer.

I think we can pay that cost for buying a consistent design (that avoids the confusion).

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