Re: [quicwg/base-drafts] Updated spinbit text (#2564)

mirjak <> Tue, 09 April 2019 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D597120819 for <>; Tue, 9 Apr 2019 07:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 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_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 VLHl-B2Q-ymT for <>; Tue, 9 Apr 2019 07:21:43 -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 8F2D0120816 for <>; Tue, 9 Apr 2019 07:21:43 -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=CtBbbe1UAB285P0k1ZPLqmFgXzg=; b=S8x9n5BQsLFZdO1V 4VUo1ksaw30PtiJksq1N3dsFuYCarlNW5GQ/lRAjuqJn3ShWEZZ+IKlgjKpK8GGb V2NQPvIoWL+vVGgWRCfDHayAxA3KfB0K1Zi63WiXSqMi3s3qIRBNvgJI/gY4pw0G HuiwWWmO3IxooYQfhJ8rvmGwPAE=
Received: by with SMTP id filter0854p1las1-5415-5CACAA68-5B 2019-04-09 14:21:29.010129069 +0000 UTC m=+49371.644295505
Received: from (unknown []) by (SG) with ESMTP id tSgxP3P7QueW95dBSP_rbg for <>; Tue, 09 Apr 2019 14:21:28.922 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id DF01AA8028E for <>; Tue, 9 Apr 2019 07:21:28 -0700 (PDT)
Date: Tue, 09 Apr 2019 14:21:29 +0000
From: mirjak <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2564/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Updated spinbit text (#2564)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cacaa68d34d9_63033fb0520d45c0102253b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1gAECpcJqOggvDcpD46jlNb9gxC03DzEa8xn R9dJgs1gPFzzON3rYjFfzTbHJ6nBkgAFirS35RyDLJrzigFwAy7HberLIr6/tGLKYDHOApD8a0uqZz 796zxX1JNRz0EEMDQgJbOKB22jAdpbHATKhOOlp0Kq6xIfsJPeFlVIFoBQ==
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, 09 Apr 2019 14:21:46 -0000

mirjak commented on this pull request.

> +the spin bit on a randomly chosen fraction of connections. The random selection
+process SHOULD be designed such that on average the spin bit is disabled for at
+least one eighth of network paths. The selection process should be externally
+unpredictable but consistent for any given combination of source and destination
+address and port. The selection process performed at the beginning of the
+connection SHOULD be applied for all paths used by the connection.
+In case multiple connections share the same five-tuple, i.e. same source and
+destination IP address and UDP port the setting of the spin bit needs to be
+coordinated across all connections to ensure a clear signal to any on path
+measurement point, however that might not be feasible.
+When the spin bit is disabled, endpoints MAY set the spin bit to any value, and
+MUST accept any incoming value. It is RECOMMENDED that they set the spin bit to
+a random value either chosen independently for each packet, or chosen
+independently for each path and kept constant for that path.

In the network you have to handle both but per-packet randomness may be harder to filter ou, while always 1 or 0 is a clear signal. Especially if you look at aggregates too much per-packet randomness could render the whole signal useless, therefore I think recommending to do the right thing is important here, given this document is probably what implementers read.

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