Re: The first octet

Martin Thomson <> Wed, 08 August 2018 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07DDB130E1A for <>; Wed, 8 Aug 2018 02:51:23 -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 yiDcMOp9YthG for <>; Wed, 8 Aug 2018 02:51:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30F0D130E1D for <>; Wed, 8 Aug 2018 02:51:21 -0700 (PDT)
Received: by with SMTP id w126-v6so2672381oie.7 for <>; Wed, 08 Aug 2018 02:51:21 -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=I9sQd/HHL10D9MixX3XLitmkgHql909kUe9BaGNNATA=; b=I5vFUl+3VVVDjmbYe7fPRAXWjDPWQvaB2hV2BT4/7Qtcchs2wZE7LplNBufEOniDsy wO7d1nBHDdagpao++wuaurn2+5oe6nAqfhVZHKQJPgJMwwPZxgHe8LJ5UbTNv3t/zJH5 dsUM0xbits+7QIvE04AEeMMGn6T4kBHQqKxmgyYO/wBgQ5I7QEhnUD13ssBVRrqbWboM xvDG83FLAvvHAuDM2Fe53KxIP4VELzlPhgXS0DVHKNBXNrv+uKfjQKcYlOQLND0B4A0s 25uUgd2EaRPsvwQ5a9d8pCvtMgI0vDojJGuvzDxdEzrYCQyA28BbOmOSxDVxRrcnLiPQ GyHQ==
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=I9sQd/HHL10D9MixX3XLitmkgHql909kUe9BaGNNATA=; b=d1MMA6lf1quq4k3swOqpRxN0NUKugqlMh8bdzD4g00OViuSvumFRDYNhfArJuvUX5X xXH8hvFNXd+jkTFQqXK+pwu7/NjzyG0qjqLcBeyRZvi+pl0084pe/gLDfFAwarcqaXpc oeNJP7Oginz95jRE+teGloWEPR5KoCXjCs2e1FpBWfR5WnamPe5ZAWJ0CW87eo24tQH/ UjfB+8I8k6QcAtnH/vo1dciKJEe+6VMt7cbsjep2AE8pD9mSkzSy+jqe+BG62jsjPlNB nslY8NxuiQz1f7pEsMPZ2yUFA8ztzYSF+md/uNjTTQ/j5TSLF+xprMpXohN1RnWCQk9K CsjA==
X-Gm-Message-State: AOUpUlF3RmMYgF3rv9Vjmp/Ql1EGw2NLAbbrCnYsA3B1QYLR2zsyXGUy X/GXAwVTpaydhMpbdlnd97N7q6aE2yewlbXZj6M=
X-Google-Smtp-Source: AA+uWPwGMK6h03+bndYMF4zpvtqJIrVnLnkjYk5sYcCED3pEJaw5APdUOETWM4dWpbrrHxa77bzeVoBegTOHrtxM0H8=
X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr2338392oib.272.1533721880421; Wed, 08 Aug 2018 02:51:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Thomson <>
Date: Wed, 08 Aug 2018 19:51:11 +1000
Message-ID: <>
Subject: Re: The first octet
To: Kazuho Oku <>
Cc: 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 09:51:23 -0000

On Wed, Aug 8, 2018 at 5:41 PM Kazuho Oku <> wrote:
> My understanding is that we do not avoid conflict in the invariants,
> but you suggest to avoid them in v2.


Yes, that was the idea.  The protocols we're talking about could have
the luxury of being able to negotiate versions carefully, and avoid
any version that doesn't suit.

> For example, is it the case that you think avoiding conflict in the
> short term is worthwhile, at the same time keeping the possibility to
> change the decision in the future versions of QUIC?

That is certainly true.  See Colin's response too.  He managed to
summarize the thinking here fairly well.

> Honestly, I do not have a strong opinion here, although I worry about
> ossification when we decide not to grease the bits. Therefore, I would
> like to understand why you think avoiding conflict in v2 but not in
> invariant is worth considering.

Yes, the risk exists.  We could, for example decide to try to mitigate
this risk by choosing something maximally bad for 7983 demux and force
folks who want to do that to define a new version, thereby generating
two variants in relatively quick succession and pinning our hopes on
that helping.  I tend to think that things ossify on longer timescales
than that and so am willing to risk those bits sticking for this gain.
For the short header, it would be exactly one bit.

Invariants is part of our protection here.  It might turn out to be
futile, I don't know.  But I would be very happy to define a new
variant that set that bit to zero.