From: Hagen Paul Pfeifer <hagen@jauu.net>
To: MK <stardust496@gmail.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: empty ack packets
Date: Fri, 10 Sep 2010 09:06:24 +0200 [thread overview]
Message-ID: <4bb006381ebf718d3c7bcb002d1ea924@localhost> (raw)
In-Reply-To: <AANLkTimkvDsqY==1JQRhH54+P7yAzFX4omYN0r9+_mi=@mail.gmail.com>
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
next prev parent reply other threads:[~2010-09-10 6:56 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 [this message]
2010-09-10 10:57 ` MK
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=4bb006381ebf718d3c7bcb002d1ea924@localhost \
--to=hagen@jauu.net \
--cc=netdev@vger.kernel.org \
--cc=stardust496@gmail.com \
/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).