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

Mike Bishop <> Thu, 07 November 2019 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 143DA1200F5 for <>; Thu, 7 Nov 2019 11:45:48 -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 RU_fmtZwpJd4 for <>; Thu, 7 Nov 2019 11:45:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDAE51200E0 for <>; Thu, 7 Nov 2019 11:45:45 -0800 (PST)
Date: Thu, 07 Nov 2019 11:45:44 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573155944; bh=B8ZVcA9AsNuf0fddYaQz5HUaKlJFuaaBiyGeTEvXZbw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FOhG7GN71dDPNnyiY3rOxwL1jE1JDmo5UrjOosmWv/E75vKr4Sj8lckn211+I3ovX EoHLRBi9NrB4ACPcT6Rw0SBiXEuzeVt8UNj3Kv+kk+1i4i2W0Fl82WgdBjD3Pwnr5B Au1tyk2pNKa9g8UtBrsSymL12GENQWDVZTN1g2no=
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_5dc47468adce7_6ee83ffb5decd9642087f"; 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: Thu, 07 Nov 2019 19:45:48 -0000

Another potential pitfall of "MUST NOT":  Assume you've filled the peer's quota, but now need to revoke all prior CIDs and start a new generation.  You have to send at least one NCID to carry the RPT and give the client something in the new generation of CIDs.  Depending on the client's implementation, the limit might be exceeded during the processing of the frame.

This can be addressed if the client takes actions in this order:
- Retire all unretired CIDs <= RPT, queuing the RCID frames for transmission
- Add the new CID to the connection
- Send the queued RCID frames using the new CID

During this transition, though, there are zero active CIDs on the connection.  A more savvy implementation might retire _all but one_ of the old CIDs (so data flow never gets stalled), install the new CID, then retire the last old one.  Of course, that gets trickier in a multipath world; you have to make sure that the one you keep is okay for the currently-active path.

What the client can't do is add the new CID first, check the limit, then process any retirements; in that order, the limit gets breached.

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