Re: [PATCH] Add TCP_NO_DELAYED_ACK socket option

[Eric Dumazet <eric.dumazet@gmail.com>]

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@amacapital.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"