[ovs-discuss] Hackaton follow-up: DPI engine integration proposal

Franck BAUDIN Franck.BAUDIN at qosmos.com
Fri Mar 28 15:19:55 UTC 2014


Hi Thomas,

> I see you are coding as root. I too like to live dangerously ;-)

I work with several GIT repos & backups, so danger is limited :-)

> Did you consider reversing the API and allowing for external modules to
> register a callback function for a specific hook? That would allow for multiple
> modules to use a hook at the same time.

That's a good point: we could deploy a general purpose hooking infrastructure on new flows, DPI being one user of this infrastructure, and others module being able to use them at the same time. In that case, miss->put_or_skip would be an AND between all modules verdict (true when all modules do not need any more packets of the current flow). Beside DPI, what kind of other modules do you foresee? A "conntracker" focused on L4?


> Do you intend to insert a dpi action for every unknown flow or are you only
> interested in targeted DPI for very specific flows?
>
> It would be great if you could provide some additional details here.

The idea is to use one or several OpenFlow rules as a gate to DPI: only the matching flows would enter the DPI, others flow won't be processed by the DPI. For example if you want to analyze only the traffic a given IP subnet. The use case permit to apply different QoS policies distinguish VoIP over HTTP, WEBDAV and web browsing for instance, for this subnet:
        ovs-ofctl add-flow br0 dl_type=0x0800, ip_src=192.168.0.0/16,actions=dpi:resubmit(,5)
        ovs-ofctl add-flow br0 dl_type=0x0800, ip_dst=192.168.0.0/16,actions=dpi:resubmit(,5)

The dpi action would update AXM registers (to be added, same as NXM ones but "Application eXtended Match)
        ovs-ofctl add-flow br0 table=5,axm0=0x01,actions=enqueue:1:0  # VoIP
        ovs-ofctl add-flow br0 table=5,axm0=0x02,actions=enqueue:1:1 # WEBDAV
        ovs-ofctl add-flow br0 table=5,axm0=0x03,actions=enqueue:1:2 # web browsing

Please note that neither dpi action neither axm are implemented yet ;-)

>  From what I've read so far it is unclear to me how new flows can be selected
> for DPI without negating the megaflow performance gains.

Megaflow performance gains were obvious on the userspace side: less flows -> less ressources -> more fps. Maybe also on the datapath, as hashing on 7 fields is faster than on 12, but I wonder if this gain is significant compared to the userland one.  Any measures/metrics available on these two points?

Impact of the DPI on the userland: ~20% of the actual capacity
=> The extra cost is only for DPI flow: on average 3 packets are required for a flow to be classified and pushed in the datapath. If DPI target 10% of the flows, this means ~20% of userland loss in term of fps capacity.

Impact of the DPI on the datapath: marginal?
=> The impact is only for the 10% of the flows targeted by the DPI. For them, the 7 fields megaflow will become a 10 fields megaflow, with the addition of the protocol & ports.

Alternate design: DPI as a dapath front-end
=> all packets, in particular the 90% untargeted one, go through the DPI and waste resources. I doubt this is acceptable.


> One possible idea that comes to mind is a DPI table that is inserted before
> the first wildcard table that is used to do selective DPI by inserting flows with
> userspace actions. These flows get removed after inspection.

Does a flow miss, in the datapath, cost more than a flow hit with a userspace action? If yes, your idea seems excellent!

Best Regards,
Franck
This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.


More information about the discuss mailing list