Re: states worth to replicate [was Re: [PATCH] add TCP protocol state event groups]

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
> 
>>>Replicate ESTABLISHED TIME_WAIT for TCP
>>>
>>>Thus, only established and time_wait states are replicated. My plan is
>>>to add similar clauses for other protocols so:
>>
>>Is that set of states useful in real-life? 
> 
> 
> I think so. In general, syn states have a very short lifetime. Thus,
> they are quickly superseded by established, making the replication
> effort barely useful. Moreover, I assume that clients usually reissue
> connections that fail in (early) syn states. I'm assuming that we are
> focusing on the recovery of connection established.
> 
> 
>>How are connections destroyed?
> 
> 
> Once we received the time_wait, we tell other replicas to destroy the
> connection. We miss previous teardown states that have also short
> lifetime. This is a tradeoff, we reduce the "copy-equivalence" degree
> among replicas but reduce the number of messages generated in return.


Connections don't go through TIME_WAIT in case they are reset.

>>Again, what I would like to understand before we add something
>>we have to live with forever is what it will look like in the
>>end and what the gain of it is, so I would like to see a realistic
>>example. Since the vast majority of updates is in TCP ESTABLISHED
>>state and basically everyone is going to synchronize that I have
>>a hard time believing that this is really going to give a notable
>>performance improvement.
> 
> 
> Well, since there is usually just one messages per state change in the
> case of TCP connections, we would just generate two, one to notify the
> established state and one to destroy it. Thus, in the particular case of
> a HTTP connection, we would need just two messages instead of seven.
> 
> 
>>I also only see new groups related to protocol states, what
>>about helpers, timeouts, ...?
> 
> 
> Same thing as above, the protocol events groups are just a way to group
> events. Thus, if the conntrack mark changes while in established state,
> an event message to the established group is delivered.


Mhh OK. I'll think about it some more over the weekend.

Something not directly related: we're generating events (internally)
for every packet and call the notifiers, yet we don't use them for
anything (for example IPCT_PROTOINFO_VOLATILE and IPCT_REFRESH),
which seems like a complete waste. I think we should remove them.