IETF Logo Mail Archive

Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)

Kazuho Oku <notifications@github.com> Thu, 19 March 2020 23:08 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 6AA453A11D0 for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 kPbn5u92jUWf for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:08:12 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744923A11CE for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:08:12 -0700 (PDT)
Received: from github-lowworker-c53a806.ac4-iad.github.net (github-lowworker-c53a806.ac4-iad.github.net [10.52.23.45]) by smtp.github.com (Postfix) with ESMTP id 4E1378C0C59 for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584659291; bh=L72pSpBHwRTLAhG6EqB8lBqgTmatPDImvvGkIzI4PMw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xZ9nQ1YkOfeLVknJWawjgQ8DX07swK0dyjZBOoOyXSWjLG3pTkj6B+RNwxjzgY8Bj B/mN7gEl6SMjRWCq2eVM0WxTg9HY3uAbvDwo7VtsW3D6F/vo/CVYwIQObMIpmsQ7fN rDmmdZPDP3dBMRL1IgxTW+Cw9WlWR51FrXusbkWY=
Date: Thu, 19 Mar 2020 16:08:11 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZXM2EFBLQR3NUKNNF4P7OFXEVBNHHCFWJJQQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3534/601457153@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3534@github.com>
References: <quicwg/base-drafts/issues/3534@github.com>
Subject: Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e73fb5b3d90e_70d93f95e58cd95c5042d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/e3Qay7pwbTVhKtTvDS-dZc0XmF8>
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: Thu, 19 Mar 2020 23:08:15 -0000

> Simply appending 'if has not already done so' to the text above would do the trick I think.

I think this would be a nice clarification.

> As a related point, it would be useful to say that an NCID receiver SHOULD NOT immediately retire old CIDs solely as the result of the NCID frame, except when instructed by Retire-Prior-to. This can lead to infinite loops if the peer tries to keep a specific number of CIDs available.

I think we already prohibit such behavior through the use of active_connection_id_limit TP. Section 5.1.1 states: _endpoints store received connection IDs for future use and advertise the number of connection IDs they are willing to store with the active_connection_id_limit transport parameter._

-- 
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/3534#issuecomment-601457153

v2.23.0 | Report a Bug | By Email