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 21:04 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 1F2D6126DBF for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 13:04:56 -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 lh4hTOuL5dDq for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 13:04:54 -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 0DD4C124B0C for <quic-issues@ietf.org>; Mon, 4 Feb 2019 13:04:54 -0800 (PST)
Date: Mon, 04 Feb 2019 13:04:52 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549314292; bh=2Wj4+MZG7oOWR8IY28M24D5TyvY1duSYqKKr337Tjyo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p6GYwT2CGARSYsmD4zuRPgZIbKm1rm3ZtZSuM8mWopnJUvVcYILMhJSuxM5Ia3gXa shtCCnmcJAxDSHFYFo12cOdIVwxHcFh/ZQ3Ik6N9vNPs7U+b2bwaP0yosyIqUyBr/w RrXvPfHZH9IB1se9ZZuP6pRDhgcLXXBC/m0AklYI=
From: erickinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8e3e3f1a6e6d5fd4b958ac113874b992e119a4b492cf0000000118706af492a169ce1833bfbd@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/460412266@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_5c58a8f4b7c80_6a7d3fdb906d45c4211489"; 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/BMbLUgvnm0DQ9uDpOJPBiknykyM>
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 21:04:56 -0000

@kazuho Yeah, I don't think that endpoints should necessarily do that, but I'm not sure we need more text or at least that specific recommendation. The issuer is in control of how much it's willing to give out and how much state it's willing to maintain. A consumer that wants to rotate through CIDs that quickly might try regardless of what we recommend, and if the issuer isn't willing to maintain that much state, then at some point it will stop issuing new ones. 

Since we can no longer retire the last CID, then that just means that the consumer ends up stuck on a single CID. That seems like a reasonable outcome to me. If any new text were necessary, it seems like it would be to expand "only issue how *much* you're willing to maintain" to be "only issue how *much* you're willing to maintain however *often* you're willing to issue it".

In other words, it seems like it could be nice to avoid adding more recommendations for consumers that take into account the tuple as well. Folks should be free to change their CID whenever they want, with the understanding that doing excessive things in any direction (requesting too many now that we have a TP, retiring too often, etc.) is gated upon whatever the issuer is willing to support.  

-- 
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-460412266