Re: Spin bit discussion - where we're at

["Gorry (erg)" <[e-mail]>]

Hi Jana 

So... +1 to Brian’s reply.

We need to decide as a WG whether manageability is needed: Do we really need more operations and measurement people to speak up? 

“Handshake RTT” - turns out to be a rather poor tool in many radio-based networks (eg mobile)... quite simply the need us to measure latency (reordering,loss) as the session progresses ... I think this is already clear. 

Gorry 

> On 27 Nov 2017, at 07:27, Brian Trammell (IETF) <[e-mail]> wrote:
> 
> hi Jana,
> 
> Thanks for these questions. A couple of points inline.
> 
>> On 27 Nov 2017, at 16:03, Jana Iyengar <[e-mail]> wrote:
>> 
>> In addition to how the spin bit can be designed and used, I'd like those taking on this effort to consider this question: Whatever network management problem you're considering solving with a bit, what does it take to solve this problem without the bit exposed? I'm asking you to consider "zero-bit" solutions, or at least for a cost/benefit analysis of developing solutions with and without the spin bit for specific network management functions. Specifically,
> 
>> (i) What's impossible or very difficult to do, from a network management perspective, of not having the spin bit? Note that I'm not asking for what is and is not measurable -- not everything measurable is useful.
> 
> ...while I agree with you here, in principle, I'll point out that we're not talking about some obscure metric you need two pages of latex mathmode to describe... latency measurement is pretty basic stuff, from which you can derive most everything else you need, which is why this is the proposal we'd go with if we only had one bit...
> 
>> I'm specifically asking in terms of network management functions, in practice, as used by operators. Some of this has been addressed in the discussions/drafts I've seen, but I think it's most useful when framed in terms of network management functions.
> 
> For the most part this is what you think it is: "detecting, localizing, and troubleshooting latency issues". For access providers, specifically, this is a matter of having an answer as to what the provider is doing wrong and/or why it's not the provider's fault when customers call to complain.
> 
>> (ii) What are the alternatives for building the same functions without the spin bit? Let's consider for a moment that the spin bit isn't actually available in practice. What will operators do to continue managing their networks?
>> This might be expensive, but that's precisely what I'm looking for -- the cost to operators of not having the spin bit. For instance, active probes are a fine way to measure network RTT within operator networks, and that is an alternative.
> 
> ...for some values of "fine", yes.
> 
>> There are surely others too.
> 
> Handshake RTT is the other one that'll almost certainly work, at the cost of drastically reduced sample rate and bias toward differential treatment of first packets / additional compute delay for crypto bootstrapping on endpoints small enough that that matters.
> 
> Next up is a two-stage approach that leverages peculiarities in implementations / CC algorithms to classify senders in order to probabilistically match packets to get component RTTs as with TCP. But that is, as you say, kind of expensive.
> 
> Third, if a provider needs passive RTT measurement at higher than handshake RTT resolution, and QUIC won't expose it, TCP still will. So one could always selectively/probabilistically block udp/443 to force fallback and get enough samples. Since the TCP and QUIC stacks are (for now) completely separate codepaths, there will be a bias on the endpoint delay side. It's also kind of expensive.
> 
> The latter two are speculative enough that I'd prefer to leave them out of the draft, though.
> 
>> Their costs and limitations are important to know about in order to reason about their viability, so I'd like to see alternatives considered.
>> 
>> I don't mean to start the discussion on this thread, but I'd like to urge those going off to do the writing to consider these questions.
> 
> Fortunately, I just wrote a first draft of that section :). Al signed up to add some text to it shortly. Hope to get a complete draft out in the next couple of weeks, travel and other deadlines permitting.
> 
> Cheers,
> 
> Brian
> 
>> - jana
>> 
>> 
>> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) <[e-mail]> wrote:
>> Hi Brian, Stephen, Lars, Mark and all,
>> 
>> one join, one suggestion, and one question below.
>> see [ACM]
>>> -----Original Message-----
>>> From: QUIC [mailto:[e-mail]] On Behalf Of Brian Trammell
>>> (IETF)
>>> Sent: Wednesday, November 22, 2017 5:59 AM
>>> To: Eggert, Lars
>>> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
>>> Subject: Re: Spin bit discussion - where we're at
>>> 
>>> hi Lars,
>>> 
>>>> On 22 Nov 2017, at 11:35, Eggert, Lars <[e-mail]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 2017-11-22, at 11:01, Stephen Farrell <[e-mail]>
>>> wrote:
>>>>> What I thought was being requested and what I do think is reasonable
>>>>> is to document a privacy analysis for any quic protocol bits that are
>>>>> visible to the path. Whether or not some or all of that text ends up
>>>>> in some RFC is another day's work.
>>>> Lars wrote:
>>>> for the Spin Bit specifically, the intent was to permanently capture
>>> the analysis the DT has done, so that when others review the proposed
>>> Spin Bit specification, they can take that as a given and direct any
>>> further analysis to other aspects. It made sense to the chairs that that
>>> specific analysis should become part of the Spin Bit specification. I
>>> think we'd be open to a discussion on whether a broader document
>>> analyzing the QUIC wire image would be a better home for this. The main
>>> point is for the work that the DT has done to be documented.
>> 
>>> Brian wrote:
>>> Okay. That's somewhat more reasonable than what I read the ask to be
>>> ("we're going to gate this on the people who care about this doing some
>>> non-trivial amount of work"). Those of us who volunteer (help, please,
>>> anyone? :) ) can certainly pull together what we have in a single I-D
>>> and ask the WG what more it thinks it needs. To me all this seems pretty
>>> clear, but I've been working on this topic for a while.
>> [ACM]
>> Having reached the end of the "Thanksgiving thread",
>> I'm scrolling back a few pages to join the task of
>> permanently capturing the work of the DT in an I-D (at least):
>> There should be lasting value in some of our findings
>> and IMO they are worthy of a persistent reference.
>> 
>>> Lars wrote:
>>>> For proposals other than the Spin Bit (I think I have seen individual
>>> contributors at least mention "loss" and "congestion" bits, but without
>>> much detail), we wanted to clarify that we'd like to see an analysis and
>>> discussion of their privacy aspects to roughly the same degree as the DT
>>> has performed for the Spin Bit proposal.
>>> 
>> [ACM]
>> I suggest that this might be a different I-D, at least to start.
>> Question: Is there a privacy analysis of present ECN available?
>> (a search yielded many results with Missing: privacy)
>> 
>> regards,
>> Al
>> 
>> 
>