Server-side limiting switches

[mfeit-internet2]

In perfsonar/pscheduler#518, I opined that bandwidth curbs imposed by the limits in perfSONAR are on the honor system because the destination (iperf3 server-side) participant has to trust that the source (client-side) will throttle itself to the agreed-upon maximum speed.

I'd like to propose the addition/re-use of these switches for the server mode as a way for the pScheduler iperf3 plugin to enforce some of the limits

• -b - Forcibly terminates the test if the measured bandwidth during any interval exceeds the specified value. (I'd also be interested in hearing your feedback on what kind of measures could or should be taken to soften this in light of the fact that every so often the results contain an outlier.)

• -t - Forcibly terminates the test if it runs longer than the specified time.

• -u - Allows the client to request UDP.

While not a perfect solution, this would give the receiving end a way to end its involvement if it thinks the client is holding up its end of the bargain.

[bmah888]

OK, I'm pondering this. I think I understand your concern for protecting the server process.

You're quite right that there can be transient intervals where the bitrate exceeds the target. We can also have tests running longer (but not much longer) than specified with -t due to network delays and possibly weird timing races (#278 is a quasi-example of this). Couple questions:

1. In the perfSONAR use case, I understand that the main stopping condition is time-based (-t). Is that the only one? iperf3 supports a couple of other stopping conditions on the client, e.g. -n (total number of bytes) or -k (number of sends).

2. Is the expectation that pSchedule will use the same flags to specify server limits as what the client wants?

[mfeit-internet2]

0. The bitrate and time limits don't have to be exact, just something where the server can reasonably decide the client has overstayed its welcome and put a stop to the test. The bandwidth end of it is more important than time for reasons I'll outline below.

1. pScheduler runs tools based on time because scheduling is done on a timeline instead of queues like BWCTL did. We build in some extra time at the end in case the tool we're running doesn't end exactly on time, but after that it will be killed off. If we know that the time tolerance is going to be, say, 5%, we can adjust the iperf3 plugin's expectations to accommodate it.

1a. The other reason I'd like the tool to exit on its own is for diagnostics. If it exits and explains why, that's more useful than our ham-fisted "we killed it because it ran longer than expected." The latter is in place as a watchdog so we can be positive the test has been shut down before its scheduled time ends.

2. It's more about preventing abuse of the server by a malicious client. Say client C has a maximum bandwidth limit of 2 Gb/s and server S has a limit of 1 Gb/s. Under normal circumstances, C will collect information about what the limits on both ends are, figure out the fastest rate either side will allow and run iperf3 accordingly. It would be a trivial exercise to modify C so iperf3 is invoked with a large value for -b switch (or none at all), giving C the ability to run at any bandwidth it wants without regard to the limits on S. This is a way to close that loophole.

Iperf2 and Nuttcp have the same vulnerability. If we can't convince the maintainers of those programs to do the same thing, sites have the option of rendering pScheduler unaware they exist by un-installing their plugins.

This isn't a high-priority thing, either, so ponder it all you need.

[igarny]

There is nothing I can add to this, but to thank you guys!

[bltierney]

One more point I'd like to add: If a perfSONAR admin wants to limit bandwidth for the entire host, they should really do that using tc:

tc qdisc add dev $ETH root fq maxrate Ngbit

But if they want to limit some users to bandwidth X, and others to bandwidth Y, this would be useful.

[mfeit-internet2]

FQ's only going to affect outbound traffic, which we have a way to handle even without it. Either way, the downside to using TC is that the throttling becomes a characteristic of the network and it leaves are no hints to anyone looking at run diagnostics that it was a factor.

[bmah888]

Note that issues #354 and #355 are somewhat related to this enhancement request.

[bmah888]

The server-side time limit is also discussed in #354.