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

Kazuho Oku <notifications@github.com> Wed, 25 March 2020 20:42 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 8CF2C3A0BE6 for <quic-issues@ietfa.amsl.com>; Wed, 25 Mar 2020 13:42:30 -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 SUUsuGWiAjeA for <quic-issues@ietfa.amsl.com>; Wed, 25 Mar 2020 13:42:29 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317373A0BD0 for <quic-issues@ietf.org>; Wed, 25 Mar 2020 13:42:28 -0700 (PDT)
Received: from github-lowworker-1dbcc59.ash1-iad.github.net (github-lowworker-1dbcc59.ash1-iad.github.net [10.56.105.54]) by smtp.github.com (Postfix) with ESMTP id 42F932C15EB for <quic-issues@ietf.org>; Wed, 25 Mar 2020 13:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585168948; bh=aYV65IcePkBX9M0ud4zH/ghzQ/rM3d8k90ZDSqg/tkI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p90UIYsMljn3CSQQpbBnkRDYQeA5lQw6R65Y2Ejo+oD5xHI+9U3yZHdWHwUqGS5fu npLXJledchThAH59ZdoTUcLJme31rb79dp7XlI8XC4UupFdZEOIXHXR0EBzbjcrSeC OFkPFjdsNHDIrXQ3sJ07POWFH1bjkSfwDnqnqQg8=
Date: Wed, 25 Mar 2020 13:42:28 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2COOJKDEICU6YI27F4Q6RTJEVBNHHCFAMG5E@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/604076404@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_5e7bc23436196_1973fb40d6cd9689035b"; 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/9ro31tPijvYa_aRC1fgC__xAI9c>
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, 25 Mar 2020 20:42:31 -0000

@ianswett 
> The other option I can imagine is to make the RETIRE_CONNECTION_ID frame cumulative, which provides a strong incentive to use connection IDs in order. Though we may have to make an exception for the connection ID in the received packet if we did that.

While I won't say that's impossible, I'd argue that the design is going to be complex.

When CIDs are used in a legitimate manner, they are not going to be retired one by one. A CID is retired when a path using that CID is abandoned.

Consider the case where an endpoint has 4 active CIDs (CID0 to CID3), and two paths. One path could be using CID0, the other path could be using CID3. When the endpoint abandon the path that is using CID3, it has to retire CID3 but it cannot retire others.

@MikeBishop The amount of CIDs that can be sent on wire at a time is restricted by the CWND, therefore there is no guarantee that you can send RCID frames for all CIDs that you want to retire at once. In other words, I think the approach at best collapses into what @martinthomson has proposed (i.e. leaky behavior).

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