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

Marten Seemann <> Wed, 14 November 2018 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDB6B130E58 for <>; Wed, 14 Nov 2018 05:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j4lT6FFcsvQc for <>; Wed, 14 Nov 2018 05:40:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B483130934 for <>; Wed, 14 Nov 2018 05:40:45 -0800 (PST)
Date: Wed, 14 Nov 2018 05:40:44 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1542202844; bh=qDh97Zege4L4KWtcNj6ggbSI6Xa3dxrPIOhueoeFEVw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FXRhrVgIFyywEsSNHAUsaB8y+xrv3zmSZqVbQLWhF5zxvynAzhLFRuUoKwPVvkiiP HgP93a8iTyhCUtwkVt3/KBfEKGFxfvyrULqnVYyQb+zE6n7JhJBNhQDVFpumG8xLCI k+fiARlKLYYwLSQaddrvL1qwUoiFAwj2KdixSvG0=
From: Marten Seemann <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1998/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] introduce a max_connection_ids transport parameter (#1998)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bec25dc32aa5_22f03ff0230d45b4455f8"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2018 13:40:47 -0000

marten-seemann commented on this pull request.

>  An endpoint SHOULD ensure that its peer has a sufficient number of available and
-unused connection IDs.  While each endpoint independently chooses how many
-connection IDs to issue, endpoints SHOULD provide and maintain at least eight
-connection IDs.  The endpoint can do this by always supplying a new connection
-ID when a connection ID is retired by its peer or when the endpoint receives a
-packet with a previously unused connection ID.  Endpoints that initiate
-migration and require non-zero-length connection IDs SHOULD provide their peers
-with new connection IDs before migration, or risk the peer closing the
+unused connection IDs. Endpoints store received connection IDs for future use.
+They advertise how many unretired connection IDs they are willing to store in
+the transport parameters. An endpoint MUST NOT provide more connection IDs than
+this limit. An endpoint MUST treat receipt of more than this number of
+connection IDs as an error of type CONNECTION_ID_LIMIT_ERROR. If an endpoint has

I regard this as an equivalent to flow control and stream ID flow control. We have errors there if the peer violates a limit. It feels weird to me to set a limit, but then to silently tolerate a violation of that limit. And it will be a lot easier to develop compliant implementation if we actually enforce the limit.

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