netdev - Connection Tracking: Single Table VS Multi Table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <AM6PR05MB52370F8A5ACA4F7D5B16F78ABD560@AM6PR05MB5237.eurprd05.prod.outlook.com>
Date:   Tue, 2 Apr 2019 14:34:01 +0000
From:   Guy Shattah <sguy@...lanox.com>
To:     Guy Shattah <sguy@...lanox.com>,
        Marcelo Leitner <mleitner@...hat.com>,
        Aaron Conole <aconole@...hat.com>,
        John Hurley <john.hurley@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Justin Pettit <jpettit@....org>,
        Gregory Rose <gvrose8192@...il.com>,
        Eelco Chaudron <echaudro@...hat.com>,
        Flavio Leitner <fbl@...hat.com>,
        Florian Westphal <fwestpha@...hat.com>,
        Jiri Pirko <jiri@...nulli.us>, Rashid Khan <rkhan@...hat.com>,
        Sushil Kulkarni <sukulkar@...hat.com>,
        Andy Gospodarek <andrew.gospodarek@...adcom.com>,
        Roi Dayan <roid@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Connection Tracking: Single Table VS Multi Table

Hi All,

Following our discussion on connection tracking: single table vs multi table I prepared a short comparison:
-------------

Terms to make the discussion clear:
Rule – IF-THEN clause composed of the form: 
if (packet classification) then (action)
Flow – a set of rules chained together.
Connection – an established connection between ORIGIN and REPLY.
Session – composed of two connections.

Single table method (ST):        multiple software rules which compose a chain are ‘compiled’ into a single hardware rule. 
Multiple table method (MT) : each rule from software layer is transferred to the hardware ‘as is’
* Packets which belong to a connection run inside a flow.

ST - Cons:
When several millions connections are active:
1.	Compilation is costly in term of CPU utilization. When dealing with Millions of rules then even a small CPU utilization 
grows very fast not to be a not small cost
2.	When having several flow tables chained together then a modification of one table 
in the middle immediately leads to  re-compilation or to flash of all the rules for all the flows ☹
This effectively means:
(1) a CPU spike.
(2) latency:  clearing a single ‘mega rule’ might take up to few seconds
(3) latency: a port down/route change can take few seconds.
it is worth mentioning that the typical required SLA is sub second.
3.	It is not clear how to compile flow which forks into two (or more) ends.
for example: packets go from within container to both external port and sampling
where only some of the packets are sampled, or  having a  mirror port with packets
sent there according to  some classification.
4.	Software needs to ‘remember’ the compiled version of a flow per connection.
ST - Pros:
1.	Fallbacks from hardware to software is easier to deal with
2.	each connection leads to a single hardware rule/entry.

MT – Cons:
1.	Not clear how to correctly fall from hardware flow into software flow.
2.	Multiple calls to connection-tracking within a single flow require multiple hardware entries.
MT – Pros:
1.	Easier to implement. Merely a reflection of what we already have.
2.	Cheap in terms of CPU utilization.