RE: Spin bit discussion - where we're at

[Roni Even <[e-mail]>]

Hi ,
 I was surprised to read the chairs email and agree with Brian's comments.
My impression is that the email reflects a view that manageability is not important (and not blocking) and this is the reason for not doing the spin bit based on issue 609 as a PR.
My product development experience is that lack of tools to manage and maintain a product will prevent its distribution. I understand that the developer  of the protocol care only about the protocol and not about making it easy to support in the field. Yet the network product manufacturers and the service providers gave a clear message that RTT  is crucial for deployment.  I provided use cases from TCP in service providers networks in https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-00.txt 
I expect that the WG chair and AD will treat protocol maintenance and management the same as the protocol itself. What emphasis my point is the effort the WG does on https://tools.ietf.org/html/draft-ietf-quic-manageability-01 

Roni Even 

> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Brian Trammell
> (IETF)
> Sent: יום ד 22 נובמבר 2017 11:15
> To: Mark Nottingham
> Cc: QUIC WG; Lars Eggert
> Subject: Re: Spin bit discussion - where we're at
> 
> 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
> >