empty ack packets

empty ack packets

[MK]

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?

Thanks a lot!!

Re: empty ack packets

[Mitchell Erblich]

MK,


	The 1st packet is probably generating window update information.

	If the TCP flow is in slow start, it should not be doing any delacks
	to keep as many normal acks in the flow.

	Mitchell Erblich

	
On Sep 9, 2010, at 10:12 PM, 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?
> 
> Thanks a lot!!
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: empty ack packets

[Hagen Paul Pfeifer]

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

Re: empty ack packets

[MK]

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
>