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

[Ben Pfaff]

Darrell, I think that you are working on some of the specific items that
Aaron listed.  Can you comment on that?

On Sat, Nov 25, 2017 at 07:37:23PM +0000, 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=
>     
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev