IETF Logo Mail Archive

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

Nick Banks <notifications@github.com> Fri, 27 March 2020 18:53 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 458153A0A2A for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 11:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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_20=1.546, 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 MCEXqSk2XqPQ for <quic-issues@ietfa.amsl.com>; Fri, 27 Mar 2020 11:53:46 -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 16FB93A0926 for <quic-issues@ietf.org>; Fri, 27 Mar 2020 11:53:43 -0700 (PDT)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 2F0328C1179 for <quic-issues@ietf.org>; Fri, 27 Mar 2020 11:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585335222; bh=CxAfKpyp3XhC++as1mwlwGOupTHm2qyXhEPk5E6pJsI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DFXgQQ/pz2IQM0sgDrWmzBJ1Rp0MzgWhqoF/tBdrSgMuYoLOPbovZG0ql1/CZ9pof zRBXF5wz2w5QiAknIzgRV+P5QJ0uMfuuCIN36xOXaCZvbBI4fQX4dew0/zt/Xs4nwG Wvjqqdl//MkJ78kS36CjhAoiCfvEHHWBoLjAE0To=
Date: Fri, 27 Mar 2020 11:53:42 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK42YICDWDTG6UG6AK54RIWLNEVBNHHCFAMG5E@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/605211494@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_5e7e4bb61f587_5aac3f9b9d2cd968566ef"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/_f0FXN7qJd6njYu7FJ_HcMdfEM0>
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 18:53:47 -0000

I know folks have been resistant to changing state based off receiving an acknowledgement of a packet/frame they sent, but what if we changed how the RetirePriorTo works, and instead just required the packet containing the frame to be acknowledged, instead of requiring the RCID to be sent? Would this solve the problems?

This would mean the receiver of the NCID shouldn't have to track any additional state beyond what it takes to acknowledge the packet (which they have to do anyways); it just immediately throws away the state. And the RCID packet would only be used when the endpoint that was given the CID chooses to retire it.

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

v2.26.15 | Report a Bug | By Email | System Status