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 b...@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 b...@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@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
