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

Mike Bishop <notifications@github.com> Wed, 06 November 2019 19:36 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9717120142 for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 11:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwfIfj6Il2dT for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 11:36:23 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5E612010C for <quic-issues@ietf.org>; Wed, 6 Nov 2019 11:36:22 -0800 (PST)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 1929D6A0095 for <quic-issues@ietf.org>; Wed, 6 Nov 2019 11:36:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573068982; bh=aZBh2U6usB99BIlPYis4zZEgIryVheGflHacpBnwI2k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cAzqgUTULqcZLniRF1HbbiebiyyghiSBChrsdGis31zI4wKsM6e498hzXoDHiqYJt B8DP2Ju/ZJl2qJPrbGLrSkJrATu1d5LFwZdHBtKv49N0gy335+ROdKMkJ4tUwy9tgX MPTvvESHPblQkB2pqsu/tnyUOzI3/pb26MiVxWHg=
Date: Wed, 06 Nov 2019 11:36:22 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZXUE2EFFIXH6KWFZV32BJTNEVBNHHB5Y6ONQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3193/550467125@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3193@github.com>
References: <quicwg/base-drafts/issues/3193@github.com>
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_5dc320b69d67_37183f8335ccd95c14686d"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ZGrcyCnrc_tWvrpt5xOCxRC4Wv8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 19:36:25 -0000

I think a MUST NOT is reasonable; there was considerable pushback in Tokyo for reasons I don't remember clearly.  I don't think you can get out of sync provided the TP is at least 2.

The other possibility, as an implementation, is to track which IDs you've retired/forgotten.  Obviously, the point of not keeping all the CIDs is to reduce the memory consumption and this still requires keeping some memory.  But it's worth pointing out that you don't actually need to have the CID in hand in order to promise you'll never use it again.

For that matter, a naive implementation that wants to save memory at the cost of bytes _could_ retire every CID sequence number up to RPT upon receipt of an increase RPT value, whether it has previously retired it or not.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3193#issuecomment-550467125