SEO

On Fri, 19 May 2006, joerg@britannica.bec.de wrote:

>> PF state entries should be modified to include one more RB-tree entry,
>> used for state expiration.

> The problem with this approach is that any longer living connection has
> far more updates than actual expiring states. It should also be kept in
> mind that this adds a lot of cache trashing due to the constant tree
> updates.

This is a valid concern. However at least I find it practically impossible
to get PF firewall machine under any practical CPU/memory load before
packet loss starts to happen because of state expiration sweeps.
So yes, this might be expensive, but it still improves practical
performance in my opinnion.

> What exactly is your concern?

The sawchain effect causes jitter and lost forwarded packets when
connection initiation rate through a PF firewall is high. This causes
serious problems with voice applications where lost packets can be heard
easily. The only real solution is to smooth the expiration load.

However, a bigger problem is that at least the OpenBSD 3.8 code can't
keep the backup firewall state table synchronized with the master firewall
because of this effect, even though CPU is 80% idle. The biggest problems
are the TCP connections for which the closing sync updates are lost. They
end up living long time in the backup firewall, and should failover
happen, they cause a lot of state-mismatch blocks for new connections
which are reusing the same TCP ports.

> Replace this with a number of linked list and one of them
> every second / half second whatever. This adds very low additional
> overhead (one or two pointers per state, a few more instructions for
> creation and removal of a state), but the runtime costs are not changed
> at all.

Originally I though of keeping one LRU TAILQ for each timeout value. The
heads of these few lists could be checked for expiration on every
processed packet. This structure would be rather cheap and cache
friendly to keep. However I forgot that every rule can have separate
timeout values which makes the number of lists too huge to check at every
frame.

The 3.9 code seems to split the sweep into smaller pieces much like you
propose, but even that does not really solve the actual problem, just
moves it to a little bit higher state creation frequency.

--
Teemu J. Takanen
Product Security Manager, Tecnomen Messaging Services