Hi Yusuke,
I am afraid what you are commenting is not the issue I was pointing out. I
am going to reexplain it because after reading again it may be
missunderstanding.
The phenomena I was trying to explain is the following:
When a new flow arrives to the network, the first packet of the flow goes
to the controller in a packetin request if there is not a matching rule in
the flow table.
The question is, if the rate of the flow is high enough so the time between
consecutive packets of a flow is lower than the latency associated to the
fact of sending the packetin request+process it+ sending packetout, several
packetin requests for the same flow will be generated.
This causes the out-of order phenomena I was commented previously: it
arrives one point where a packet of the flow see the rule in the table and
it is forwarded but there are still packetin requests from previous packets
still processing at the controller or in the way back to the switch.
Has someone experienced this? In fact, it happens with a UDP flow of 1M and
the out-of-order phenomena is more accentuated as the flow rate increases.
As commented before, my initial solution is to store information about
flows and datapath ids at the controller to discard the packet in messages
if it comes replicated, but i think is not a smart enoubh solution. What do
you think?
Jordi
2015-02-06 3:18 GMT+01:00 Yusuke Iwase <[email protected]>:
> Hi Jordi,
>
>
> On 2015年02月05日 23:52, Jordi Baranda wrote:
> > Dear all,
> >
> > I am starting to work with SDN concepts and I am noticing there is a lot
> of challenging issues behind this paradigm. After solving the ARP flooding
> problems (thanks to contributors of the mailing list), I have discovered
> another interesting issue.
> >
> > I am working with the mininet(OpenVswitch) +Ryu environment and I am
> trying to get familiar with rules and flow tables. In order to do so, I use
> iperf to generate traffic. My question comes here:
> > Normally, I work with UDP flows of 1M and I have realised that there are
> some packets that are out-of order. This is due to the latency in the
> communication between switch and controller. Of course, if I increase the
> bit rate of the flow, more out-of-order packets are produced.
> > Is there any way to control it? I mean, can we configure the openvswitch
> to buffer packets until the packet-in is received?
>
> I guess it maybe gets the performance limit of the "mininet + Open
> vSwitch" environment.
> I tried some iperf test as follow.
>
> # Conditions: Flow entries are already exist and Ryu are NOT working.
> mininet> sh ovs-ofctl dump-flows s1
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=315.099s, table=0, n_packets=216, n_bytes=303600,
> idle_age=259, priority=0 actions=CONTROLLER:65535
> cookie=0x0, duration=259.932s, table=0, n_packets=2718805,
> n_bytes=3347515588, idle_age=22,
> priority=1,in_port=2,dl_dst=00:00:00:00:00:01 actions=output:1
> cookie=0x0, duration=260.013s, table=0, n_packets=1830425,
> n_bytes=25078177190, idle_age=22,
> priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:2
>
> mininet> iperfudp 100M h1 h2
> *** Iperf: testing UDP bandwidth between h1 and h2
> *** Results: ['100M', '101 Mbits/sec', '101 Mbits/sec']
>
> mininet> iperfudp 500M h1 h2
> *** Iperf: testing UDP bandwidth between h1 and h2
> *** Results: ['500M', '512 Mbits/sec', '512 Mbits/sec']
>
> mininet> iperfudp 1000M h1 h2
> *** Iperf: testing UDP bandwidth between h1 and h2
> *** Results: ['1000M', '813 Mbits/sec', '813 Mbits/sec']
>
> Like above, on my environment, around 800Mbps is the bandwidth limit.
> Then, Please check your environment spec.
>
> Thanks
>
> > I have came out with a solution that is to store information about flows
> and datapath ids at the controller to discard the packet in messages if the
> come replicated, but I think is not a smart enough solution. What do you
> think?
> > (when I say discard is to return from the _packet_in_handler function
> of the app "simple_switch_13.py" without doing anything)
> >
> > Thank you very much for your time and attention,
> >
> > Kind regards,
> >
> > Jordi Baranda
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> >
> >
> >
> > _______________________________________________
> > Ryu-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ryu-devel
> >
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
