Re: [tsvwg] [ippm] Why measure RTT passively?

[<[e-mail]>]

We've spent some energy trying to get something from 1 bit indeed. The problem 
is twofold:
  (1) robustness to reordering => only commutative things like unary or average 
(like 1-bit DACs) work
  (2) scarce outgoing flow => as few as 2 ACKs per RTT happen => must spread the 
info over a looong time if you're the receiver

For an example with unary see the "E" bit in our 3-bit proposal (spin + 2 loss 
bits) at page 15 of

https://github.com/quicwg/wg-materials/blob/master/interim-18-09/Spin%20bit%20and%20beyond%20%40%20Orange%20v1.pdf

On 09/19/18 23:30, Mikkel Fahnøe Jørgensen wrote:
> On the actual experiments:
>
> has there been any work on patterns on a single bit? At some point we 
> discussed various signals including square wave, PI, and fractal gray codes.
>
> If privacy or space is a concern with 3 bits, perhaps a gray code could solve 
> the same problem trading space for time.
>
> On 19 September 2018 at 23.18.25, Tom Herbert ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
>> On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter
>> <[e-mail] <mailto:[e-mail]>> wrote:
>> > On 2018-09-20 01:56, Gorry Fairhurst wrote:
>> >> On 19/09/2018 13:24, Christian Huitema wrote:
>> >>>
>> >>>> On Sep 18, 2018, at 7:59 PM, Spencer Dawkins at IETF 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>> >>>>
>> >>>> Forget that I'm an AD, because I'm not wearing any hats, but I'm having 
>> a really difficult time explaining to other people internally how a spin bit 
>> that's not in the IP header, but is part of a mostly-encrypted transport 
>> header, is better than putting something in an IP (extension? iOAM?) header 
>> that would be transport-independent.
>> >>> The one advantage of the bit in transport header is that it is 
>> authenticated end to end. The other advantage is that it is automatically 
>> tied to a transport flow and its five tuple. Then there is the reality that 
>> IP header bits are commonly rewritten by a variety of middleboxes.
>> >>>
>> >>> The downside is that different encrypted transports will most likely end 
>> up adopting different encodings and conventions.
>> >>>
>> >>> But of course we could also repurpose one of the TOS bits
>> >> Do you mean the DSCP field? - That would sound like a very odd proposal.
>> >
>> > To be clear, there are no free bits in the DSCP field, there are only
>> > free codepoints in the 6-bit space. And of course since DSCP values
>> > explicitly act as a QoS request, they also implicitly change the
>> > one-way latency and therefore the RTT. So the DSCP bits would be
>> > remarkably bad as a tool for RTT measurement.
>> >
>> > Brian C
>> >
>> >>> or one of the flow header bits for the purpose, to mirror the transport 
>> level bit. Mirror instead of replace: that would alleviate the need of 
>> parsing transport headers, but still allow end to end detection of IP header 
>> rewriting.
>>
>> Neither are there any flow label bits available. Re-purposing even a
>> single bit would adversely effect deployed use cases where flow label
>> is being used for packet steering or other purposes. Using the flow
>> label for packet marking was discussed in
>> https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01
>>
>> Tom
>>
>> >>>
>> >>> -- Christian Huitema
>> >>
>> >> 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.