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

[Christian Huitema <[e-mail]>]

> On Sep 19, 2018, at 5:17 PM, 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

OK. So basically, all the bits are taken for both v4 and v6. Spencer's original question why, should we put this kind of tracing bit in the transport header or in the network header. In theory, there are some arguments for putting common functions in the network header rather than in a variety of transport headers. But in practice that would mean some kind of IP option, and that's both more complicated and more error prone than reserving a bit in a transport header.

-- Christian Huitema