Re: Structuring the BKK spin bit discussion

Kazuho Oku <> Wed, 31 October 2018 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 633BE127332 for <>; Tue, 30 Oct 2018 20:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yGL23tIswHcO for <>; Tue, 30 Oct 2018 20:22:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAED7124C04 for <>; Tue, 30 Oct 2018 20:22:35 -0700 (PDT)
Received: by with SMTP id g26-v6so12170503lja.10 for <>; Tue, 30 Oct 2018 20:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=79yD4oHBfcWzISnO1PUGjDZeYuf/DtVtzxY0AgNoyIw=; b=G1WCDbClML2UkCly9HjVmQkX7x5pZZS2fv3JYiX/zKogcGUuRqJ3fz8gfeb1Skmdbk MW1SQ7sJPBtepgW6jZzcUezevPRONzZ68Y+DZfyOcNmbzJTnAIiIRlabpe9EzIb6xNeH SDpDqPPpd7WiY2q+r3pIja70On8A22aIrEF2chtn0qdb+U0K2PE0BPe/m1pZE1c63xdx 133yu4ziK4DxbWpMU3J1GdEey06lAdGqf4lIJPVvLO39M5zrSQBOAU96XMzXhosZTsCa gQZSPdPuXhbFFb+i9YxAlMUSl1oJUvviePrNNjgg3H6NG4v3sU1dLsa+ojpavwRJ9Jz1 JGHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=79yD4oHBfcWzISnO1PUGjDZeYuf/DtVtzxY0AgNoyIw=; b=EODBtdhf6U7qh80MhstaTGnylhSemJ6zMPp+33ckwJwEIBeQFSc2P8jKSe9pVhe6bs UAACtfqDtXCCoL1PywwkEdELVOsMXB+P+PbYAxXAycQmVlcNTmWDBKCoTyIIrXPUtzW5 O8VqtigU1RkYL99JBq8GcLvUj85YLY6cg5ZK1saF48YIU4PkdHuhz0cfE87xJLnIeFGM gN3wgzqTEn4JIz4ogh1SWMEcictoXuNTxbAWON8pPK0p4A3sVjMkCbQop6ab4PFACAGw AtpcAycuxz2PdUAR4MZYdZIu7lLJpUO0rI7hOYBdTDx0cu0iLJo2dqFospr1sw06R6GW ORNw==
X-Gm-Message-State: AGRZ1gIfJnmWhk1LvTBeGir/zAILykMd80TDNHiGok17z/OxJwoyIHDY u5u6ibsz0lZQUV17MZXBa9yUFJY/iZZ1yI9EUPQ=
X-Google-Smtp-Source: AJdET5clt3stQoP9trzUzw0jx/Rjx37CnpVf6f44YUk5XnYlOu4A/sjE7BPufrFtpFrn+J9F88jJDhfgCyu3kxqMkEc=
X-Received: by 2002:a2e:9d50:: with SMTP id y16-v6mr858033ljj.136.1540956153942; Tue, 30 Oct 2018 20:22:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <> <> <> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Wed, 31 Oct 2018 12:22:22 +0900
Message-ID: <>
Subject: Re: Structuring the BKK spin bit discussion
To: Martin Thomson <>
Cc: Christian Huitema <>, Mikkel Fahnøe Jørgensen <>,, IETF QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 31 Oct 2018 03:22:37 -0000

2018年10月31日(水) 7:55 Martin Thomson <>:
> On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <> wrote:
> > Mikkel is correct, we may not want a purely random per connection behavior, but rather something "random per destination". This would better mimic the opt-out behavior of a privacy-sensitive endpoint, which would always opt out when contacting a specific destination. If I had to implement it, I would not use a PRNG, but rather something compute the hash of a local secret and either the peer address or the peer name. That way, the client would opt out for all 16 Netflix connections, or for none of them.
> Or are we looking for random per-path?
> That notion would seem to tilt the balance more in favour of the
> "discretionary" option over the "negotiated" one on the basis that
> spinning/not doesn't become a linkability consideration.

Even though spin-bit is a per-path thing, I am not sure if the
probabilistic opt-out needs to be per-path. This is because what we
need to ensure is having at least some portion of QUIC packets flows
floating on each path not using the spin bit.

That can be achieved either by having QUIC endpoints turning off the
spin-bit for every path at a fixed probability, or by having them
turning off the spin-bit for every connection at a fixed probability.

Kazuho Oku