Re: [quicwg/base-drafts] introduce a max_connection_ids transport parameter (#1998)

Martin Thomson <notifications@github.com> Thu, 14 February 2019 01:08 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 CCABE130E27 for <quic-issues@ietfa.amsl.com>; Wed, 13 Feb 2019 17:08:13 -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_IMAGE_ONLY_32=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FagoTksVq5BJ for <quic-issues@ietfa.amsl.com>; Wed, 13 Feb 2019 17:08:11 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6192130DD8 for <quic-issues@ietf.org>; Wed, 13 Feb 2019 17:08:11 -0800 (PST)
Date: Wed, 13 Feb 2019 17:08:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1550106490; bh=QR46tpUIfezMJvUeTvwLz0sF5ZuNk2MchNV2F3CexNE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oaHq1daFe8XEDNljmwFoyVYI1QSmmP2imO5VPWitc1LEECohy9893jhWONxtO85MF cm3jNRPy4fDzSY3a+2DDJ0L5DpSz1Wo42dI6GeVIZqPFo3NMQQoXC9uuOrlmEZGVxg HNSY3qbWK6ANxU7U2IANzi1dJczz5T+BQq+RMQ9A=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab87d203c11a3a13ec3a4911fe5a5a2f51e9f2dbec92cf00000001187c817a92a169ce16a7e5d6@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1998/review/203527706@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1998@github.com>
References: <quicwg/base-drafts/pull/1998@github.com>
Subject: Re: [quicwg/base-drafts] introduce a max_connection_ids transport parameter (#1998)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c64bf7ad1967_746a3f892e8d45b8409fd"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/_nrKkKFlzeR6lqjHSCQ0d7sxWeE>
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: Thu, 14 Feb 2019 01:08:14 -0000

martinthomson commented on this pull request.



> @@ -3981,6 +3979,12 @@ A client MUST NOT include an original connection ID, a stateless reset token, or
 a preferred address.  A server MUST treat receipt of any of these transport
 parameters as a connection error of type TRANSPORT_PARAMETER_ERROR.
 
+max_connection_ids (0x000e):
+
+: The maximum number of connection IDs that the peer is willing to store.
+  This value includes only connection IDs sent in NEW_CONNECTION_ID frames.

The need for reciprocity in most cases that consume a connection ID does tend to lead to the numbers being approximately the same.  But it's not symmetric in the sense that they need to be equal.  The design is therefore asymmetric.  

If you consider a client that is moving between networks of questionable quality, they can burn connection IDs on futile probes, leading to greater consumption of connection IDs.  That suggests that a client might store more spares than a server.

-- 
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/pull/1998#discussion_r256655813