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

Marten Seemann <notifications@github.com> Wed, 06 November 2019 05:24 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 []) by ietfa.amsl.com (Postfix) with ESMTP id C61AC120271 for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 21:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dkTSyI66CWrR for <quic-issues@ietfa.amsl.com>; Tue, 5 Nov 2019 21:24:39 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4730E12000F for <quic-issues@ietf.org>; Tue, 5 Nov 2019 21:24:39 -0800 (PST)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 9EC73C60C78 for <quic-issues@ietf.org>; Tue, 5 Nov 2019 21:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573017878; bh=a0euPZm1Chxj90xu73TbP6ug+CKMqX/wz4Ri8iS/0jM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=CgBrnJ6jAYIbcGzmnHkMlI3N7L12U0Q8IPfNI5B9CkyY8Rfwn4eaDt0CeiaDcKFpE PzJQTjVjv898BD2faDV0QAlXsSYPKIoN1ZtJASkVywserAjuGqQhfhbVBAYMn81lIY Fcd6fFKmiFCFRlPmYtg4Yf6GYdXWIgYQrGWz7cn8=
Date: Tue, 05 Nov 2019 21:24:38 -0800
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6FD2YIPYG5DWKLAAV3Z6FZNEVBNHHB5Y6ONQ@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@github.com>
Subject: [quicwg/base-drafts] active_connection_id_limit interacts poorly with Retire Prior To (#3193)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc259168f8b5_17c03fe9bd4cd95c278267"; 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/ignuDPCraA9lEv1kKhZ6zbcHUX0>
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 05:24:41 -0000

The `active_connection_id_limit` parameters communicates the maximum number of connection IDs sent in NEW_CONNECTION_ID frames that an endpoint is willing to store. This value is only advisory though, there's nothing stopping an implementation from storing more CIDs than this limit, and the peer is allowed to send more CIDs than this limit:
> An endpoint SHOULD NOT provide more connection IDs than the peer’s limit.

We don't specify any behavior in the case the peer provides more CIDs than this limit, but since retiring a CID asks the peer to provide a new CID, it seems like the reasonable thing to do would be to silently drop the CID on the floor:
> Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not be used again and requests that the peer replace it with a new connection ID using a NEW_CONNECTION_ID frame.

This means that a peer cannot fulfill its duty of retiring those discarded connection IDs when receiving a NEW_CONNECTION_ID frame with Retire Prior To set:
>  Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.

This, however, is not guaranteed, either. A peer might decide to send a RETIRE_CONNECTION_ID frame for a sequence number that it already forgot.

Furthermore, depending on how implementations decide with all these uncertainties, one could end up in a situation where an endpoint only has a single active CID available, but its peer assumes that it is still keeping track of `active_connection_id_limit` CIDs and thus won't provide any new CIDs. In this situation, the endpoint won't be able to initiate or respond to a connection migration any more, leading to a failure of the connection.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: