Re: [quicwg/base-drafts] Handling of Retire Prior To field (#3046)

Eric Kinnear <> Tue, 17 September 2019 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 968C5120920 for <>; Tue, 17 Sep 2019 12:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.899
X-Spam-Status: No, score=-7.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MaH4-XwwMjfm for <>; Tue, 17 Sep 2019 12:52:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D78891208C4 for <>; Tue, 17 Sep 2019 12:52:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C3F4A120E for <>; Tue, 17 Sep 2019 12:52:12 -0700 (PDT)
Date: Tue, 17 Sep 2019 12:52:11 -0700
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3046/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Handling of Retire Prior To field (#3046)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d81396bf1796_1bb33fda0a6cd9684954ef"; 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: Tue, 17 Sep 2019 19:52:23 -0000

There was definitely lots of discussion around the requirement level here when this was added (see #2645), @nibanks asked: 
> why couldn't we make it a "MUST immediately retire" instead of a SHOULD? What reasons would an endpoint have to ACK the packets but not retire the CIDs at the same time?

There was good discussion following that ([start here]( and scroll down). 

My understanding of [where we ended up]( was that the endpoint being asked to retire a CID really SHOULD retire it or else the peer may stop responding to that CID. 

After the endpoint requesting retirement gives up on a CID and forgets about it, packets will either arrive with that CID or they will not. It has two choices, it can choose to process them if they arrive with the wrong CID, or it can drop them. The enforcement mechanism here is to stop processing the "bad" CIDs, not close the connection, especially as you take into account potentially delayed-but-valid packets.

I think the current stance of "really SHOULD stop using such a CID, but the other endpoint needs to be careful about enforcing that" is the right one, if there's a wording update that would help with understanding there, then it would be great to update the wording as an editorial issue.

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