Re: [quicwg/base-drafts] Required state for retaining unacked RETIRE_CONNECTION_ID frames is unbound (#3509)

Kazuho Oku <notifications@github.com> Mon, 30 March 2020 04:09 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 9E0463A0A4A for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 21:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 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, 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 WYhaD8ACqMYG for <quic-issues@ietfa.amsl.com>; Sun, 29 Mar 2020 21:09:47 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B4B3A0A47 for <quic-issues@ietf.org>; Sun, 29 Mar 2020 21:09:46 -0700 (PDT)
Date: Sun, 29 Mar 2020 21:09:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585541386; bh=IzYzLnVSqh1jd7CEC7YqBGRWHlmcuymRieQy2e3AV6Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=e/NTFpyBqcFK+mhO8mYNoQnHOKneiMrAdd94cV5PXeNLL+pI/k/3QUo2oa4OEuMN4 BiEc9/O8Os6hRWLAW4yz+kqhC+mIM/L3aH+1Jwl92ZrNTD6Z61dRsq4EDZxUTFPx8D i+fnKApXjE76WkfOftH+dcAjHlBt4/vfPP3JHNZc=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYRRPPK7NMIMZAC7SF4RVJAVEVBNHHCFAMG5E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3509/605771367@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3509@github.com>
References: <quicwg/base-drafts/issues/3509@github.com>
Subject: Re: [quicwg/base-drafts] Required state for retaining unacked RETIRE_CONNECTION_ID frames is unbound (#3509)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e81710afef3_7dd83fac01ccd96c4468b0"; 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/Mu_2YxupxK06YEk0drHWKUUZRmw>
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, 30 Mar 2020 04:09:49 -0000

@martinthomson 
> I know that you have characterized this as "leaky", but I'm not sure that I understand exactly what is being leaked. Nothing is lost in #3547, except that the endpoint requesting retirement has to tolerate a potentially extended period without old connection IDs being retired.

In the approach we take in #3547, there is a possibility that the issuer of the CID might not receive RCID frames that the peer sends, when the issuer is issuing new CIDs at high rate and the receiver is also consuming them at a hight rate. That is the consequence of endpoints limiting the amount of inflight RCID frames it tracks.

I think we can provide advice so that the "leak" would not be an issue in practice, and assuming that would happen, I am happy with #3547 being the solution.

I think #3553 is cleaner, but I acknowledge that it is more disruptive than #3547. Part of my intent behind creating #3553 is to see how a clean fix (in terms of state machinery) would look like, so that it can be compared against #3547.

> In case this helps, I have no big preference between #3547 and #3550. There is a certain elegance to #3550 that might tip me toward that, but it is slightly more disruptive.

As stated in https://github.com/quicwg/base-drafts/pull/3550#issuecomment-605540981, #3550 by itself only partly fixes the problem. I am not against adopting #3550 along with #3547 though.

#3548 is also a partial fix, I also think that it is a non-starter.

-- 
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/3509#issuecomment-605771367