Re: The first octet

Martin Thomson <> Wed, 08 August 2018 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47F7A130E00 for <>; Wed, 8 Aug 2018 03:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] 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 KJDNiJRNHOWc for <>; Wed, 8 Aug 2018 03:05:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B861B126CB6 for <>; Wed, 8 Aug 2018 03:05:37 -0700 (PDT)
Received: by with SMTP id v8-v6so2755034oie.5 for <>; Wed, 08 Aug 2018 03:05:37 -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; bh=sR0Iu8jto+vccc0ixsR/ACuxV6Vwb4JjxFTqIsxaIfc=; b=N2KcHwMev0RFZM2jEYFC17F+ZRyi2uI9FMAqIDvh9Ge7fdwn9+A4QKUeilN3Tlk+ez m9HrS/rAI3Wv1XHZBQiLrDs93Nb4AseEhBQJVPU4+6tgtBnPFlDMfmA9i9xkJKUWRJpe qlTxu00Y5d5/LpB1/SuHTA+vL+XFiJmCJe579dQ7dQnXP1KlacIaAtqUjqRBn8PINevR qLoEDY50qZlurpZfmGqUZ9lPabVZmwsRgEL6GjPx94xzHu7Brl52/dMKe3m3dXuIYIf7 3gricgn9+TZT9qubkEHHXjSKtWaL46YKmWTu33NBJSFhGwBm1V3uhES7idge8hK/xb/q aR7A==
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; bh=sR0Iu8jto+vccc0ixsR/ACuxV6Vwb4JjxFTqIsxaIfc=; b=N5Zva5oGUAYFjwq5129ZevbHeUT1TW9AwZ8mavOfJ5lslhxx+CTTHtxQhnXh2Pz6Jf C3It+FBhjZDcFgTaSLXgWr1DMnrZMd2uv+RlgwdxxI3nr122LyWGvrA5ph3G3VhGlot5 lkBMY0aMeghfeyu/enbB3LibRo07Q4NvVFtI75kXpeez5bpYSQSTX9+rADa0CCT5Kbgu 0KOAMKDrav1ePq0bb1PSQTxWSJ2ussOotm1RLAHlYrkUHKPl9x1x+bPB6Qf24RIPoldE 2TW4bSlqCPpOZRzRtNeixE+lRGxlttdgz1q0oTRdLxK64TOcY1c4f67YFqpz9cE/2300 4iQQ==
X-Gm-Message-State: AOUpUlGwxuPdTJY88uR0PYE2pLglfy/vzGjR/TXbNJUOt3hXu1/o5uBS PzyhrSTcN8fD+I/BrYad/SkeJ74TEQWQruThUl8=
X-Google-Smtp-Source: AA+uWPw567YiN3DUttMUn/fsZvQTJ+mV5XoxAB/O+oRZ/mFMnUCd6zVYLIKqAFI90GDbxMwu8b8/47W/Acz5vuG7zDg=
X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr2385813oib.272.1533722737041; Wed, 08 Aug 2018 03:05:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 08 Aug 2018 20:05:28 +1000
Message-ID: <>
Subject: Re: The first octet
Cc: Kazuho Oku <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.27
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, 08 Aug 2018 10:05:39 -0000

On Wed, Aug 8, 2018 at 5:50 PM <> wrote:
> Hello Martin,
> Since you're discussing spin bit allocation variants, maybe it's worth taking a
> step back: how strong is the "bit pressure" really ? Are we really fighting over
> the last single bits in an otherwise optimally packed protocol ? Or could the
> ~70 bytes of a typical ACK-only packet afford an extra byte without endangering
> polar bears ?
> The reason I'm asking is I'm wondering about the set of arguments that will be
> used to decide the final number of "s" bits:
>   - space: it's a sheer coincidence that, at some point, the first byte happened
> to have three seemingly spare bits, and that the "spin bit + VEC" approach also
> needs three. Your message seems to indicate that might no longer be the case,
> since you've got a use case for the spare.
>   - ossification and linkability vs need for measurement: this is the real name
> of the game, will be discussed in due time.
> I'm concerned that the second set might somehow be masked by the first one.
> How about the following alternative: (1) decide how many bits to allocate to
> measurement, fully focusing on the trade-off between manageability and key QUIC
> goals above; (2) decide where to fit them, including in a possible extra, hum, byte.
> What do you think ?

We agreed to reserve 3 bits.  If we decide not to use those bits, we
need to do something with them (octets don't get smaller after all,
and an octet used is better safeguarded than one that is not).  The
intent of this discussion is to prepare for the outcome of the
discussion in Bangkok.

I know you discussed taking more bits and even bytes, but the case
hasn't been made in this working group to my knowledge.  I certainly
don't think that's justified; it improved fidelity of measurements,
but the spin bit appears to be pretty good at that without the extra
overheads.  And overheads do matter (on that point, your claim of 70
seems overly large, if it's based on ACK encoding in gQUIC, the
differences are now significant enough that it might not be
representative - my estimation is that you might get as low as 28
octets, plus connection ID size for a typical, unpadded ACK, certainly
not more than double that).