Re: [quicwg/base-drafts] Add sequence number to NCID frame (#1821)

Kazuho Oku <> Tue, 02 October 2018 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 576731311AB for <>; Tue, 2 Oct 2018 15:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 eQOOqJxU4Qa2 for <>; Tue, 2 Oct 2018 15:07:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DB04131182 for <>; Tue, 2 Oct 2018 15:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=2Q/7ilFwHJMZrC8nQnmzRbgXFyQ=; b=ldpOsIgZ0jMsB3II IH+/FFvG78SkEOCU3Y2xxUIzlKFpQFqmwvlQAd/OxWh+WeYdJw7TKujALz4MVsOt hMAlvATj2r49Karn6rV5PvKEQNNFM4T2VCM8D1ERz1P1LKhFzJg/1w7NGeEo7QMa S+OsUpNXOIa05u944PIENBj2W44=
Received: by with SMTP id filter0708p1las1-23623-5BB3EC09-16 2018-10-02 22:07:05.974731284 +0000 UTC m=+2247129.352473699
Received: from (unknown []) by (SG) with ESMTP id wVjTbpGPQsqBOfxw547Niw for <>; Tue, 02 Oct 2018 22:07:05.870 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id D0830420337 for <>; Tue, 2 Oct 2018 15:07:05 -0700 (PDT)
Date: Tue, 02 Oct 2018 22:07:06 +0000
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1821/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add sequence number to NCID frame (#1821)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb3ec09c437a_77bf3fad23ad45c0623cc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1thO4KnZsiy1GQSgd/5xNz3953qMZlXQ0LKk 3qpcNEkaTRflpQ6++VA7bBIhFgGus3PYujMHYSJGe0FhiBpQ2acPDUx1L36vRhubTAy03aVCcBasoq phGc0030DSCu3+Ot8OFO3esLC8Eso7Ih+7COZI0WomQ7fhHK1XnNxb7XcAvk0QnSp72pwh4nXS8XYi A=
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: Tue, 02 Oct 2018 22:07:08 -0000

kazuho commented on this pull request.

> @@ -3285,8 +3292,10 @@ zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID
 frame as a connection error of type PROTOCOL_VIOLATION.
 Transmission errors, timeouts and retransmissions might cause the same
-NEW_CONNECTION_ID frame to be received multiple times. Receipt of the same
-frame multiple times MUST NOT be treated as a connection error.
+NEW_CONNECTION_ID frame to be received multiple times.  Receipt of the same
+frame multiple times MUST NOT be treated as a connection error.  A receiver can
+use the sequence number supplied in the NEW_CONNECTION_ID frame to identify new
+connection IDs from old ones.

> I think we need to require the sender to always increase by one.

On the flip-side, does it require the sender to have a window of CIDs (i.e. the maximum number of CIDs in-flight)?

I ask this because unless we have such maximum, it is impossible for the receiver to enforce the rule.
If we have an enforcement, then the receiver could use a simple data structure (like holding the most-recent N CIDs where the recency is identified by the sequence number). But otherwise, the receivers need to be aware that the sender can try to consume large amount of state by sending a huge gap...

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