Re: [quicwg/base-drafts] Timer interval for retire the connection IDs (#3215)

Mike Bishop <> Mon, 11 November 2019 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 704E0120828 for <>; Mon, 11 Nov 2019 12:43:50 -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 9EPTsvTBUYVR for <>; Mon, 11 Nov 2019 12:43:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83DD7120825 for <>; Mon, 11 Nov 2019 12:43:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CA506520420 for <>; Mon, 11 Nov 2019 12:43:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1573505027; bh=0V/F/IkpTrQQ9+WjyET55d7BDroNNHFj0dDKTgEyIKg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hUyJk91ijbgMO/g8yYXMpkv4T6YZ8vcrmKE9ezTEcWYuecBSyXMjr/yzvNXUwvy7U DpuBH48389adyzwFzFd3xuIwx7ouDSwb7BaNVnMPnvC0CShS+r+y+9qGVj40qtpjdM f3akHa2DatL9vejUOW6fwmoPtclHcbkaYdMCyEJ0=
Date: Mon, 11 Nov 2019 12:43:47 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3215/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Timer interval for retire the connection IDs (#3215)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc9c803bac3c_4e393fb3c22cd96c16591cc"; 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: Mon, 11 Nov 2019 20:43:50 -0000

It's tied up in why you would retire CIDs.  Various conditions mean that a CID issuer's infrastructure might no longer be able to honor old CIDs (i.e. recognize them as valid and get them to the correct recipient).  However, you usually either know that's coming or can extend the period with some temporary extra state.

The CID issuer will stop accepting the CIDs in question 3 PTO after sending the frame requesting retirement.  That 3-PTO period covers transit time to the peer, any time the peer decides to wait before it stops using the old CIDs, the return transit time for any packets that were already in flight before the peer stopped, and any extra time those packets might have been delayed.  If packets arrive late, they will not be processed and will generate stateless resets.  Those shouldn't be connection-fatal; if the peer has dropped the CIDs and corresponding tokens correctly, then they won't recognize the stateless resets as matching the current connection and will drop *them*.  But you've caused packet "loss" in excess of what happened on the network if you let it get to that point.

This is advice that the peer not wait more than 1 PTO, to make it likely that the issuer is not still receiving packets with old CIDs after the 3-PTO timer has expired.  It's an arbitrary period, no doubt, but it's a better arbitrary period than anything else we've come up with.  Alternative suggestions welcome.

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