netdev - How to accelerate tcp retransmition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jan 2012 16:58:31 +0800
From:	leno soff <lnxuff@...il.com>
To:	netdev@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, eric.dumazet@...il.com,
	davem@...emloft.net
Subject: How to accelerate tcp retransmition

Hello everyone,
   I have a lot of client, say C1, C2, .. Cn, which route packets to
my servers through router R. But R will drop 70% - 90% _ non-SYN _
packets from clients to Server.

  The clients and server work like http client and server, sending a
request, wating for the response.

  When router R drop the request-like packets(without SYN flag, of
cause), the clients retransmit with icsk_backoff++;  They usually
should wait 15 seconds+ (1+2+4+8), and sometimes more or just timeout.

   So, my question is:

        Is there any way in _server_ side, to accelerate the
retransmition like accelerating slow-start. I tried SO_KEEPALIVE in
server, interval == 1 second or less,  I assume the keepalive ack will
 accelerate the retransmition, ,  but it does not work:

       Flags [P.], seq 1:314, ack 1.  ----------------client request,
which is lost
       Flags [.], ack 1, win 905, length 0  --- server keepalive ack
       Flags [.], ack 1, win 115, length 0  --- client responds ack
       .... A lot keepalive and response.

    The client timeout because of RTO, why doesn't retransmit the
request packet but just an ack without data when it sees keepalive ack
?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html