Re: The first octet

[Jana Iyengar <[e-mail]>]

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.
>

Agreed.


> 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