perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Jarett DeAngelis writes:

iperf3: It seems like installing perfSONAR does not make a machine an iperf3 server, for example, although it does install the package. OWAMP and TWAMP are installed and running by default, on the other hand. … This would imply that a common testing configuration could be one node running perfSONAR and many others running nothing other than `iperf3 -s` with no coordination or common configuration with the perfSONAR machine. Is that correct, or am I missing something here?

The bit you’re missing is pScheduler, which oversees all of the measurements on a perfSONAR system.  To make a very long story short, pScheduler arranges a mutually-agreeable time for a pair of hosts to run a throughput test.  When that time comes, one side starts up the client, the other starts the server, the measurement is done and both are shut down.  We intentionally don’t run an open iperf3 (or iperf2, nuttcp or Ethr) server because it would allow other systems to connect and do their own bandwidth measurements that would distort scheduled measurements or prevent them from happening in the first place.  More-recent versions of the iperf3 plugin go so far as to use one-time authentication data so the server side will only service the client that should be using it.

Latency measurements, which aren’t huge consumers of resources, are handled differently.  Unlike throughput, only the sending side worries about the schedule.  The input we got from our heavier users when we were designing this thing was that a one-shot measurement should run in an environment clear of high interface traffic levels so it’s as accurate as possible but streaming measurements should run in the background and accept any distortions.  Any of the latter can be correlated with concurrent throughput tests.  In order to make all of that work, we made the decision to not have both ends cooperate and run open [OT]WAMP servers.  This turned out to be a good thing because some network equipment runs TWAMP natively and that opens up another avenue for measurement that wouldn’t have existed if there had to be an instance of pScheduler present to make it work.

authn/authz: You are prompted during setup to create local user accounts for logging into the web interface and the shell. I can't tell whether or not directory service support exists in the software such that one can auth to the server (and have role based access control) using LDAP, Active Directory, FreeIPA or similar services.

Being a large project with a relatively small staff, we operate on a “give the users what they tell us they want” model.  Nobody’s asked us to support directory services, so we haven’t.  That said, lots of our users pre-configure a system to their site’s standards and then install perfSONAR, which would allow for that.  Logins are something of a holdover from the days of BWCTL, when you had to be logged onto the system to do measurements.  pScheduler’s REST API is a direct result of wanting to eliminate that.  As for the web interface, LDAP or anything else could probably be configured into Apache without a lot of gymnastics.

central management: The scope of what perfsonar-centralmanagement does is not super clear to me -- minimally it sounds like it's related to pSconfig?

Partially.  The Central Management bundle installs a the pSConfig publisher, an archive to store measurements and a MaDDash server for looking at the results.  You still have to develop what the publisher publishes manually or with the pSConfig Web Administrator),

Hope that helps explain it all.

--Mark