[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)

Henrik Nordstrom hno at marasystems.com
Wed Sep 29 17:02:55 CEST 2004

On Wed, 29 Sep 2004, jamal wrote:

> Where this becomes an issue is if your responses come back faster than
> you can synchronize state. If you are going across big bad internet
> where latencies start in the ms range, then the issue becomes less
> challenging.

Problem is you don't really know.

If it was the case that when you received the reply packet you could know 
the state of this has not yet been syncronized then no problem, but before 
the state has been syncronized you don't know it is reply traffic.

> I think what you describe above needs to be done in the case of response
> latency being lower than update latency. i.e its not a bad option. It
> will slow down the setup time but thats only for the firts new packet.

Only if you accept sloppy connection tracking without TCP windows etc. 
With netfilter conntrack moving to full tracking it is no longer the case 
and you will need relatively frequent syncronizations during the session, 
not only the first packet.

> The impact on susbequent packets in the flow should be low.



More information about the netfilter-devel mailing list