perfSONAR User Q&A and Other Discussion

["Yamamoto, Miguel" <>]

Hi mark,

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.

 

This is interesting, is there an example that you could show me for the rewriter? Using the rewriter below and have all IPs (IP1-3) in Group2-limit-500mb, I can limit everything to 500mb but this would not be the case as we have few devices to restrict at 500mb, and some at 1G.

         "rewrite": {

        "script": [

            "500000000 as $tcp500mb",

            "| if …conditions…",

            "  then",

            "    .test.spec.bandwidth = $tcp500mb | change(\"Capped throughput at 500 Mb/s\")",

            "  else .",

            "  end"

        ]

    }

·         IP1’s limit config should use the rewriter to examine the destination of throughput tests and rewrite the bandwidth to 1 Gb/s if it’s IP2 or 500 Mb/s if it’s IP3.

·         IP2’s limit config should use the rewriter to examine the destination of throughput tests and rewrite the bandwidth to 1 Gb/s if it’s IP1

·         IP3’s limit config should use the rewriter to examine the destination of throughput tests and rewrite the bandwidth to 500 Mb/s if it’s IP1

As of right now, there is no way to limit 1G and 500Mb at the same time for one limit configuration? I tried the rewriter below as well but results still the same.
- IP1/IP2 bandwidth to IP3 is 1G rather than 500Mb and vice versa

    "rewrite": {

        "script": [

            "1000000000 as $tcp1g",

            "| if …conditions…",

            "  then",

            "    .test.spec.bandwidth = $tcp1g | change(\"Capped throughput at 1 Gb/s\")",

            "  else .",

            "  end"

            "| 500000000 as $tcp500mb",

            "| if …conditions…",

            "  then",

            "    .test.spec.bandwidth = $tcp500mb | change(\"Capped throughput at 500 Mb/s\")",

            "  else .",

            "  end"

        ]

    }

 

Thanks for all the help,
Miguel

 

From: Mark Feit <>
Date: Friday, March 29, 2024 at 1:04 PM
To: Yamamoto, Miguel <>, <>
Subject: Re: Limit TCP Throughput Bandwidth to 500Mb

(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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

(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