netdev - Re: [PATCH] Add TCP_NO_DELAYED

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]

Message-ID: <1319711072.2601.18.camel@edumazet-laptop>
Date:	Thu, 27 Oct 2011 12:24:32 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] Add TCP_NO_DELAYED_ACK socket option

Le mardi 25 octobre 2011 à 19:25 -0700, Andy Lutomirski a écrit :
> When talking to an unfixable interactive peer that fails to set
> TCP_NODELAY, disabling delayed ACKs can help mitigate the problem.
> This is an evil thing to do, but if the entire network is private,
> it's not that evil.
> 
> This works around a problem with the remote *application*, so make
> it a socket option instead of a sysctl or a per-route option.
> 
> Signed-off-by: Andy Lutomirski <luto@...capital.net>
> ---
> 
> This patch is a bit embarrassing.  We talk to remote applications over
> TCP that are very much interactive but don't set TCP_NODELAY.  These
> applications apparently cannot be fixed.  As a partial workaround, if we
> ACK every incoming segment, then as long as they don't transmit two
> segments per rtt, we do pretty well.
> 
> Windows can do something similar, but it's per interface instead of per
> socket:
> 
> http://support.microsoft.com/kb/328890

Hi Andy

Yet another delayed ack hacking proposal :)

Well, to be honest, I find the MS Windows tunable more generic.
[ But doing it for a whole interface is wrong, it should be per socket
to allow best tuning ]

Setting the value to 4 (instead of default 2) for example would _reduce_
number of ACK packets in bulk transferts [ We can do that if GRO is on,
as a side effect ]

Also the 40ms/200ms values (TCP_DELACK_{MIN|MAX}) could be tunables.
(system or per socket)
RFC 1122 says it SHOULD be less than 500ms. The time criteria is IMHO
far more palatable for an application author than "number of delayed
acks"



--
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