IETF Logo Mail Archive

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

Marten Seemann <notifications@github.com> Tue, 31 March 2020 01:37 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 611333A175C for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 18:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 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_IMAGE_ONLY_20=0.7, 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 EFEiLQ_qYTDz for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 18:37:27 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321FA3A175B for <quic-issues@ietf.org>; Mon, 30 Mar 2020 18:37:27 -0700 (PDT)
Received: from github-lowworker-275fa97.va3-iad.github.net (github-lowworker-275fa97.va3-iad.github.net [10.48.17.64]) by smtp.github.com (Postfix) with ESMTP id 3066A5207DE for <quic-issues@ietf.org>; Mon, 30 Mar 2020 18:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585618646; bh=Ghw9coVah7L08cBC+Dwqv51UEpB2Rj3McAAfLIXGp0Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VJYffvgLpTPxuKN3p/6A6Z4jaor6bEhXZ8lkf1dQiorCVzRUMq9GQvQwv4fhdZp4C RFEGisN5q4wBLbbcCrOWJmzw+ogqxBCbLr4VJFCihO+lsZxMPJ5zelu6dVHxFJiWZW klH0XuFEfWwIFxL78MKqCF7utu9NZUnuYIOAfzCA=
Date: Mon, 30 Mar 2020 18:37:26 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK232FRLIYVCH4JYVVN4RZ75NEVBNHHCGFYIAU@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/c606345475@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_5e829ed620774_56e93facb9ecd95c48280"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/7Gsyj_cnchSgvxjs9SJEgXhao1A>
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 01:37:28 -0000

Reading through this proposal, I fear that this would be very difficult to implement. If the ACK for a RETIRE_CONNECTION_ID frame is lost, and endpoint cannot safely send a NEW_CONNECTION_ID frame with a RetirePriorTo, since this would cause the peer to have more than `max_connection_id_limit` RETIRE_CONNECTION_ID frames in flight. In order to safely use RetirePriorTo, this endpoint then would have to track receipt of the ACK frame. I'd very much like to avoid the complexity associated with that.

-- 
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#issuecomment-606345475

v2.23.0 | Report a Bug | By Email