perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

(Re-added perfsonar-user since it’s of general interest)

 

Yamamoto, Miguel writes:

 

That is correct, this is what I am trying to do. Both IP1 and IP2 will be in Group1 at 1G and IP3 will be in Group2 at 500Mb/s. I am trying to restrict IP3 to only have a cap of 500Mb/s incoming and outgoing requests. I also want to just have one limits.conf attach to all node.
…

From this reply, it looks like there is no way to have one limits.conf file for all nodes to limit from the destination-end? I still want to do request rather than rejecting the request. As mentioned, it’s more of just restricting the IP3 (or other IPs) to have 500Mb/s and not go above that.

 

There are a couple of scenarios in play here:

 

One is where you control every machine that will ever do a throughput test with IP3, such as if they’re on a private network.  In that case, you can write a single limit configuration whose rewriter detects throughput tests to or from IP3 where the bandwidth parameter is unspecified or more than 500 Mb/s and rewrites them to 500 Mb/s.  That’s the easy case.

 

The other is where hosts you don’t control will be asking IP3 to do throughput tests.  Because there’s no way to force them into submission, your choices are to live with higher-bandwidth tests, refuse to do them or use Linux’s traffic control features to limit the bandwidth to/from the ports used for throughput.  If you choose to reject high-bandwidth tasks, you could include a message about why the task was rejected (e.g., using reject(“Bandwidth must be 500 Mb/s or below”) in the rewriter) and users could re-submit something acceptable.

 

For what it's worth, we’ve considered putting in a feature where a task is put through both the first and second participants’ rewriters.  It opens a big can of worms because both ends of a test could rewrite the parameters in conflicting ways and cause one or both to participate in tests the would go against their policies.  I could probably find a way to do that safely, but the demand hasn’t been there for it.

 

HTH.

 

--Mark