Re: The first octet

[<[e-mail]>]

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 ?




On 08/08/18 09:17, Martin Thomson wrote:
> Thanks for sharing your perspective Kazuho, I have a slightly
> different view, but it's fairly consistent with yours.  Reformulating
> the second question is good, and I too would like to encrypt this
> stuff.  It should be easy enough to do so.
> 
> I too like the common form for packet number lengths.  I can even see
> adding key phase to long header packets for the purposes of
> consistency.
> 
> This is my preferred layout for the case we have three bits for spin.
> 
> 1 t t t t p p p
> 0 1 s s s p p p
> 
> Where p p p is an encrypted key phase bit and two-bit packet number
> length (1,2,3,4).  I think that we can afford to have fix tttt values
> with no greasing.  Allocating four bits and using two of them isn't so
> bad.  By doing that we can choose types that don't conflict with RTP.
> It's not necessary, but it's very cheap.  The fixed bit keeps the
> short header away from most of the RFC 7983 protocols without costing
> much (you had a reserved bit anyway).
> 
> The extra fixed bit here makes QUIC short header packets conflict only
> with TURN channels from 7983.  That's totally acceptable and fairly
> cheap from our perspective.  If you are concerned about ossification
> of this bit, we could give it to the spin bit(s) and force the people
> who want this sort of demux to negotiate the spin bit into a fixed
> value if they care to have good demux.
> 
> If we have two fewer bits of spin, that's where things get
> interesting.  I would prefer to keep the same ppp bits, but leave the
> two spare bits unallocated, but encrypted along with ppp.  Encrypting
> means they can be forced to be zero unless agreed otherwise (MBZ
> normally means MUST send zero, MUST ignore non-zero, but I prefer MUST
> reject non-zero here):
> 
> 1 t t z z p p p
> 0 1 s z z p p p
> 
> The hit here is RTP.  We would need all type values so we end up using
> 0b10xxxxxx.  We can limit the damage by changing codepoints for 0-RTT
> and Retry packets, which can be avoided in most scenarios that use RTP
> (signaling FTW).
> 
> If we have no spin bits, then we might as well change the single s bit
> to a fixed 1.  Then we avoid TURN channels as well.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.