netdev - Re: empty ack packets

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

Date:	Fri, 10 Sep 2010 06:57:18 -0400
From:	MK <stardust496@...il.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: empty ack packets

Hagen,

My flow is most certainly in both directions. ( I am guessing that
means pingpong will be true and so no quickack by default unless I
explicitly enable it which I am not.)

Thanks....

On Friday, September 10, 2010, Hagen Paul Pfeifer <hagen@...u.net> wrote:
>
> On Fri, 10 Sep 2010 01:12:44 -0400, MK wrote:
>> Hello list,
>>
>> I am looking at a tcpdump and I see that very very frequently, after
>> receiving a segment, my tcp is sending an empty ack back in a matter
>> of several (around 20 - 50) microseconds. And then after several more
>> microseconds, my tcp is sending some valid outgoing data. I am trying
>> to understand why it decided to send an empty ack back when that ack
>> could potentially have been delayed by microseconds and get
>> piggybacked on the outgoing data.
>>
>> From the code, it appears that the delayed ack timeout is 40 millisecs
>> so it is likely not the delack timer that is causing this. (And I do
>> not have the quickack option)
>>
>> This is RHEL5 (2.6.18) kernel.
>>
>> Does anybody have an idea as to what is happening?
>
> The mechanism behind is called TCP Quick ACK and was introduced to raise
> the Congestion Window more quickly for non-interactive streams. If the
> stack detects that the stream is interactive (can piggy-back data) the
> quick ACK is disabled. But the heuristic demand at least one packet to
> detect that the flow is interactive. Currently the mechanism favor
> non-interactive flows and generate at least on "unnecessary" ACK packet.
> The alternative approach is to always delay the first ACK and after that
> decide if a stream is interactive or not. But this will penalize bulk data
> transfer, because the CW is raised slower and additionally, the first
> return packet may not be triggered instantly.
>
> See the following discussion and patch where the mechanism is made
> modifiable (I will drop a new patch but this take some time (vacation)):
>
> http://kerneltrap.org/mailarchive/linux-netdev/2010/8/23/6283640
>
> Hagen
>
--
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