Subject: Spin Bit -- a Path Forward

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Mar 2018 14:20:23 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Mar 2018 14:28:28 +0000

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.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Mar 2018 14:30:02 +0000

> On 23 Mar 2018, at 2:28 pm, Martin Thomson <[email-masked]> wrote:
> 

Whatever is practical. I don't think these bits need to be contiguous, and they're only for experimentation now -- if we need to change their locations after making a decision about adopting Spin (or another proposal) before shipping QUICv1, we can do that.

--
Mark Nottingham   https://www.mnot.net/

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 23 Mar 2018 14:34:01 +0000

hi Mark, all,

This reflects where I thought we ended up yesterday. If I may propose one friendly amendment...

> On 23 Mar 2018, at 14:20, Mark Nottingham <[email-masked]> wrote:
> 
> <snip>
> 

While the privacy considerations for additional signal beyond the one bit are important (and we haven't yet examined them), I wouldn't scope the DT so tightly. The DT should consider measurement utility as well as privacy risk.

Cheers,

Brian

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 23 Mar 2018 15:24:12 +0000

I hope we take into account the other gQUIC operators as well. :)

________________________________
From: QUIC <[email-masked]> on behalf of Martin Thomson <[email-masked]>
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

---

From: Martin Duke <[email-masked]>
Date: Fri, 23 Mar 2018 10:21:55 -0700

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 <
[email-masked]> wrote:

> ------------------------------
> *From:* QUIC <[email-masked]> on behalf of Martin Thomson <
> [email-masked]>
> *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
>
> > - 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
> > - 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
> >
>
>