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

Kazuho Oku <notifications@github.com> Fri, 27 March 2020 13:20 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 F1F873A085B for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 06:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 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_28=1.404, 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 OYLZCe5wVOgw for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 06:20:18 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838383A0765 for <quic-issues@ietf.org>; Fri, 27 Mar 2020 06:20:18 -0700 (PDT)
Date: Fri, 27 Mar 2020 06:20:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585315217; bh=BcixCd3mwdL4zX0Ni3qQ1bBXDUSLp/W0DzPGK0YiByE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rgN4JErw7eaPhirSkVd/EL6HaP7FKJrYSrb/GHso4W2dJixmNhnrrKMvUG/GvanvX xKmsujGR4FaXFri3DdGvoWO1LMXcy33SdcqYssDTzWQw2WeyqyLw8AAVCfHZiQ0YqI pCaN95Ip6dtbKXUUIbvMX6JxVX4IjOvo3Nih839w=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2N77INAQLW3IRW4XF4RHPJDEVBNHHCGFYIAU@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/382848451@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_5e7dfd91b016b_6edb3fe33f4cd9681512f0"; 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/rnzhqXuaw0B1NOhYPldCVa3LabU>
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: Fri, 27 Mar 2020 13:20:20 -0000

@kazuho commented on this pull request.



> @@ -1069,6 +1069,18 @@ 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 MAY elect to only send or retransmit RETIRE_CONNECTION_ID frames
+with sequence numbers greater than or equal to the highest Retire Prior To field
+received minus its advertised active_connection_id_limit. This bounds the

> I don't want to force retirement to be in multiple phases in edge cases like this, but I think it's fine to limit RCID to max_connection_id_limit outstanding frames. Later, when some RCID frames get acknowledged, check if there are more CIDs that need retiring. The case when the limit is exceeded needs to be handled in some way, so I'd rather have that code hit very infrequently than basically never.

I think I agree that tracking 2*max_connection_id_limit of RCID frames in just one way taking care of these edge cases. I'm fine with leaving it up to the implementations how they would deal with this problem.

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