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

> Thanks for this detailed background, Brian,
> my reply in-line,
> Al
>
> > -----Original Message-----
> > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]
> > Sent: Tuesday, October 17, 2017 1:32 AM
> > To: MORTON, ALFRED C (AL)
> > Cc: ippm@ietf.org; 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>
> > 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.
> [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 :-)
>
> >
> > > 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
> https://www.ietf.org/mailman/listinfo/ippm
>