[quicwg/base-drafts] endpoints don't know how many connection IDs the peer is willing to store (#1994)

Marten Seemann <notifications@github.com> Mon, 12 November 2018 10:46 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 BA8D0129619 for <quic-issues@ietfa.amsl.com>; Mon, 12 Nov 2018 02:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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_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 jIF6gRNl4quL for <quic-issues@ietfa.amsl.com>; Mon, 12 Nov 2018 02:46:21 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.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 DD3A91292F1 for <quic-issues@ietf.org>; Mon, 12 Nov 2018 02:46:20 -0800 (PST)
Date: Mon, 12 Nov 2018 02:46:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542019580; bh=Ex4wFeCH6KUGOnxBcO4gyUVVXOTv1EcgKcBLj/WRI14=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=bWq47d4S2Z4/RxeVdBqsxXj1/9UH06Rc/GOHMSu7bgafotdvgmN+f+1Dgijd1uZj+ VlDTba/czR/PK3Hq2EC8WPO+a7o7HV1XZssToCFe2mkeMENhN3/6sWUIBaK4nTz9QG UVftbHGuUJ/2hkS9WK329uLCbLuERo0tngY60V44=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdaf41e5420545087173bdc8764062b6b02ed1d0992cf0000000118011bfc92a169ce16a20dde@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1994@github.com>
Subject: [quicwg/base-drafts] endpoints don't know how many connection IDs the peer is willing to store (#1994)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5be959fc1fe2d_38493f92760d45c429514"; 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/HFR0RvZEXszwtaTc60Bxl4X7lsU>
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, 12 Nov 2018 10:46:23 -0000

As discussed on the list and in #1992, the fact that endpoints don't know how many connection IDs the peer is willing to store, leads to some undesirable consequences, which I described in https://github.com/quicwg/base-drafts/pull/1992#pullrequestreview-173829561:

Issuing too many connection IDs doesn't hurt in the case where the server uses a deterministic routing scheme to associate connection IDs to connections (except for the obviously wasted bandwidth). However, there's a different approach (which I chose in my implementation). I'm keeping a mapping connection ID => connection around for every single connection ID I issue. This allows me to use very short (4 bytes) connection IDs. If an implementation like this issues too many connection IDs, and the peer starts dropping them, it will have to keep state for every dropped connection ID until the end of the connection.

I'm preparing a PR to introduce a transport parameter, which will allow an endpoint to declare how many connection IDs it is willing to receive. It's late in Thailand already, so please give me until tomorrow this time to finalize the text for that.

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