Test TWAMP integration

[laeti-tia]

We need to make sure the new pScheduler TWAMP plugin is working fine for usage in the perfSONAR toolkit. That means we need to test:

• [x] pscheduler CLI task with TWAMP
• [x] TWAMP measurement storage into esmond
• [x] twping mesh measurements with psconfig/mesh-admin GUI
• [x] visualisation of TWAMP latency measurements
• [x] visualisation of TWAMP roundtrip time measurements
• [ ] perfSONAR toolkit test configuration dialog with the rtt TWAMP tool

And all other I've missed.

[vvidic]

I wanted to ask about TWAMP measurement storage and pscheduler integration. Since twping output provides latency info for both directions of the connection I'm not sure it fits the current test and storage types (RTT, latency) or we need to create something new? Can a pscheduler tool output two latency results for both directions (c->s and s->c)?

[mfeit-internet2]

Tool plugins for programs that provide multiple results can be written two ways:

• Single-test: Each plugin runs the same program but handles a different type of test. For TWAMP, you might write twamp-rtt and twamp-latency, each of which says they'll do whatever test is in the name. These tend to be simpler to write and maintain, but there's the risk of duplication of some code.

• Multi-test: One plugin runs the program and handles all tests. The trade-off here is that the code becomes a bit more complex, but you don't have to duplicate code that parses output or turn it into a library that serves multiple plugins.

A tool's job is to produce the requested measurement. The concept of "bonus material," or extra results provided when they're a side effect of another test, has been discussed, but it's logistically-complex and nobody's clamoring for it. Other than throughput, the cost of doing multiple runs for most tests is minimal.

[vvidic]

On Tue, Feb 27, 2018 at 03:20:35PM +0000, Mark Feit wrote:

Tool plugins for programs that provide multiple results can be written two ways:

• Single-test: Each plugin runs the same program but handles a different type of test. For TWAMP, you might write twamp-rtt and twamp-latency, each of which says they'll do whatever test is in the name. These tend to be simpler to write and maintain, but there's the risk of duplication of some code.

• Multi-test: One plugin runs the program and handles all tests. The trade-off here is that the code becomes a bit more complex, but you don't have to duplicate code that parses output or turn it into a library that serves multiple plugins.

A tool's job is to produce the requested measurement. The concept of "bonus material," or extra results provided when they're a side effect of another test, has been discussed, but it's logistically-complex and nobody's clamoring for it. Other than throughput, the cost of doing multiple runs for most tests is minimal.

Ok, it's just that a single twamp test gives us all of this data:

• latency A -> B
• latency B -> A
• RTT calculated from the above

but we are only ever using one of these. Fine by me to drop the rest, just wanted to check if we want to do something else here.

-- Valentin Vidic Computer Systems Engineer - Expert Department of Computer Infrastructure and Services Croatian Academic and Research Network - CARNET Josipa Marohnica 5, HR-10000 Zagreb, Croatia tel: +385 1 6661 714, fax. +385 1 6661 635 gsm: +385 91 2480 919 www.CARNet.hr

[mfeit-internet2]

If it's not part of the standard result for the requested test, drop it on the floor. We could do a couple of things to take advantage of TWAMP's additional data:

• Add a reverse switch to the latency test that would make tools that know the reverse-direction latency supply the B->A value instead. (This would be different from flip, which originates the test at the far end and isn't supported by TWAMP as far as I know.)

• Add a protocol field to the rtt and latency tests that specifies the preferred protocol. This is truer to the architecture than forcing use of a specific tool. If the test specifies the twamp protocol, the regular ICMP pinger or OWAMP plugins would take themselves out of the running.

Note that there are some schema-related things we have to do if the test specs change, so please work with me if you decide to do those things.

[vvidic]

On Tue, Feb 27, 2018 at 06:56:49PM +0000, Mark Feit wrote:

If it's not part of the standard result for the requested test, drop it on the floor. We could do a couple of things to take advantage of TWAMP's additional data:

• Add a reverse switch to the latency test that would make tools that know the reverse-direction latency supply the B->A value instead. (This would be different from flip, which originates the test at the far end and isn't supported by TWAMP as far as I know.)

Yes, I added the flip thing to the twping plugin but maybe it should have been called reverse like you suggest here :)

• Add a protocol field to the rtt and latency tests that specifies the preferred protocol. This is truer to the architecture than forcing use of a specific tool. If the test specifies the twamp protocol, the regular ICMP pinger or OWAMP plugins would take themselves out of the running.

Note that there are some schema-related things we have to do if the test specs change, so please work with me if you decide to do those things.

Ok, than we probably don't need this for the initial TWAMP integration, but can add it later if required.

-- Valentin Vidic Computer Systems Engineer - Expert Department of Computer Infrastructure and Services Croatian Academic and Research Network - CARNET Josipa Marohnica 5, HR-10000 Zagreb, Croatia tel: +385 1 6661 714, fax. +385 1 6661 635 gsm: +385 91 2480 919 www.CARNet.hr

[vvidic]

Do we try to add twamp latency to current meshconfig or should we wait for psconfig?

[laeti-tia]

TWAMP latency measurements are currently a bit misleading. I created https://github.com/perfsonar/graphs/issues/115 to try to find a better solution.

[laeti-tia]

All tests have been done except for https://github.com/perfsonar/toolkit/issues/318 which will most likely be part of next closing. Hence closing.