Re: Spin Bit -- a Path Forward

[Martin Duke <[e-mail]>]

I support this course of action.

I don't see us reaching consensus that this should become a part of v1, for
reasons that aren't worth discussing on the list*. Assuming that further
experience proves the spin bits to be valuable, I support a separate RFC
defining a different QUIC version in which using them is mandatory. This
seem to be the cleanest way to proceed.

*to be clear, I wouldn't mind it being in v1, but I don't think it will
happen.

On Fri, Mar 23, 2018 at 8:24 AM, Dmitri Tikhonov <
[e-mail]> wrote:

> I hope we take into account the other gQUIC operators as well. :)
>
> ------------------------------
> *From:* QUIC <[e-mail]> on behalf of Martin Thomson <
> [e-mail]>
> *Sent:* Friday, March 23, 2018 2:28:28 PM
> *To:* Mark Nottingham
> *Cc:* Lars Eggert; IETF QUIC WG
> *Subject:* Re: Spin Bit -- a Path Forward
>
> 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
> >
>
>