[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Flow miss/Packet order question
From:       blp () nicira ! com (Ben Pfaff)
Date:       2012-04-30 17:15:10
Message-ID: 20120430171510.GD2701 () nicira ! com
[Download RAW message or body]

I think that your explanation stems from a misunderstanding.  Yes, if
an OpenFlow controller uses a reactive model, then it cannot avoid the
problem.  However, I think that Joji is raising a different issue, one
that is an implementation detail within Open vSwitch and that
controllers have no power to avoid.

Let me explain in detail.  When a packet arrives for which there is no
kernel flow, the kernel sends it to userspace.  Userspace sends the
packet and sets up a kernel flow.  In the meantime, more packets might
have arrived and been queued to userspace.  Userspace will send these
packets, but any packets that arrive after the kernel flow is set up
will be forwarded directly by the kernel before those queued to
userspace go out.

On Fri, Apr 27, 2012 at 01:26:55PM -0700, Bob Lantz 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 <blp at nicira.com> 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 <blp at nicira.com> 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
> > > > discuss at openvswitch.org
> > > > http://openvswitch.org/mailman/listinfo/discuss
> > > > 
> > 
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> 


[prev in list] [next in list] [prev in thread] [next in thread]