Re: Measurement bit(s) or not

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

> On 10 Feb 2018, at 17:34, <[e-mail]> <[e-mail]> wrote:
> 
> 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.
> 
+1
... at the time when this is most useful for troubleshooting, a lot may be happening that is not normal.

> 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.
Again +1

> 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).
> 
8 bits could be enough - and still would be les than 0.1% overhead.

> 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.

Being able to observe that the network is doing this could still be good when debugging network faults.
> 
> (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 ?
> 
No amount of encryption is going to actually prevent a middlebox/tunnel/lower layer doing things - such as link retransmission.

Gorry

> _________________________________________________________________________________________________________________________
> 
> 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.