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

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 16 Oct 2017 23:57:31 +0000

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.

FYI - you also argued for ICMP RT Delay and Loss,
and I've just added them to the working draft.

thanks for your well-thought-out comments, and regards,
Al
(for the draft-ietf-ippm-initial-registry authors)

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Oct 2017 07:32:29 +0200

hi Al, all,

> On 17 Oct 2017, at 01:57, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> 
> Hi Brian,
> 

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.

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 (QoF, a passive performance measurement IPFIX flow meter), and https://github.com/britram/mokumokuren/blob/master/chainfunc.go#L126 (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. 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.

> 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)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 17 Oct 2017 23:03:17 +0000

Thanks for this detailed background, Brian, 
my reply in-line,
Al

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2017 1:32 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]; [email-masked]
> Subject: Re: <ping> Suggestion for TCP RTT metric in the Initial
> Registry
> 
> hi Al, all,
> 
> 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.
[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 (QoF, a
> passive performance measurement IPFIX flow meter), and
> https://github.com/britram/mokumokuren/blob/master/chainfunc.go#L126
> (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. 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
(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 :-)

---

From: Ron Even <[email-masked]>
Date: Thu, 19 Oct 2017 14:08:23 +0300

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

> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 19 Oct 2017 17:52:46 +0000

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:[email-masked]]
Sent: Thursday, October 19, 2017 7:08 AM
To: MORTON, ALFRED C (AL)
Cc: Brian Trammell; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for this detailed background, Brian,
my reply in-line,
Al

> From: Brian Trammell [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > On 17 Oct 2017, at 01:57, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hi Brian,
> >
> 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]

> 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
> 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=>
> 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
[ACM]
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=>

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
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=>