> > 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.) >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
