On Sat, Mar 05, 2016 at 03:03:21PM +0200, Julian Anastasov wrote: > Jiri Bohac is reporting for a problem with the connection > rescheduling mechanism added in 3.10 when new SYNs in > connection to dead real server can be redirected to another > real server. His solution is to drop SYNs until the IPVS > connection and its conntrack are properly removed, so that > a new connection can be established later from client's > retransmissions. Alternative would be to redirect the > conntrack (its reply direction) to the new real server but > we do not see such solution. > > The second patch addresses another scenario: client restarts > TCP connection by reusing the same IPVS connection: > > - IPVS conn is established, eg. FTP without persistence > - restart client box > - start new TCP connection from same port to reuse IPVS conn > C: SYN with new SEQ > S: ACK with ACK_SEQ=old SEQ > C: RST SEQ=old SEQ, IPVS conn:EST->CLOSE > retransmit pause > C: SYN, still in CLOSE? => DROP, expire IPVS conn > Expire IPVS connection > retransmit pause > C: SYN, create connection > > In this case we should allow rescheduling in CLOSE state. > In the worst case for this scenario with initial RTO=3 secs > the client can be delayed for 9 seconds. Thanks, I have queued these up dropping the previous versions -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
