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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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]) wrote:

On Wed, Sep 19, 2018 at 1:49 PM, Brian E Carpenter
<[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]> 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
>>
>> .
>>
>