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

ianswett <notifications@github.com> Wed, 01 April 2020 13: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 6E3FB3A0F2D for <quic-issues@ietfa.amsl.com>; Wed, 1 Apr 2020 06:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 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_32=0.001, 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 1Grpwh9wKDAR for <quic-issues@ietfa.amsl.com>; Wed, 1 Apr 2020 06:36:39 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1E53A0F6C for <quic-issues@ietf.org>; Wed, 1 Apr 2020 06:36:38 -0700 (PDT)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id 56CAC2C2273 for <quic-issues@ietf.org>; Wed, 1 Apr 2020 06:36:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585748197; bh=fCarW5kbIFypoDYIALeRjctsitcxjL0Q8EiGUitPYyQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fhhHOpckLdJa74r1Rm2Hgv6HUlPoCVNcdZLyHSeQwTftMwPA8jEXOA9d/BKK7oDSL 86zcs2Ee8mY67AtMWiOqtFqEEGBg3iYm1Be5wnA0L+oolt9OywT0uYtO+uU6IS8gd5 voDMJwE5yRqW2u6ALJpWJp2dHu7MVJNOi27XNNGc=
Date: Wed, 01 Apr 2020 06:36:37 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5O5UYLJFJHPIDMJIV4SB46LEVBNHHCFAMG5E@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/607253576@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_5e8498e548adf_32c13f971accd968779a"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/cvbueWXLOQ579zVqhFFn5rZfhi0>
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: Wed, 01 Apr 2020 13:36:51 -0000

@kazuho I don't think not sending RCID frames is that easy.  Tracking something that needs to be sent consumes comparable state to tracking it in flight.  Or are you suggesting a different algorithm that indicates a RCID frame doesn't need to be sent?

If the peer has to wait for one Retire Prior To to take effect before it's increased again, that leaves only the peer migrating really quickly and lost ACKs as the unbounded case. As @kazuho said, I think it's more likely a well-behaved peer would run out of CIDs in this case than any other failure mode.  I previously suggested stopping sending out NCID frames when the RCID frame limit had been reached to force the issue, but that just changes who has to close the connection.

FWIW, we already have sanity checks where our implementation closes the connection when a datastructure becomes too large.  The limits are high enough that they're almost never hit unless there is a bug, but they've been helpful in finding bugs.  I would advocate everyone have these.  @marten-seemann You'll never get to 0 transport errors.  Some implementations will have a bug, and some peers or servers will have faulty or corrupted memory.  For example, in Google QUIC we found we received the ClientHello on a stream besides 1 surprisingly often.

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