Re: Measurement bit(s) or not

[<[e-mail]>]

Hi Brian,

We're clearly in violent agreement about both the potential to make intelligent
use of this measurement nibble, and the desirability of *some* troubleshooting
helper. Thanks for proposing to include this discussion in the spin bit table.

As it turns out, we do have concrete illustrations to show there, on real
networks and long distances. But beyond that, I'd like to "probe" this group for
a possible veto before digging further: while I have no doubt about an eventual
consensus among us "troubleshooters", I'm more worried by the other side of the 
board: people primarily concerned about ossification and linkability, to whom
network debugging is at best a secondary goal.

More precisely, as you accurately described, the position of the cursor of both
tradeoffs may display a kind of threshold for acceptability by them :

- endpoint vs midpoint complexity: if the tool is too easy on the midpoint,
active Murphies will come in ; at kind of entry barrier should be set -- how high ?

- fidelity: the coarser, or the more delayed, the better, since it precludes any
real-time feedback loop like active Murphies do ; what is the minimum
degradation that is needed ?




On 12/02/2018 10:20, Brian Trammell (IETF) wrote:
> hi Mikkel, Igor, Alexandre, all,
>
> Engineering is fun, but let's step back a bit. :)
>
> It looks like we're exploring a space of proposals that have different
> tradeoffs for the patterns of loss and reordering they can easily make
> visible, tradeoffs for sender (endpoint) versus observer (midpoint)
> complexity, and tradeoffs for fidelity versus overhead.
>
> In any case, it seems like it is possible to design a signal that would be a
> vast improvement (from the measurement utility standpoint) over no signal and
> no discernible pattern in the packet number that will fit in bits scavenged
> from the Type field of the short header, i.e., the bandwidth overhead will be
> *zero*, because otherwise in an encrypted-PN world we just have to grease
> those bits anyway.
>
> Back to Alexandre's question:
>
> Do we want to do this?
>
> Rephrased: Is the passive measurability of loss, reordering (and, if we
> consider the spin bit as one of the measurement bits, latency) of QUIC
> important to us, or do we decide we can live with the negative pressure a
> complete loss of visibility and an vast increase in diagnostic complexity
> will place on deployment?
>
> Note, of course, that all the proposals we have so far represent a decrease
> in visibility and an increase in complexity of measurement compared to
> passive measurement of TCP. New tools will have to be developed. But the loss
> of visibility is minimal compared to blackout, and the deployability and
> feasibility of all of these is far, far better than an SSLKEYLOGFILE-based
> debugging approach, especially in the interdomain case.
>
> I've heard at least one dismissal of this whole space as being too abstract
> to take seriously. (I'm not concerned, but maybe I've been staring at network
> measurement both passive and active for too long to know what's intuitive
> anymore.) Let me then suggest a way forward:
>
> I've announced a table at the London hackathon for "Transport Measurability"
> (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we
> intend to set up in the vicinity of QUIC. This was originally intended as the
> "Spin Bit" table, and we (from ETH) will be there working on scalable,
> open-source passive measurement tools both for the spin bit as well as for
> the current TCP TSOPT and SEQ/ACK methodologies (as a basis of comparison,
> mainly; at least in the case of the spin bit we so far believe the explicit
> signalœ to have superior usability compared to current TCP measurement). I
> suggest we expand the scope of table to hack on various signals for loss and
> reordering, and to compare their complexity and fidelity against the loss and
> reordering patterns we want visibility into. One output of this work could be
> a (smaller) set of suggestion(s) for which signal(s) to add, so that those
> who want to have concrete proposals to evaluate can do so.
>
> Cheers,
>
> Brian
>
> [...]





>>>>
>>>> -----Original Message----- From: [e-mail]
>>>> [[e-mail]] Received: Saturday, 10 Feb 2018,
>>>> 12:34PM To: [e-mail] [[e-mail]] Subject: Measurement bit(s)
>>>> or not
>>>>
>>>> On 07/02/2018 14:34, Brian Trammell (IETF) wrote:
>>>>> hi Jana,
>>>>>
>>>>>> 3. Some sequencing information -- a few bits of the packet number
>>>>>> perhaps -- should be revealed (for monitoring. Number of bits
>>>>>> TBD.)
>>>>>
>>>>> This is the crux of the argument. On one side we have the risk of
>>>>> misuse and ossification (well, not ossification -- these bits are
>>>>> *meant* for the path -- rather the risk that we'll figure out later
>>>>> that we specified the wrong thing), on the other side we have the
>>>>> loss of visibility into how QUIC traffic interacts with the network
>>>>> as compared to TCP, with a side question of whether or not this
>>>>> visibility is really the transport layer's problem despite the
>>>>> evolution the practice of diagnostics and troubleshooting using TCP
>>>>> information.
>>>>>
>>>>> If we can come to agreement on this question, everything else falls
>>>>> into place. I have my arguments here, but as you said, this subthread
>>>>> is not the place for them. :)
>>>>
>>>> The crux indeed. So what about settling it first ?
>>>>
>>>> With the troubleshooting hat, I can only stress the need for
>>>> measurement bits, for the benefit of everybody, since s**t happens,
>>>> networks are imperfect, and nifty encapsulations-with-seqnum will
>>>> simply not be where you need them.
>>>>
>>>> Now to the exact nature of these measurement bits:
>>>>
>>>> Thanks to the detailed exchanges on this thread, it is by now clear
>>>> that a simple gapless counter, even nonzero-based and XORed, is not
>>>> acceptable. The 4-bit SSN comes pretty close but is not enough when
>>>> things go really wrong (and they will - and that's where we need the
>>>> tool).
>>>>
>>>> Then Kazuho's square signal and Mikkel's Pi (or any other consensual
>>>> self-synchronizing sequence) ramification came up. They are both
>>>> appealing for their elegance and low complexity on QUIC endpoints.
>>>> Beyond their quirks acknowledged here, here are a few considerations
>>>> for troubleshooting:
>>>>
>>>> (1) Since reordering is less of a concern to QUIC than to TCP, it
>>>> becomes a secondary goal. This is nice, because the square doesn't see
>>>> it, and the self-synchronizing sequence will only tolerate a mild one,
>>>> and never see its detail like cycle length etc.
>>>>
>>>> (2) There's of course a huge difference between them in complexity for
>>>> the midpoint: square is trivial, Pi is hefty.
>>>>
>>>> Given these, a benevolent, troubleshooting-minded passive midpoint will
>>>> clearly vote for the square. Now the obvious question is: is this
>>>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to
>>>> see upstream losses and benevolently wreak havoc by delaying packets ?
>>>>
>>>> _________________________________________________________________________________________________________________________


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.