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

Marten Seemann <notifications@github.com> Wed, 06 November 2019 09:49 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 D7D8A12025D for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 01:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 2tZvvK7fhg1q for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 01:49:25 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AD8120255 for <quic-issues@ietf.org>; Wed, 6 Nov 2019 01:49:25 -0800 (PST)
Date: Wed, 06 Nov 2019 01:49:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573033764; bh=oFjgdM7ZMvD4SWZdWh8JXS0cOw87Pch5AjWnMml16OU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VOBRD5vJjt3gDTYMiAQGnlTuGXsHJ9AcM+mTLUrs9we800eaIP9Gfd5PostiWv77K aVyPzcDjJ9mDwlmEbfFSH1S40SwBJsWGdLU+JeFsJcen+KGMFUkAKd0pfEtttwoOv5 RTqp4uOA5BQQmWVecsiKMZ88CDnkarOrbqJrraV0=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2PCCSEV25R3QVKG4F3Z7E2JEVBNHHB5Y6ONQ@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/550232159@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_5dc297247e1d0_11d73fc225ccd964144650"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/feaSisIv_2IrT25jJvDJvZ5-f2U>
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, 06 Nov 2019 09:49:28 -0000

Dropping connection IDs worked out fine before we introduced the Retire Prior To field. We added that field in #2769, which was merged in July (about half a year after our discussion in Tokyo and the claryfing PRs).

> If/when the peer sends RetirePriorTo and requests that you retire them, you retire the ones you haven't yet retired and still know about.

That's not what the spec says (but maybe what the spec intends to say?). If this was the only issue, we could probably easily resolve this by changing the wording to something like "MUST retire the corresponding connection IDs that it still remembers" or so.

> Generally, that means that you get a replacement for those, so now you still have active_connection_id_limit CIDs. 

That might or might not happen. It all depends on the peer's assumption of what you did: Does it assume that you dropped connection IDs (if so, which ones?)? Does it assume that you actually enforced the limit that you announced in the TP by dropping all CIDs in excess of it?
The situation gets even worse when you assume that  a RETIRE_CONNECTION_ID frame was in flight just when the endpoint provided the new CIDs. In this situation, there's no race-condition-free view of how many CIDs the peer was actually storing, so it's not possible to know how many of the new CIDs were actually stored and how many of them might have been dropped.

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