IETF Logo Mail Archive

Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)

Eric Kinnear <notifications@github.com> Mon, 11 November 2019 23:55 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 7C63C1200F7 for <quic-issues@ietfa.amsl.com>; Mon, 11 Nov 2019 15:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 Q8Y8PosqBqnG for <quic-issues@ietfa.amsl.com>; Mon, 11 Nov 2019 15:55:28 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8668E1200B6 for <quic-issues@ietf.org>; Mon, 11 Nov 2019 15:55:28 -0800 (PST)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 13A986A0E34 for <quic-issues@ietf.org>; Mon, 11 Nov 2019 15:55:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573516527; bh=aFvc0Ei0+si1FRzH5vWQwoenMZ6aTiUGCCZOET7vrXs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XV0kEpfuqYCqPHxFXBdDx+FgVS/SPfGO36ujcTOhWyHGYkKRLuOGhhOGq31A27wbj i8W/dbVEPgGSiQB3qSV2ZyQmfhXXRf5Z82VRq1lh4iiI6+uf8K+qYY60y4qC2SDLTH qsQYZtYwuQAm3mXAKALTCx8lSTEHfPhLD7vY9QY8=
Date: Mon, 11 Nov 2019 15:55:27 -0800
From: Eric Kinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4FVNTNOA65RMYAQ5N324TW7EVBNHHB5Y6ONQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3193/552671227@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3193@github.com>
References: <quicwg/base-drafts/issues/3193@github.com>
Subject: Re: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc9f4ef4617_417d3fb3c22cd96c29390c9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/RHIolbPTrV0a9I7gVe8utqA_lns>
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, 11 Nov 2019 23:55:30 -0000

Right, I think the issues about packets that are already enqueued, etc. are more for the person requesting retirement of the CID to know that some packets might still show up (although potentially not after the ACK for the NCID frame that had RPT if they're all in the same queue? Not sure I'd want to rely on that ordering even before looking at the network). The endpoint that is retiring the CID can simply stop sending _new_ packets with that CID and be fine.

And leaving it up to the implementation but making a note that it's not a problem to retire/replace right up to the limit sounds good to me. đź‘Ť

-- 
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/3193#issuecomment-552671227

v2.23.0 | Report a Bug | By Email