Re: [tsvwg] Why measure RTT passively?

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

Tom, it may be quite difficult to ask the application. An operator may have
many thousands ongoing connections with mobile phones and want to measure
the overall network quality. It would be quite impossible to discuss
latency with all phones in the network. Additionally it would require a
secure connection, trust, etc. etc.

Passive measurement is invasive in the sense that it steals private
information that could be abused without consent. So the balance is expose
as little as possible, but enough to make it useful for reasonable purposes.

Trammels paper shows that a very high quality can be achieved with 3 bits,
which is a lot simpler than asking an application, whether the option
existed or not. The question is more: would 8 bits, or a full sequence
number be better? The answer, according to the paper is no - only in
certain lossy conditions, and not by very much. On the other hand, more
information leaks more private information.

Furthermore, the simplicity of 3 bits make it possible to stuff the bits
almost anywhere, so the concept is universal.

There is almost no bad things to say about it, except the connection
asymmetri mentioned, and the fact it must happen in the layer 4 packet
rather than the IP packet. But then, it could be mirrored into a lower
layer protocol header since it is space efficient.


On 19 September 2018 at 17.00.33, Tom Herbert ([e-mail]) wrote:

On Wed, Sep 19, 2018 at 4:46 AM, Michael Tuexen
<[e-mail]> wrote:
>> On 19. Sep 2018, at 00:53, Tom Herbert <[e-mail]> wrote:
>>
>> On Tue, Aug 21, 2018 at 5:42 AM, Brian Trammell (IETF) <[e-mail]>
wrote:
>>> Greetings, TSVWG, QUIC, and IPPM,
>>>
>>> I've just submitted a new I-D, "Why do we need passive measurement of
round trip time?" (
https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00) which may
be of some interest to each of these WGs. :) It presents a set of use cases
for on-path passive RTT measurement, both generally, and specific to the
facility described in "A Transport-Independent Explicit Signal for Hybrid
RTT Measurement" (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00)
or the "spin bit".
>>>
>> Hi Brian,
>>
>> I looked at that draft draft-trammell-tsvwg-spin-00. It's unclear to
>> me how this mechanism is transport-independent. The draft shows how to
>> do this in QUIC and TCP, but there's no support that I see for DCCP,
>> SCTP, IPsec, other encapsulations, etc. I would think that for
>> something to be truly transport-independent the information would need
>> to reside in the network layer.
> I agree with Tom, right now this does not look like
transport-independent..
> One could add a chunk for SCTP to expose the 3 bits, but I was wondering
> why not just let the endpoints willing to expose the RTT signal let them
> send the measured RTT explicitly?
>
Yes! The application or at least network stack will have this
information and much more that might be of interest to the network--
they will also know RTT variance, packet loss on the flow, number of
out of order packets received, etc. If the network needs this sort of
information why not just ask the application for it instead of trying
deduce it from a limited view of the transport layer and a couple of
fundamentally insecure bits in the packet?

Tom


> Best regards
> Michael
>>
>> Tom
>>
>>> - For QUIC, this draft addresses the second half of the risk/utility
question raised by the spin bit and spin+VEC latency signal -- much of the
content comes from the original QUIC spin bit document, but there are new
sections on using VEC for loss/reordering proxy metrics and exploiting
correlations between RTT and other metrics to drive intraflow diagnostics
from only RTT signals. In particular, I'll talk about ongoing
experimentation along the lines of section 3 at the interim in New York.
>>>
>>> - For TSVWG and tsvarea, it addresses some of the "why design wire
images" questions raised in the tsvarea meeting in Montreal, with respect
to the specific tasks for which RTT data is useful.
>>>
>>> - And for IPPM, it gives a bit more background on the "passive RTT"
metric in the initial registry document.
>>>
>>> Feedback is much appreciated. :)
>>>
>>> Thanks, cheers,
>>>
>>> Brian (as an individual contributor)
>>>
>>> P.S. apologies for the resend: the previous message was not an obscure
joke about ubiquitous encryption: apparently the interaction among my MUA,
its bolt-on GPG, and the somewhat underprovisioned network in SIGCOMM led
to an encrypted draft being posted to the list. :/
>>>
>>
>