<div dir="auto">I watched your presentation at ucla on youtube. I wasn't expecting the talk you ended up giving, but I think your experience is familiar.<div dir="auto"><br></div><div dir="auto">Poking at data in different ways is interesting and it can be hard to separate the wheat from the chaff. What presentation methods matter? What presentation methods drive useful action?</div><div dir="auto"><br></div><div dir="auto">I'm not a data science guy. At my core, I am a plumber. New and interesting ways of visualizing what lives in the pipes can help me target problem areas, the same way you noted with the 7 second delay in the university science network in your presentation.</div><div dir="auto"><br></div><div dir="auto">I appreciate the scope of pping. It's small and intentional. Anyway, I dig the intent and the size and I hope to see more of this kind of work.</div><div dir="auto"><br></div><div dir="auto">Thanks for replying,</div><div dir="auto"><br></div><div dir="auto">Jason </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 26, 2021, 5:16 PM Kathleen Nichols <<a href="mailto:nichols@pollere.net">nichols@pollere.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/26/21 4:56 AM, Jason Iannone wrote:<br>
...<br>
> passively monitor production flows to get a novel sense of end to end<br>
> performance per flow. I don't know of any other passive monitoring<br>
> technique, beyond a port mirror + a whole gang of systems, that can<br>
> provide this level of detail. Please enlighten me if I'm wrong. The only<br>
> other passive monitoring mechanisms I'm aware of are SNMP polling,<br>
> IPFIX/*Flow, and Streaming Telemetry Interface. None of those systems<br>
> provide end to end flow performance details. The standard in-band active<br>
> monitoring tools are good for determining node to node and full path<br>
> metrics, but this provides a more complete picture of end to end<br>
> performance beyond active y.1731/802.3ag/OAM probes. I'm a little<br>
> surprised that I'm only learning about it now.<br>
> <br>
<br>
So, I worked on something I call TSDE (Transport Segment Delay<br>
Estimator) that lets you get a (noisy) one-way estimate of delay<br>
variation. I did pping as sort of a side product and as a way to find<br>
the minimum round trip delay since TSDE just gives variation. This was<br>
done under a DOE SBIR and Pollere has a patent on it but I would<br>
consider sharing information if someone wanted to develop an open source<br>
tool. (I feel that my own implementation is kind of fragile as I was<br>
using it to try different ideas for getting a good estimate. And I<br>
haven't done anything with it for several years.)<br>
<br>
        Kathie<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank" rel="noreferrer">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div>