Re: [quicwg/base-drafts] The number of Connection ID is unbounded to NEW_CONNECTION_ID sender (#2403)

erickinnear <notifications@github.com> Mon, 04 February 2019 04:01 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 73FB11294FA for <quic-issues@ietfa.amsl.com>; Sun, 3 Feb 2019 20:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_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 PNAV5im3FfQw for <quic-issues@ietfa.amsl.com>; Sun, 3 Feb 2019 20:01:28 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BCB12008A for <quic-issues@ietf.org>; Sun, 3 Feb 2019 20:01:28 -0800 (PST)
Date: Sun, 03 Feb 2019 20:01:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549252886; bh=x9Q5x8qc79Hw4RddcwcWnqTtcg8t1owy59Qh7kNAIYA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XMBQQd8X/pod2Z1nuDl7jXs/5G/qjwP8dqhGTptojhML3FLhKrT9x2wwabBvNtVI3 sXEu58iOGu9dWjULzgRDhuCU9h6oABnz7bMq1blBUYQ9IwNfLM1JnxmeyOVRUPorww Z+/EMENDlkVVEZIonaXjD88EsMLQyeYO2iMf+/uU=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3f3b8fcabee102a8bba2b23609d0eebaca98b4b192cf00000001186f7b1692a169ce1833bfbd@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2403/460125027@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2403@github.com>
References: <quicwg/base-drafts/issues/2403@github.com>
Subject: Re: [quicwg/base-drafts] The number of Connection ID is unbounded to NEW_CONNECTION_ID sender (#2403)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c57b916ea737_207d3fe4334d45c018175ee"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/edh2FdEGcL6YHK3OoAFoVUBkH_k>
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: Mon, 04 Feb 2019 04:01:31 -0000

To add to this, I think the fundamental design (which, admittedly, a TP confuses a bit) is that the issuer should issue (and maintain with new ones when retired) as many connection IDs as it’s willing to maintain state for. 

So, if the consumer of the CIDs uses all the new ones and doesn’t retire them, it will eventually run out of new ones to use. 

My understanding of the suggestion to replenish when a new one is observed is simply to lower the chance of having the consumer of the CIDs run out while RETIRE_ frames are in flight (or potentially lost). If the issuer is already at the max they’re willing to maintain, then only issue new ones when old ones are retired. The associated assumption here is that a consumer would not be advised to retire all CIDs at the same time.  

-- 
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/2403#issuecomment-460125027