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]

Date:	Thu, 27 Oct 2011 14:54:32 +0300
From:	Daniel Baluta <dbaluta@...acom.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Andy Lutomirski <luto@...capital.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] Add TCP_NO_DELAYED_ACK socket option

On Thu, Oct 27, 2011 at 1:24 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> 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"

Hello Eric,

Few days ago, in our custom kernel we made TCP Delack segments and
TCP Delack timeout parameters tunable via proc entries.
Increasing tcp_delack_segs (number of full sized segments that must
be received until an ACK is sent) we observed an improvement of
throughput up to 20% in some test cases.

Do you think that this kind of patch would have a chance to be
included in mainstream?

thanks,
Daniel.
--
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