TCP Delayed Ack implementation in 6.1

[Preethi Natarajan]

Hello,

The reason for the second ack appears to be a new window update at the 
client side. The push flag was not set.

Thanks,
Preethi

On 4/27/2007 4:25 PM, Mike Silbersack wrote:
> On Fri, 27 Apr 2007, Preethi Natarajan wrote:
>
>   
>>  From tcpdump at client side:
>> Time: 38s.695ms: S->C data (282b)
>> Time: 38s.707ms: S->C data (1448b)
>> Time: 38s.707ms: C->S ack
>> Time: 38s.719ms: S->C data (1448b)
>> Time: 38s.719ms: C->S ack
>> Time: 38s.731ms: S->C data (1448b)
>> Time: 38s.741ms: S->C data (1166b)
>> Time: 38s.741ms: C->S ack
>>
>> I do not understand the reason for the second ack from C->S (Time
>> 38s.719ms). Clearly this ack has not delayed for 200ms from the previous
>> ack and acks only 1 packet. Am I missing something?
>>
>> Thanks a ton,
>> Preethi
>>     
>
> My crystal ball tells me that packet four has the PUSH flag set on it,
> which means that it will be immediately ACKed and sent to the application.
>
> Please post tcpdump output in the future, the batteries on my crystal ball
> are running low.
>
> Mike "Silby" Silbersack
>