Threshold with TCP

[Bastien Veuthey]

Hi,

I am currently experiencing a problem with the threshold for TCP communications. I use the same script described in this article: https://blog.sflow.com/2016/05/mininet-flow-analytics.html with 10Mbits as threshold (so 1.25MBytes). For the tests, I use iperf3. With UDP, I have no problem, the event linked with the threshold is correctly triggered when a communication exceeds the limit. But with TCP it is more tricky as sometimes, even with a bandwidth inferior to the limit, the flow is captured. For example: 'iperf3 -c <ip> -p <port> -b 800K -t 12' can trigger the event. 

Is there a margin of error in the implementation of the threshold to be careful with? I have done many tests with even a 50Mb threshold but the problem still occurs.
Thank you for your help.

[Peter Phaal]

Have you tried running the Mininet Dashboard application?

https://blog.sflow.com/2016/05/mininet-dashboard.html

The attached screen shot shows three iperf3 tests with -b 800k, -b 1600k and -b 2400k. You can see as the traffic goes up the measurements across the three links in the path start to converge because the larger flows generate more samples and so the percentage error on the measurements is lower, https://sflow.org/packetSamplingBasics/index.htm.

You can improve accuracy by increasing time window (although you get a slower response) or by increasing the sampling rate (at the cost of a higher measurement overhead). Flow smooting, describes how the t setting in the flow definition smooths out the variability in flow measurements.

There is additional information accessible through the embedded JavaScript interface that can be used to ignore threshold events if there aren't enough samples to be sure of the threshold crossing. See sflow-rt/ddos-protect application.