Re: Problem with tcp (2.6.31) as first, http://bugzilla.kernel.org/show_bug.cgi?id=14580

Ilpo Järvinen a écrit :

What would you expect to happen? If out-of-window stuff arrives we send 
dupacks. If we would send resets, that would introduce blind rst attacks.
In theory we might be able to quench the loop by using pingpong thing but 
that needs very careful thought in order to not introduce other problems,
and even then your connections will not be re-usable until either end 
times out so the gain is rather limited. We simply cannot rst the 
connection, that's not an option.

I find this problem simply stem from the introduced loss of end-to-end 
connectivity. Would you really "lose" that server so that its TCP state is 
not maintained, you'd get resets etc (crash, scheduled reboot or 
whatever). Only real solution would be a kill switch for TCP connection 
when you break e-2-e connectivity (ie., switch servers so that the same IP 
is reacquired by somebody else). In theory you can "simulate" the kill 
switch by setting tcp_retries sysctls to small values to make the 
connections to timeout much faster, but still that might not be enough for 
you (and has other implications you might not like). 

RST is not an option, sure, but ACK storms are unlikely good things too.


Could'nt we do something smart in presence of tcp timestamps ?

11:23:27.669910 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.669991 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670000 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670093 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670099 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670175 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670183 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670268 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670276 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670359 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670368 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>


Or we could 

Count number N of strange/bad acks we received from peer.

- At first one, send our ACK immediately

- For following, delay our ACK answer by N*100 ms, to reduce the flood.
(or if we have data in flight, only rely on retransmit timer and not sending acks)