Re: The first octet

Jana Iyengar <> Mon, 06 August 2018 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9926130DEF for <>; Mon, 6 Aug 2018 12:36:24 -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, HTML_MESSAGE=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 s8KT_TyWEJqE for <>; Mon, 6 Aug 2018 12:36:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97A4E12F1A2 for <>; Mon, 6 Aug 2018 12:36:22 -0700 (PDT)
Received: by with SMTP id f8-v6so11549723ljk.1 for <>; Mon, 06 Aug 2018 12:36:22 -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=S74jCGpPws1llwI8seL6JYqSqcyHDfYJbqENxEqZVyc=; b=mXjHPBxdk9MxKfC81ifXaLb1q/naYqlQOMgTG+tB5+IB/g+vGv53jrHsJRKcp39NHy HWf40Sc0m6MzQG5viY57KNLiVGc9Qg7vPfNhfLiONBH9x4UCzGztF6B7w1z/WIYZqJYj 5Pi84QE1L3lfHJNj6fwZNI/3EU8bbvG6bkNHUXOk0G3Tsnd7+Wqdos6ZvD3mXtC/LfqT 6Ph+FgUzgmacd5YNxQg0eD+9HN+AYCJZiGMkyj6Nv17VZr1muOUg4aPDaAxgB8tsm6Xn FWfKEIdD6y79iyYO5oi8yr/rRuhCds08OlTbpifkOs6rnruGPjhIkBu4c0EXeWqWXxLR kO2w==
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=S74jCGpPws1llwI8seL6JYqSqcyHDfYJbqENxEqZVyc=; b=pvCaHYZ80+afwTaybrXEfIbFcZpmAwBHKo2PGwhBnkuws2rpajt1lILM5IZ2Km+Z1V lPfh2P2IeK+i5m7M9tZn2xK62LW6SJYDIlXwlbNW0SLU3PkUKT0rU6hA/1PCfy28DHa9 UcNK+rK5Gg5Vvmx59SbuujOZNC6UazdV5e3/R8wtcBXBPzHdpBGvxCiZLStofzHFu3PH 4BZVUmAUGPd11OiK9Jz3WU6O/QD2VqdaEiUaj6N656DV1OYoGsfTPn/3s3229k4NVSkt bOsgXP4i/tRekUzJqNUq+WApY/tnQPeiTL4L9wq1BviPFUNeMFWaaPFXu51TYWSWEoME n6Sg==
X-Gm-Message-State: AOUpUlG5LRKAuon/T+k4kTWGYfpYz5QYi3TUyq6987ALXzI2A4GHG7jM 6+D+Prno8zThm0DxVrv+sxnhfLtGPVSUOE5GCNs=
X-Google-Smtp-Source: AAOMgpcpxYzE7E5rJ6OdMDqmpVwysVnesjdDdXhWIYXiLd4meUUWxoMv47BejoK6NwC/sNp2nZ16izUpmNz+Oy6cJMk=
X-Received: by 2002:a2e:998e:: with SMTP id w14-v6mr1389707lji.7.1533584180686; Mon, 06 Aug 2018 12:36:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jana Iyengar <>
Date: Mon, 6 Aug 2018 12:36:09 -0700
Message-ID: <>
Subject: Re: The first octet
To: Martin Thomson <>
Cc: QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000052b63d0572c9648a"
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: Mon, 06 Aug 2018 19:36:25 -0000

Hi Martin,

Thanks for raising these questions. I agree that we should at least agree
as a group on the principles for resolving these questions, so I'll respond
on the ones you've suggested.

> 0. (This should already be agreed, but I'm repeating it because it's
> important.)  The low 7 bits of the first octet are version-specific
> and can change in the next version of the protocol.


> A. What do we want to do with unused bits?  Do we want to ensure that
> they are always used?  Or can they be reserved?  If so, how would they
> be reserved (fixed values, random values, greasing, etc...)?

I would strongly encourage us to always use unused bits. I think what we so
far is quite good, and for the rest of the unused bits, I'm starting to
like Christian's idea of using different versions.

B. Should things in the first octet be encrypted where possible (for
> example, using an extension of packet number encoding).

Yes, but we need to do something where the first octet is not greased
(Initial, for instance). And what we do there could also be done where
encrypting is inconvenient.

C. Should packet number encodings should be consistent between long
> and short header forms?

I don't think I have a strong opinion on this yet, but I am leaning towards
consistency. Let's not add another type of parsing if we don't need it.

> D. What should we do with key phase?  This was an open issue from the
> stream 0 design team, which might alter the outcome here.  I have
> another email that covers this in more detail.

(I assume we'll discuss this in the other email thread then.)

> E. How should we accommodate multiplexing?  For me, the big questions
> here are whether we allow for RTP to collide with the long header and
> which of the protocols we privilege by avoiding with the short header.

So some thoughts, and I'll admit to still not fully being able to reason
about this clearly. It seems to me that the connection ID in short header
packets ought to be adequate for demux. For long header packets, again,
after the Initial and 0RTT packets, the DCID ought to be enough. If that's
true, then we want to avoid conflicting Initial and 0RTT types with RFC
7983 types, which at least reduces the problem. We can figure out where to
go from here, but does this agree with your understanding of the world, or
am I off in the weeds?

- jana