Re: [quicwg/base-drafts] Limit RCID state (#3547)

Kazuho Oku <notifications@github.com> Tue, 31 March 2020 05: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 2FBDF3A1B84 for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 22:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 iT5C1v_rPE-1 for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 22:36:05 -0700 (PDT)
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 547B23A1B83 for <quic-issues@ietf.org>; Mon, 30 Mar 2020 22:36:05 -0700 (PDT)
Date: Mon, 30 Mar 2020 22:36:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585632964; bh=yhtm4tFBTlUEUiVY2ExHbjbIKLRXAH0McbLcgRWEAGs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SFFvykxc6v2SQ1h0c/mKu2V+UrdHHavlUnFwIsvDhIr1T8TeTGTJYA0b9B1nTHrG5 p6NdlPDCrP72fRvhGyGWwwmvQz5zIjMlNxhfDkGl1Qwsa0p5G3zYILTIN5Ovp56Ie/ 4nBgm9zVXrd1wb0z0znElDhgXRhTvbYh1VmlUPuw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZPSDCZ24DEL7GQLDF4R234JEVBNHHCGFYIAU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3547/review/384413902@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3547@github.com>
References: <quicwg/base-drafts/pull/3547@github.com>
Subject: Re: [quicwg/base-drafts] Limit RCID state (#3547)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e82d6c42c5e6_3b793ff42facd95c10103"; 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/qcvSaYppJMqJFJ7cp7Wbhrb8qH0>
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: Tue, 31 Mar 2020 05:36:07 -0000

@kazuho commented on this pull request.



> @@ -1069,6 +1069,15 @@ to cease using the connection IDs when requested can result in connection
 failures, as the issuing endpoint might be unable to continue using the
 connection IDs with the active connection.
 
+An endpoint SHOULD limit the number of outstanding RETIRE_CONNECTION_ID frames
+to bound the necessary state. In order to allow a peer to retire all previously
+issued connection IDs, the limit on the number of outstanding
+RETIRE_CONNECTION_IDs SHOULD be at least the active_connection_id_limit. An

> I see what you mean by the CID<sub>2</sub> example, but my counter would be that you wouldn't retire that connection ID because you were still busy working through the previous set of retirements. (This assumes that you don't or can't start to retire CID<sub>2</sub> before being told to retire the others.)

Yeah I think my view is that it is hard to implement such behavior without having additional state, because the peer can request an endpoint to retire CIDs. You can delay the start to retire CID<sub>2</sub>. But to do that, you need to have a delayed slot (i.e. state).

> Costs of discretionary activities are something people just have to factor in.

I agree. My complaint is that the recommendation of "at least active_connection_id_limit" is incorrect.

As we seem to be converging on adopting #3550, I've posted an example that does not involve the use of RPT in https://github.com/quicwg/base-drafts/issues/3509#issuecomment-606408197. I posted it on the issue as I think it is a part of the problem statement rather than the solution.

-- 
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/pull/3547#discussion_r400653972