Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Martin Thomson <> Thu, 07 January 2021 05:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96B883A0127; Wed, 6 Jan 2021 21:05:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Sl4T7D6r; dkim=pass (2048-bit key) header.b=V9OkrWQA
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jOqZPAhif6_N; Wed, 6 Jan 2021 21:05:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89B5A3A011D; Wed, 6 Jan 2021 21:05:01 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 642075C012C; Thu, 7 Jan 2021 00:04:59 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Thu, 07 Jan 2021 00:04:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=TPcNc0rEmK/jB5jfa3/KaoXzfrTY W7siLePydlsZcnQ=; b=Sl4T7D6r1fKYelDKd5wDaJbYcTE+Nf4hpVo5He6IHCvM 73lUV/1MRZNVAjYfWo2bycwyc6GOUDijeB2cX2dA/3xl1JY5Chp9Es4ZWD/NzDuA TYeOAZlmM2jztUqHdFYshZNRHOafJJtjcpUhUsha4QjDQpUNPuIoVbORlHuhfdZY dL5FDyrl29rHns2TKvA6xoyAftMDMaYZoqPFsk7U2nfSHJS0GFyfn5FN/H29GG0Q TLV8ocHfu3hJ9wkVbZ3emn3/wzSoHtvEw+bD3aXAExBZlc8tBkHwXyEVpOremVId bDusBaRdMDx+ONlszLP3wwBXXy6GZNeaF+jhTEyhqw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=TPcNc0 rEmK/jB5jfa3/KaoXzfrTYW7siLePydlsZcnQ=; b=V9OkrWQAOH6fEBydZjF9HB nBaAmXThRThDCRoVkQp8T7ckodETnk/g7q3aJ23WJnzegchEY8Vk8/f8sZHkU1l+ o9Kv0RUJ7hK2S4Vcuh4pPJG2tKR0Q3r8uBG+sxyowOk9+5R5JnAk9LxjOAvY80zG X/77kT8DyrA+Ac3zoagyME+jtJx51V5jen/tzQrUl7/XVGOg1GcTyCtZbw5+hwtp mtxgbSgGfxOkiz6Wr3j9B5fEsfgbGWVK6lKK1P0u6Q1W5JKZ14tCV11ZVMwuGoYp oqwZwrKNCx1AeDdikTf51LcsxFeAa1q+S6jmSyybbR14GYUK0yYrKTPD0WGB1L2w ==
X-ME-Sender: <xms:epb2X_Ka9dVthUkrInu5DjK8n6j1Kw9M8F2kO9zYuXGzuueyqZGLlQ> <xme:epb2XzKB1r2Igi3Uyd27S04dgv1sk7QOo2kMoQ4cDm_cAfqfhnHpVdMJndqrILRMW DqLrSGo98IJYJqXFkg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegtddgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeehfeetudduudehtdekhfdvhfetleffudejgeejffehffevkedu iefgueevkeefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:e5b2X3tG4PnRzjQIIs6dyJMtUeYkk6NTQuO-ahO_Hq9dlvp--2mcKg> <xmx:e5b2X4bwF8z6L0jJPipv5BefLUzive4vW9ERwUts6NQcFeB6PDUp6A> <xmx:e5b2X2aRFZSDTMxwH18WxZcTWOOJ4dnNdiqeH0fo_yNnhNfGpykB2w> <xmx:e5b2X2HmW8h5-8qHvnO7WPYXrd4R_43DkhkUW2LNETkVUI77-5WVnQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E64F12014F; Thu, 7 Jan 2021 00:04:58 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Thu, 07 Jan 2021 16:03:44 +1100
From: Martin Thomson <>
To: "Rob Wilton (rwilton)" <>, The IESG <>
Cc:, WG Chairs <>,, Lars Eggert <>
Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Content-Type: text/plain
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 05:05:05 -0000

Responding to the DISCUSS only.

On Thu, Jan 7, 2021, at 04:43, Robert Wilton via Datatracker wrote:
> 1) It would be helpful to clarify what the expected behaviour is for an
> implementation that chooses not to support the spin-bit.  Does it just leave
> the bit set as 0, or is it meant to follow the same behaviour as if spin-bit is
> supported but disabled?

The working group did not reach consensus on what an implementation should do, therefore the document does not say anything specific.  Indeed, I will go further and say that we have pretty firm consensus on what is documented.

We did get good information, based on implementation and experimental experience, that filtering out bad values was easy, even trivial.

> 2) This may not be discuss worthy, but some of the spin bit behaviour is
> inconsistently defined between the quic transport and quic manageability
> drafts.  

As you correctly observe, the transport draft is authoritative in this regard.  As the manageability draft is not yet finished, I would expect any inconsistencies to be addressed there.

> But my two main discuss questions/comments relate to whether the spin-bit, as
> specified in quic transport, achieves its goal.  I appreciate that there are
> individuals who don't think that it is required at all, conversely some network
> operators believe that they will lose vital information needed to help manage
> their networks, and presumably we are trying to find a pragmatic compromise
> between these two positions.

I would not say compromise, but rather that this is a mechanism that we know is acceptable to (some) endpoint implementations and know to be valuable to (some) network operators.  It is also optional (for both), relatively low cost to specify, implement, and deploy.
> 1) I find it hard to understand why a server is allowed to independently decide
> whether or not to support the spin bit on a connection?  Shouldn't the client
> (or administrator of the client system) that opened the connection be able to
> choose whether they want the RTT to be monitorable via the spin bit?  What is
> the reasoning for allowing the server (or server administrator) to be able to
> independently be able to decide what is best for the client?

The consensus of the working group is that active spinning must be made independently by either endpoint and that having an endpoint dictate the actions of its peer for this feature was not desirable.  Hence the design as documented.

> 2) In the case that the spin-bit is disabled, I don't understand the benefit of
> injecting a random spin bit value in each packet rather than always setting it
> to a per connection random value.  It seems that whether or not the randomness
> is injected, it is expected to be feasible to extract the RTT for those
> connections that are genuinely spinning the bit (or otherwise the spin bit is
> entirely pointless), but it just seems to make it computationally harder to
> extract the signal from the noise.  Perhaps the goal here is reduce the ability
> for pervasive monitoring to occur, but that feels a bit like security through
> obscurity.

Randomness is an option, not a requirement.  Some implementations just send 0 or 1 always.

As previously noted, extracting signal from noise was proven to be relatively easy.  This was, I believe, what convinced those who wanted to read the spin bit to accept the consensus position (though I can't speak for those people).

> Some enlightenment for these questions would be appreciated.

I hope that what enlightenment I was able to share suffices.