Thanks for sharing your experience! -Christian
On Sat, Jun 15, 2013 at 12:37 PM, Philippos Isaia <p.is...@lboro.ac.uk> wrote: > Hi, > > I was thinking of my idea 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 > entry/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", and I was > trying to find a way to eliminate that to see if the rate limiting works. > > And I have solved the problem. > > Instead of adding new meters and assign them to flow entries, I have decided > to assign just one meter and every time I want the rate to change, to just > modify that specific meter. > > Therefore, > > create meter > > dpctl tcp:127.0.0.1:6634 meter-mod cmd=add,flags=1,meter=1 drop:rate=10000 > > add the flow entries > > dpctl tcp:127.0.0.1:6634 flow-mod table=0,cmd=add in_port=2 meter:1 > apply:output=1 > > and every time I want to change the rate just execute the command > > dpctl tcp:127.0.0.1:6634 meter-mod cmd=mod,flags=1,meter=1 drop:rate=20000 > > and it works perfectly. > > Therefore problem solved! > > Regards, > Philip > > On 15 Jun 2013, at 15:57, Philippos Isaia <p.is...@lboro.ac.uk> wrote: > > 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. > > <tp13-061202-r.png> > > 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? > > > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > -- Christian _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
