Re: The first octet

[Martin Thomson <[e-mail]>]

On Wed, Aug 8, 2018 at 5:50 PM <[e-mail]> 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).