> In practice you can easily solve the problem either by pushing down routes proactively
I am not sure that this will solve the problem - per my understanding, the rules that are pro-actively pushed are still in user space. Is there a way to push them down proactively to the DP? > or by buffering somewhere (e.g. at the receiver.) You mean restoring the packet order at the receiver endpoint? This also has practical difficulties and is usually not a good option. -Joji. On Fri, Apr 27, 2012 at 1:26 PM, Bob Lantz <[email protected]> wrote: > It does indeed happen with UDP flows (or if a rule is removed while a flow > is active) and it's easy to observe. > It's not a bug in Open vSwitch, which is in fact implementing the correct > OpenFlow behavior. > In practice you can easily solve the problem either by pushing down routes > proactively or by buffering somewhere (e.g. at the receiver.) > > On Apr 27, 2012, at 7:39 AM, Joji Mtt wrote: > > I currently do not have a real scenario where I have run into this problem. > > However, it is easy to see real scenarios where I could run into this. As > you said, most flows start off with a single packet and wait for a > response. But, there is also the flow eviction mechanism which would bring > this into play mid-flow. There is also the UDP traffic which does not have > a ramp up mechanism. Yes, the window is small. But, I think it is real and > could problems for some applications. > > -Joji > > > On Thu, Apr 26, 2012 at 10:22 PM, Ben Pfaff <[email protected]> wrote: > >> It isn't commonly a problem in practice because flows most often start >> off with a single packet and wait for a return packet before ramping up >> packet volume. I've been aware of the issue for years, but you are the >> only other person I ever recall bringing it up on the mailing lists. >> >> Do you have a real situation (not a hypothetical scenario) where you see >> this causing trouble? >> >> On Fri, Apr 27, 2012 at 11:06:29AM +0600, junaid khalid wrote: >> > Are you planning to solve this problem in near future or do you have any >> > suggestions to mitigate this problem? >> > >> > On Thu, Apr 26, 2012 at 2:37 AM, Ben Pfaff <[email protected]> wrote: >> > >> > > On Wed, Apr 25, 2012 at 01:33:56PM -0700, Joji Mtt wrote: >> > > > I am trying to figure out if there would be a packet order issue >> with the >> > > > current version of OVS. Consider a case where a controller has >> added a >> > > > forwarding rule for a specific flow (Flow A) and this rule is not >> yet >> > > > installed in the DP. In this scenario, it is conceivable that >> certain >> > > > (bursty) traffic patterns on Flow A can result in the packets being >> sent >> > > > out of order. E.g. consider an initial burst of 5 packets that miss >> the >> > > > kernel flow table, followed by several subsequent packets arriving >> at >> > > > random intervals. As soon as the userspace processes the flow miss, >> it >> > > will >> > > > install a rule in the kernel. Depending on the relative timing of >> the >> > > rule >> > > > installation, any of these subsequent packets could get switched >> directly >> > > > by the kernel before the previous packets that took the slow path >> could >> > > get >> > > > forwarded. I couldn't find any special handling to cover this case. >> Most >> > > > likely it is already handled and I am just missing the part where >> it is >> > > > done. Could anyone clarify this for me? >> > > >> > > Yes, it's possible to get out-of-order packets for this reason. >> > > _______________________________________________ >> > > discuss mailing list >> > > [email protected] >> > > http://openvswitch.org/mailman/listinfo/discuss >> > > >> > > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss > > >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
