[ovs-discuss] packet reorderoing

[swair shah]

>
> I don't see how that can solve the problem that he is reporting.  Did
> you read his whole scenario?  If we knew how to handle the packet in the
> datapath at the beginning of the scenario then we would not be sending
> it to the controller.
>
> I doubt that this is a real problem that needs to be solved, because
> it's been in the back of my mind since about 2008 as a possible concern
> but this is the first time I remember anyone actually voicing it.  Swair
> hasn't explained how it actually shows up as a problem in practice.
> Swair?
>

I ran into this case when running some tests with streams of UDP datagrams.
Clearly in case of TCP, the flow would gradually build up and this case
would not occur as only the first 'ack' would not be followed by any
packets before the handshake is done. I am not sure how significant this
problem would be in real world scenarios.

Can this be done:
If we define flow as the set of packets with 'similar' header (I am not
sure on the granularity with which one would define 'similar' in this
case), then after the first packet buffer each subsequent packet in a
ordered list (and probably don't send Packet_In, for subsequent packets;
but this can be a configuration). In response to packet_out for first
packet forward all the packets from that list.

Again, the issue is how would you decide if two packets are 'similar', i.e.
are to be queued in the same list.

Another probably highly inefficient way to do is to check all the buffered
packets in response to every packet_in.

thanks,
swair.


>
> (Also, this particular manifestation of the issue can only occur with
> reactive controllers, which don't scale.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150309/ba92926f/attachment-0002.html>