Re: [ippm] <ping> Suggestion for TCP RTT metric in the Initial Registry

Hi Roni,

I’m adding this new metric in the
draft-ietf-ippm-initial-registry,
as a new section (and nearly done).

This sentence inviting another doc
dates back a long time. All we really need
now is proof of applicability to passive
metrics (choosing one that is worthwhile
to do at the same time).

regards,
Al

From: Ron Even [mailto:ron.even.tlv@gmail.com]
Sent: Thursday, October 19, 2017 7:08 AM
To: MORTON, ALFRED C (AL)
Cc: Brian Trammell; draft-ietf-ippm-initial-registry@ietf.org; ippm@ietf.org
Subject: Re: [ippm] <ping> Suggestion for TCP RTT metric in the Initial Registry

Hi Al,
Are you suggesting that for passive metric for RTT there is a need for a new document on initial registry as stated in draft-ietf-ippm-initial-registry-04 "Proponents of Passive Performance Metrics are encouraged to develop a similar document."?
Roni Even

On Wed, Oct 18, 2017 at 2:03 AM, MORTON, ALFRED C (AL) <acmorton@att.com<mailto:acmorton@att.com>> wrote:
Thanks for this detailed background, Brian,
my reply in-line,
Al

> -----Original Message-----
> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch>]
> Sent: Tuesday, October 17, 2017 1:32 AM
> To: MORTON, ALFRED C (AL)
> Cc: ippm@ietf.org<mailto:ippm@ietf.org>; draft-ietf-ippm-initial-registry@ietf.org<mailto:draft-ietf-ippm-initial-registry@ietf.org>
> Subject: Re: <ping> Suggestion for TCP RTT metric in the Initial
> Registry
>
> hi Al, all,
>
> > On 17 Oct 2017, at 01:57, MORTON, ALFRED C (AL) <acmorton@att.com<mailto:acmorton@att.com>>
> wrote:
> >
> > Hi Brian,
> >
> > As a participant, you suggested that we might add
> > a Passive Metric for TCP RTT in the initial contents
> > of the Registry (I just listened to the audio, you
> > commented for several minutes ending at 0:26:00 in the
> > session). You mentioned that you have written the text
> > describing this passive metric about 6 times, and I
> > should ping you for a reference.
> >
> > This is that ping.
>
> First I'll say I think the best reference for this is *not* one of those
> I've written: see Stephen Strowes, "Passively Measuring TCP Round Trip
> Times", in ACM Queue Sept/Oct 2013, online at
> https://queue.acm.org/detail.cfm?id=2539132<https://urldefense.proofpoint.com/v2/url?u=https-3A__queue.acm.org_detail.cfm-3Fid-3D2539132&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=lHpO4lqDGwL6hfgIAbE3RXe_PhDUpKNXaHoxI3CTz8E&e=>.
[ACM]
I agree this is well-written, but your work addresses
the observations at a mid-point with the requirement
to measure RTT_fwd and RTT_rev components of RTT,
and uses more than the TSval and TSecr.

>
> My six: twice in notebooks in Auckland, while I was designing QoF;
> neither of those variants works very well, though, so counting them is
> slightly unfair.
>
> Twice in code:
> https://github.com/britram/qof/blob/master/src/qofrtt.c#L65<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_britram_qof_blob_master_src_qofrtt.c-23L65&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=d8bltKlSfLkJ2NXwlOhsHSo4JkzxPlQF3xLd8Tvx6Qs&e=> (QoF, a
> passive performance measurement IPFIX flow meter), and
> https://github.com/britram/mokumokuren/blob/master/chainfunc.go#L126<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_britram_mokumokuren_blob_master_chainfunc.go-23L126&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=9grGX6SSVNRZMGKYP37fqh7ZPOL-7gxksj3xTq28YpU&e=>
> (buggy, since it's a straight port from QoF written on a two-hour
> flight, but fixing moku is on my List Of Things To Get Done).
>
> Once on the slides that became a deck on the QUIC Latency Spin Bit I
> hope to give a lightning talk about at RIPE next week.
>
> Once got published: Trammell et al, "Inline Data Integrity Signals for
> Passive Measurement", TMA 2014, author's copy at
> https://trammell.ch/pdf/qof-tma14.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__trammell.ch_pdf_qof-2Dtma14.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=LER_YxkHT2Od2CFY5p1dKc8-pnskXGATwMonwhYJGq4&e=>. In section 2 "Background", which
> talks about what QoF does here, since the paper itself was about the
> addition of an observation loss metric to measurements of passive RTT
> and loss. QoF's heuristics differ slightly from those in Strowes. QoF
> will reject certain TSOPT-based samples in order to reduce the number of
> samples affected by application or stack delay, because it is focused on
> "network-accountable" latency and doesn't want to keep a lot of data
> around.
[ACM]
As I now appreciate much better than before,
the challenge of writing this registry entry is
that the Method of Measurement section needs to
be created from the references you supplied and
https://tools.ietf.org/html/rfc7323#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7323-23section-2D4&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=N3cjmKLUZpIa_43T3jP76hP8qrT6FA4wKzJ0FkzM6bY&e=>
(which has a Rule to avoid RTT errors from Sender Pause,
a feature that addresses one problem our friends have
raised in QUIC RTT DT).

Should be interesting :-)

>
> > FYI - you also argued for ICMP RT Delay and Loss,
> > and I've just added them to the working draft.
>
> Yay! Not necessarily because I believe in them, mind you, but because
> the whole world seems to. :)
>
> Cheers,
>
> Brian (hatless)
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Q0qgMjfBk8l5RrA69mVIjzlK7mPSl9TvVfjKlwMDA6w&s=v0qTPbdCIGxS1EZ-Ggm6zE2I07UceM_ijZrnz3k8cbU&e=>