Measurement bit(s) or not

[<[e-mail]>]

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.