Hi, Any chance you are experiencing the effect of the "burst tolerance" associated with the meters? I believe that when you switch to the new meter, your traffic quickly consumes the burst tokens - causing the peak - and once the tokens are depleted, the meter starts working.
It would be great if you could run the same experiments, but with explicitly setting the burst size to zero in dpctl. This could confirm, or rule out my guess. Thanks, Zoltan From: openflow-discuss-boun...@lists.stanford.edu [mailto:openflow-discuss-boun...@lists.stanford.edu] On Behalf Of Philippos Isaia Sent: Saturday, June 15, 2013 4:58 PM To: openflow-discuss@lists.stanford.edu Subject: [openflow-discuss] OpenFlow 1.3 Rate Limiting Anomaly Hi, I would like some help with the OpenFlow 1.3 implementation, specifically per flow meters. What I am trying to do is to limit the rate of flow for the packets send from one host to another. For the time I am running my experiment both on Mininet and on a TP-Link router using OpenWRT with OpenFlow 1.3. In order to create this rate limitation I am using dpctl. First of all I create the meters and then apply them to the connection once I want the specified limiting to take place. Here is an example of how I create the meters and then apply them. Create Meters dpctl tcp:127.0.0.1:6634 meter-mod cmd=add,flags=1,meter=1 drop:rate=10000 dpctl tcp:127.0.0.1:6634 meter-mod cmd=add,flags=1,meter=2 drop:rate=20000 Apply Meters Initial Meter: dpctl tcp:127.0.0.1:6634 flow-mod table=0,cmd=add in_port=2 meter:1 apply:output=1 After 10seconds: dpctl tcp:127.0.0.1:6634 flow-mod table=0,cmd=add in_port=2 meter:2 apply:output=1 Problem I am using Iperf and Jperf to run my experiments. I am sending UDP traffic from one host to another. When I have the first meter active, I get a bandwidth of around 10Mbits. The problem is that once I apply the second meter, instead of getting a smooth increate to around 20Mbits, the bandwidth for a second goes to around 30-35Mbits and then settles down to 20Mbits. I have repeated the experiment several times using either Mininet (with OpenFlow 1.3) or the TP-Link router with OpenWRT. All of the runs are identical. [cid:image001.png@01CE6A0B.C13BA860] Anybody having any idea what is causing such an anomaly? I came up with several ideas and investigated them with several experiments but the anomaly still exists. Here are my ideas and the experiments. Idea 1 Instead of immediately doubling the bandwidth, I tried to make a more smooth change. Therefore instead of having: Meter 1 = 10000 Meter 2 = 20000 I created some in between steps to see if the anomaly still exists, like: Meter 1 = 10000 Meter 2 = 10500 Meter 3 = 11000 Meter 4 = 11500 Unfortunately there is the same anomaly as before. Even if the difference between the meters is just 1. Like from 10000 to 10001. Idea 2 Maybe, during the rate change, there are some asynchronous packets in the buffer that may get processed, and maybe that is the reason for such a higher bandwidth. Therefore what I did was to make the buffer size equal or even smaller than the packet size. Through that process I wanted to actually eliminate the possibility that packets may remain in the buffer. Therefore no asynchronous packet processing can take place. Unfortunately the result remains the same! Anomaly still exists. Idea 3 I believe that there is a small time interval every time you change the limit. In that time interval, the switch/router disables the previous limit and enables the new limit (i.e. flow table modification). But as soon as the previous limit is disabled, the switch/router is sending data without any restriction, until the new limit is enabled. That time interval causes increase in bandwidth.", is the strongest candidate for the anomaly I face. Therefore, does anybody knows what is the problem that cause such a behaviour? Any possible suggestions? Solutions?
<<inline: image001.png>>
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
