Re: Spin bit discussion - where we're at

["Brian Trammell (IETF)" <[e-mail]>]

hi Mark, all,

While I disagree with the chairs as to the state of consensus on this issue, I'm going to go ahead and (perhaps predictably) throw my name in the hat for this one, since we're actively working on it anyway.

I have a few questions and comments on the content of the work program requested, below:

> On 22 Nov 2017, at 09:06, Mark Nottingham <[e-mail]> wrote:

<snip>

> There are a number of things that we think will help clarify the value provided by the Spin Bit:
> 
> 1) A description of the use case(s) that motivate this proposal. We understand that the goal is to measure RTT, but some people are still unclear as to why that's necessary to operate a network. Detailed scenarios and ideally real-world examples (e.g., from TCP) would help tremendously. Saying "I need to debug the network" is not enough detail.

This seems reasonable, though I would appreciate some clear acceptance criteria for the level of detail the WG would consider useful. "I need to debug the network" is clearly not detailed enough, but what is?

> 2) An actual protocol specification for the Spin Bit, including Privacy Considerations. There seems to be a fairly good common understanding of it (especially in the DT), but it would be helpful to have it written down, so we can make sure we're talking about the same thing. If it were proposed as an extension, current implementations (reminder: we have 12) could implement it to see how it works on the network. Doing so would also give the security research community something to look at (see above).

We already have this in the form of PR 609, though it needs to be rewritten. I'd be happy to volunteer to carve this off into a separate I-D if that's what the WG wants.

The request for a privacy considerations section for a single protocol feature seems odd to me at best, and prejudicial at worst. Where is the privacy considerations analysis for other features, for instance, various header compression schemes? But, again, given that the work is already done (and mostly in markdown!), dumping it into an I-D is marginal work.

> 3) Data showing that the Spin Bit is fit for purpose under real-world conditions. Piet's experiment is a start here, but we need much more.

Piet's current work represents much more than was presented to the list during the Singapore meeting, but some indication of how much more we need would be useful here. Piet is producing a detailed analysis of a number of proposed measurability features (one-bit spin is done, and two-bit spin and a blocking bit as once proposed by Martin Duke are on the implementation schedule now), and we can certainly feed this into the draft.

> Analysis of how well that data meets the use cases is also necessary. This might form part of the Manageability Considerations of the draft.
> 
> 4) A comparison of other potential solutions to measuring delay, and their relative merits. Again, ideally with detailed, real-world data.

As in 1, there's a whole lot of literature here. I'll say that we'll probably produce some numbers as part of the same evaluation above comparing the latency spin bit to handshake RTT measurement (presuming that the handshake remains visible enough to measure) and to "find some TCP in your aggregate and compute latency based on that" (which reduces to "force 1/k QUIC flows to TCP in order to get enough TCP in your aggregate to compute latency" in a mostly-QUIC world, yay fallback!).

> 5) An exploration of what the effects of deploying the spin bit are likely to be. E.g.: Will even the perception of privacy issues change endpoint behaviour? Will networks treat traffic differently based upon the spin bit? If so, can that be gamed? Will firewalls and other gateways police spin bit behaviour (e.g., to prevent data loss), and what effects will that have?

I don't see how this request is useful.

Perhaps if the proposal were to add some new form of exposure not already ubiquitously available in TCP, with which we did not have years of operational experience, this might arguably be necessary work. However, as it stands, the exercise would certainly lead to a fascinating exploration of the economics of modern Internet access, but given the lack of ability to run sensible experiments to form an evidentiary basis for decision, such an exercise would always reflect the prejudices of its authors. One could write an essay for 5 that will reasonably support any view one cares to have here, which yields it useless for helping us to make a decision.

> We're looking for volunteers to start drafting one or more documents along these lines. If you're interested, please indicate this on-list, so you can coordinate with other interested parties. They won't (yet) be WG documents, but since the DT didn't resolve the issue, we will discuss them in the WG.
> 
> In terms of timeline - resolving this is NOT a blocking issue; i.e., we can discuss this concurrently with other work on the protocol, and because it's such a small change in the packet layout, we can add it right before shipping the protocol to the IESG.

I will note that any bits we designate to measurement will rapidly become part of QUIC's invariants, whether we intend them to or not, so the details of any design we choose will have to be carefully considered. However, that probably does not imply that those bits (their number and position) need to be proactively added to the invariants currently under discussion. So I agree with your assessment that we can tip this into the short header relatively late in the game.

Cheers,

Brian

> In light of that, we will NOT discuss this (or related) issues at the Melbourne interim. That will allow the people attending to focus on continued protocol development, and means that people don't feel the need to travel to discuss just this issue. We would like to be able to move the discussion forward at IETF101 in London, provided that significant progress is made on the items above.
> 
> Cheers,
> 
> 
> Your Chairs, Mark and Lars
>