netdev - RE: TCP delayed ACK heuristic

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2012 09:57:27 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Cong Wang" <amwang@...hat.com>,
	"David Miller" <davem@...emloft.net>
Cc:	<rick.jones2@...com>, <netdev@...r.kernel.org>,
	<greearb@...delatech.com>, <eric.dumazet@...il.com>,
	<shemminger@...tta.com>, <tgraf@...hat.com>
Subject: RE: TCP delayed ACK heuristic

> So, can we at least have a sysctl to control the timeout of the delayed
> ACK? I mean the minimum 40ms. TCP_QUICKACK can help too, but it requires
> the receiver to modify the application and has to be set every time when
> calling recv().

A sysctl in inappropriate - it affects the entire TCP protocol stack.

You want different behaviour for different remote hosts (probably
different subnets).
In particular your local subnet is unlikely to have packet loss
and very likely to have a very low RTT.

AFAICT a lot of the recent 'tuning' has been done for web/ftp
servers that are very remote from the client. These connections
are also request-response ones - quite often with large responses.

IMHO This has been to the detriment of local connections.

	David