Re: [RFC] alternative to conntrack ID

[Pablo Neira <pablo@eurodev.net>]

Hello Jozsef,

Jozsef Kadlecsik wrote:
> On Fri, 10 Jun 2005, Pablo Neira wrote:
> 
> 
>>>How are you going to handle id collision due to wraparound?
>>
>>yes, 8 bits is too short. About the wraparound problem, I'm planning to
>>re-use id's. The id of a new conntrack will be set to the lastest
>>inserted in the bucket plus one.
>>
>>However this wouldn't uniquely identify a conntrack: Say a connection is
>>established, lastest conntrack in the bucket uses id A, so its id will
>>be set to A+1. After quite some time the connection is closed. Then, in
>>a very short period of time, another connection with the same tuples is
>>established and lastest conntrack id is still A, in that case the id of
>>the new conntrack will be set to A+1 again.
> 
> 
> Wouldn't be more straightforward to store the last assigned id value in
> the bucket and simply increment that whenever the next value is used up?
> (Id collision is actually not a big problem, because the entries are
> identified by the tuples in the first place.)

Right, but then I'll have to face another problem, once the wraparound 
happens the conntracks inserted in the bucket aren't ordered by the id 
anymore. Currently if the skbuff that is going to be sent to user space 
via netlink gets full (one page sized), I'll need to know which was the 
lastest processed conntrack, including possible race conditions, ie. the 
conntrack expires while netlink is returning the packet to user space. 
This is controled by the following branch while iterating over the list:

                         if (ct->id <= cb->args[1])
                                 continue;

That's why I came up with the idea of re-using id's, I want to avoid a 
wraparound. BTW, inserting conntracks in order isn't a solution either, 
since this will break LRU early drop.

> At dumping we could use the flip-bit solution: entries which are already
> dumped were marked with the next value of the bit. Of course user requests
> for dumping must be serialized, but conntrack replication could benefit
> from such schema, because new entries could be added to the conntrack
> table and replicated during full conntrack table replication as well.

Could you elaborate this idea about the flip-bit solution, please? looks 
interesting.

I'm still looking for a solution based on a simpler logic, we'll see ;).

--
Pablo