perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Yamamoto, Miguel writes:

Just want to reach out again about this and if it’s possible to do?

 

Hey, I have to apologize.  I had a draft reply started and it got buried.  Let me rectify that.

 

Now I am trying to limit both the source and destination TCP bandwidth on whichever the test gets performed.

 

None of the tools we’ve integrated have provisions for destination-end caps, so bandwidth is limited on the source end.  You can configure destination-end limits to reject requests for tasks that ask for too much or no limit.

 

I currently got the TCP outgoing bandwidth to be limited to whichever IP on a set group. All outgoing bandwidth from Group1 is 1g, all outgoing bandwidth from Group2 is 500mb regardless of destination.

What I am trying to do is have Group1 source bandwidth change if the destination is in Group2 and vice versa. Ex:
- IP1 to IP2 will be 1G but IP1 to IP3 will change to 500mb

- IP2 to IP1 will be 1G but IP3 to IP1 will change to 500mb

Below are the example of group and the current rewrite. Please advice if it’s possible to achieve or if I am missing anything in the config file. Thank you!

Identifiers Section:   …

 

One thing to note about identifiers is that they exist to vet who’s making a request, not anything specified in the test parameters.  I could, for example, log onto Internet2’s perfSONAR node in Denver and have it ask the host at IP1 to do a throughput test to IP2.  The identifiers on IP1 would be given the Denver host’s address and those on IP2 would be given IP1’s address.  You can still use the rewriter or the jq limit to examine the test parameters, but those are taken at face value.  You’d have to cover the IPs and all possible FQDNs.

 

If I understand the rules correctly:

 

• 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

 

Any other set of test parameters is left alone.  Identifiers and classifiers don’t have to be involved because those are for requesters.

 

Rewrite Section:

 

There can only be one rewrite section; if you have multiple things to do, they all need to be strung together as a single script.  I’ve included an abbreviated version of how yours would be structured below.  The highlighted calls to change() are recommended practice so users looking at the diagnostics will know their tasks were rewritten.

    "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"

        ]

    }

 

Hope that helps.

 

--Mark