Recently I’ve been optimizing my firewall rules. MikroTik offers two traffic acceleration methods: FastTrack and NoTrack. I’m wondering whether NoTrack might be a better option for IPv6 BitTorrent traffic.
No. Just made a benchmark for another thread. Notrack performs the same with regard to fw cpu usage.
Where notrack helps is when you have a lot of (unsolicited) ddos or port scan traffic. In these cases notrack prevents the conntrack entry from being created. For normal traffic it doesn't help one bit. Fasttrack is significantly faster, so use that if possible in your use case.
IMO NoTrack would be faster where connection tracking table is a long one (with many concurrent active connections via router).
Reasoning: with connection tracking enabled, router has to check each passing packet against connection tracking table. After that it can determine if packet can pass the fast track path. With small connection tracking table, this process is a quick one, with longer connection tracking table it becomes a most costly operation of all packet processing steps.
If packet can skip connection tracking process, then this (potentially) costly operation can be skipped ... and can still enter fast track[*] if fasttrack rule configuration includes untracked in connection-state property (which in default config doesn't).
Surely untracked packet processing can be more costly than processing of fast-tracked packet ... if firewall filter rules don't accept the untracked packet early (and has to pass all the firewall filter rules). And yes, processing all packets in raw (to set notrack to certain packets) does come with processing cost ... which is not there with default fasttrack-enabled firewall.
[*] I'm not sure about this actually working ... it can be set, but I don't know if it actually works.
Actually, with the way the conntrack table is implemented in Linux, the lookup performance is not much affected by the numbers of active entries in the table. Of course, if the table is tiny and can fit in the CPU cache then it will be faster, but otherwise (if table is larger than CPU cache) the difference is negligible, because it's implemented as a hash table:
Connection tracking (conntrack) - Part 2: Core Implementation [Thermalcircle]
and normally lookup is a O(1) operation (not even O(log n)) that requires constant time, unless there is a hash collision of the keys. But then hash collisions can also happen with small number of entries, because it depends on the keys, the hashing algorithm chosen, and the hash size (which depends on the size of the RAM). For example, your table only has 60 active entries but 50 of them are in the same hash buckets, then it would still be slower than a table with 4000 entries but with none of the buckets having more than 10 entries.
The biggest downside of more entries is that more RAM is consumed. So usually there is an upper limit to the size of the table based on the RAM size, and if you have more connections to track than that limit, then entries need to be dropped. But let's say the limit (based on RAM) is 65536 entries, then there should be no lookup speed difference whether you are currently tracking 200 items or 20000 items.
And when there are more entries, then the garbage collection worker that runs in parallel has to do more work, but this doesn't affect the lookup performance.
NoTrack is for services where creating a tracking entry would be useless because there is only one request/reply to be expected.
That would not only be DDoS attacks, but also things like NTP service, e.g. when you are a member of the NTP pool.
@CGGXANNX thanks for explanation, I've learned something new.
If a packet has to be checked against connection tracking table, then hash value has to be calculated. Yes, it's a relatively cheap operation, but for NoTrack packets even this can be skipped. And even cheap operations, when done millions of times per second become rather expensive.
The OP proposed it would be “for IPv6 BitTorrent traffic” and then it is not that much different, but as mentioned when you are member of the NTP pool, you can get many many single UDP packets from thousands to hundreds of thousands of individual addresses, all of them have to receive a reply and then you don’t hear from them for a minute, 10 minutes, an hour or whatever their sync interval is.
In that situation there will be many useless entries in the tracking table, that first had to be created (memory allocated, hash calculated, entry linked in the hash chain) and in these entries a timer object has to exist that at some time a couple of seconds later will expire, and the whole process has to be reversed. All for nothing, because no “established/related” traffic will ever arrive.
In that kind of circumstances it can be better to have no tracking. A similar situation could arise when running a DNS server for a domain.