[ovs-dev] [CONNTRACK] Discussions at OvS 2017

Tiago Lam tiagolam at gmail.com
Tue Nov 28 17:29:30 UTC 2017


Hi all,

Thanks, Darrell. That sounds reasonable to me, nothing to point there.

But this leads me to my next question; With regards to integrating with SIP (or even SCTP), is there a list of the main use cases to support, or something similar? I guess this is still early days, but for SIP for example, I'd imagine that supporting the INVITE and respective 200 OK and inspecting the SDP to set up the expectations for the RTP connections would be a good first step. But what other methods are of interest out there?

Regards,
Tiago.

On 11/25/2017 07:37 PM, Darrell Ball wrote:
> Let me clarify some general points.
> 
> 1/ We will not be porting any code from the Linux kernel, whether it be SIP module code or anything else.
> 
> 2/ Furthermore, we will not be using proprietary code algorithms and other aspects from the Linux kernel.
> 
> 3/ Furthermore, those people working in, having worked in, or having been exposed to Netfilter code need to
> be careful about any “cross-pollination”, intentional or otherwise.
> 
> 4/ In addition, in general, we don’t think it is necessary to copy the behavior of the kernel; we look at
> each behavior and see if it makes sense or is necessary on its own technical merits. If we don’t think it
> necessary, overly complex,  or we have something better, we can omit that behavior entirely or do it differently.
> 
> Thanks Darrell
> 
> 
> 
> On 11/25/17, 9:47 AM, "ovs-dev-bounces at openvswitch.org on behalf of Tiago Lam" <ovs-dev-bounces at openvswitch.org on behalf of tiagolam at gmail.com> wrote:
> 
>     Hi Aaron (and all),
>     
>     Thank you for your email, I found it to be informative.
>     
>     Would you mind elaborating a bit more on point number 5 below?
>     
>     With regards to SIP (don't know about SCTP), a module [1] seems to already
>     exist for the kernel, integrating with Netfilter / conntrack.
>     
>     So, in terms of support for SIP in OVS' userspace conntrack (or any other new
>     protocol for that matter, but I'm most familiar with SIP), would OVS be
>     looking for a port, or a "from scratch" implementation? Or what would be the
>     preference here?
>     
>     Thanks and regards,
>     
>     Tiago.
>     
>     [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__people.netfilter.org_chentschel_docs_sip-2Dconntrack-2Dnat.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=Pfb29ck4yGzJEN3CgHQWatvLFA-XFUuMG_UWAKoutN0&e=
>     
>     On 11/20/2017 06:21 PM, Aaron Conole wrote:
>     > (NOTE: This is a resend - I fat-fingered the ovs email.  Apologies to
>     > those who got duplicates).
>     > 
>     > This email is meant to summarize some of the discussions we had at OvS
>     > conference.
>     > 
>     > The interest in the userspace conntrack is heating up.  That's a good
>     > thing, but it means that we'll probably have some growing pains as it
>     > relates to features and usages.  These are the topics and some
>     > additional information that we came up with.
>     > 
>     > 1. Making EST state match between linux kernel conntrack and userspace
>     >    conntrack.  We will need to make sure that the windows datapath
>     >    conntrack also matches.  The issue came down to the distinction about
>     >    whether commit action should also imply that the connection is
>     >    established.
>     > 
>     > 2. Disabling conntrack helpers 'on by default' in the userspace
>     >    datapath.  This represents possible security issue; users will want
>     >    to disable helpers (or enable helpers) at their own discretion.
>     >    One proposed resolution to this is simply disabling the helpers, and
>     >    relying on the 'alg=' specifier in the conntrack action. Complicating
>     >    this solution is existing users who rely on the existing solution -
>     >    specifically those users with the tftp helper and pxe booting in an
>     >    large data center.
>     > 
>     > 3. Performance analysis deep-dive.  We'd like to get input on the
>     >    performance of the userspace conntrack path.  There was discussion
>     >    that the performance was suffering - anything here like additional
>     >    tests people have, or data that can be shared is good.  The
>     >    development community is interested in knowing what it means.
>     > 
>     > 4. Hardware offload.  What will we need to present from that standpoint?
>     >    Are there counters or other information that software will need to
>     >    expose?  What does it mean for the userspace datapath to be aware of
>     >    hardware offload for conntrack?
>     > 
>     > 5. Additional protocol support and helpers.  We think SCTP, and SIP are
>     >    important.  Any others?  Anyone think this is useful work to do?
>     > 
>     > Thanks all for the presentations and discussions.
>     > _______________________________________________
>     > dev mailing list
>     > dev at openvswitch.org
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=0oFbn_OEVTacCVLYQVealZJQelpkp-hZmBriL5kLV_s&e=
>     > 
>     _______________________________________________
>     dev mailing list
>     dev at openvswitch.org
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=FfTX_mff2SgY4OCYC5YbZOO44fljLYgir7rk9fccjRQ&s=0oFbn_OEVTacCVLYQVealZJQelpkp-hZmBriL5kLV_s&e=
>     
> 


More information about the dev mailing list