perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Brent Draney writes:
    
    When performance tends to drop my best go-to tool is to take a tcpdump 
capture and run it
    through TCPtrace and generate a time sequence graph and plot it using 
xplot.  I was wondering
    if others thought it would be a useful enhancement to perfsonar to be 
able to request that the
    perfsonar node automatically dump the first (1000?) packets and generate 
the plot file and make 
    the dump available for download and generate a graphic of the plot file.
    
    Do others have thoughts on whether this is a good or bad idea (or a waste 
of cycles)?

It’s an interesting idea, and you’re not the first to suggest it.  We’ve had 
a ticket open on collecting interface traffic as a separate test since last 
fall (https://github.com/perfsonar/pscheduler/issues/115), and its genesis 
goes back further than that.  There are some reasons why I wouldn’t be 
inclined to make dumping packets part of the core of the system, but that 
doesn’t mean you won’t get what you need out of it.

One aspect of pScheduler we haven’t discussed much is the fact that it 
doesn’t understand anything about the tests it runs.  The networking 
knowledge is built into the plugins, and there’s nothing in the system that 
requires that plugins do anything network-related.  While network measurement 
is the problem pScheduler was designed to solve, it can just as easily be 
made to measure how much Amazon is charging for a 32-ounce bottle of ketchup 
or the temperature in Sheboygan, Wisconsin.  We could add features to all 
plugins that do network measurements to produce nicely-filtered packet dumps 
as part of the results, but we’d have to see if there’s enough demand to do 
it and work it into our development schedule.

The good news is that the University of Michigan joined the project this year 
and has a pair of interns writing pScheduler plugins for measurements their 
ITS department is interested in having as part of perfSONAR.  Dumping traffic 
is on the list, and we’re in the early stages of discussing how the plugins 
for it will be put together, how to handle some of the practical aspects of 
getting large dumps off the machine and how to keep it from being abused.  So 
that’s the first part of it.

The second is that one of the things we’ve discussed with UofM is how to 
schedule pairs of tests in parallel.  They want to be able to do a throughput 
measurement and, at the same time, use SNMP to read counters from network 
equipment along the path under test.  Some of the recent development I’ve 
done for another feature includes code that runs tests programmatically.  It 
wouldn’t take long to adapt it into something that can schedule one task and 
then, once its run time is known, schedule the second for the same times (or 
slightly before and after so nothing gets missed).

How would something like that suit you?

--Mark