Re: Spin Bit -- a Path Forward

[Martin Thomson <[e-mail]>]

This captures my understanding well.  I want to clarify a couple of points.

I believe that we don't need to reserve bits in the long header, even
though that has more space available.

For the short header, we currently have a few bits reserved for other
purposes.  Saving two bits is easy though they will not be contiguous,
due to the gQUIC demux bit.  We could have 3 bits if we decided that
STUN demux wasn't a goal.  We will regain one more bit when Google
sort out the migration to IETF QUIC.

On Fri, Mar 23, 2018 at 2:20 PM, Mark Nottingham <[e-mail]> wrote:
> In London, Thursday's discussion ended up with a plan where:
>
> - The transport draft editors will assure that at least three bits are available for experimentation in the next draft
> - A separate WG document (but not milestone, yet) would be written that would document how to use one of those bits to measure RTT (the "Spin Bit")
> - That document would be an optional part of our upcoming Implementation Draft milestones, to encourage implementation and experimentation
> - However, the "core" documents will NOT yet be affected in any way, beyond the accommodation of bits above
> - Before publishing QUICv1, we'd revisit the status of that document to determine what to do with that document (as well as any other proposals that emerge and have a similar level of review).
>
> This gives us more time to get experience, explore possible alternatives (provided they have adequate review) and assess implementation support, without putting it on our critical path. The final decision regarding the destiny of those bits in QUICv1 (or other possible extensions, versions, etc. to meet these uses) will depend upon the implementation take-up, breadth and quality of experiences reported, and amount and diversity of data collected in our experimentation.
>
> If there is enough interest in using more than one bit for determining RTT (e.g., Brian's VEC), or another proposal, we'll spin up a Design Team to evaluate the privacy implications of doing so (taking into consideration decisions about Packet Number Encryption).
>
> The above is an expanded version of what we discussed in the room (time was constrained). We believe that the sense of the room supported this path forward pretty strongly. If you disagree -- either with the characterisation of what was discussed above, or with the proposed path forward -- please explain why.
>
> Regards,
>
> --
> Mark and Lars, WG Chairs
>