From: MK <stardust496@gmail.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: empty ack packets
Date: Fri, 10 Sep 2010 06:57:18 -0400 [thread overview]
Message-ID: <AANLkTinJCXaWPGmd0HXDaN8fT=nY8jeoY7Hb0Aw-TAod@mail.gmail.com> (raw)
In-Reply-To: <4bb006381ebf718d3c7bcb002d1ea924@localhost>
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@jauu.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
>
prev parent reply other threads:[~2010-09-10 10:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 5:12 empty ack packets MK
2010-09-10 5:29 ` Mitchell Erblich
2010-09-10 7:06 ` Hagen Paul Pfeifer
2010-09-10 10:57 ` MK [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTinJCXaWPGmd0HXDaN8fT=nY8jeoY7Hb0Aw-TAod@mail.gmail.com' \
--to=stardust496@gmail.com \
--cc=hagen@jauu.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).