<div dir="auto">Ideally, always on monitoring and export at the PE. An incremental first step in an adhoc off box tester, maybe deployed with the perfsonar suite.<div dir="auto"><br></div><div dir="auto">Meaningfully visualizing the output seems challenging. Do you have any insights on that part?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 27, 2021, 11:00 AM Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jason Iannone <<a href="mailto:jason.iannone@gmail.com" target="_blank" rel="noreferrer">jason.iannone@gmail.com</a>> writes:<br>
<br>
> Beyond getting acquainted with a new dataset? I'm a transit network that<br>
> supports, among other traffic types, science flows. I think new monitoring<br>
> methods can help identify targets for intervention.<br>
<br>
Right, I meant more in terms of deployment: are you looking to run this<br>
as an always-on monitor on a middlebox, or are you just running ad-hoc<br>
measurements on a client device?<br>
<br>
I ask because we have a PhD student working on a re-implementation of<br>
pping in BPF, the goal of which is precisely to be able to run as an<br>
always-on monitor:<br>
<a href="https://github.com/xdp-project/bpf-examples/tree/master/pping" rel="noreferrer noreferrer" target="_blank">https://github.com/xdp-project/bpf-examples/tree/master/pping</a><br>
<br>
So any insights into what you're thinking of doing with the tool would<br>
potentially be helpful - adding in Simon, who's writing the code.<br>
<br>
-Toke<br>
</blockquote></div>