TCP Delayed Ack implementation in 6.1

Hello,

I have a question about the TCP delayed ack implementation
in FreeBSD 6.1

According to specs, if delayed acks are enabled, the
receiver delays 
transmitting acks for the delack time period or acks every
other 
incoming packet.

I have an experimental setup where:
- RTT between server & client ~90ms.
- one-way data transmission from server to client.
- tcp delayed acks enabled
- delacktimer = 200ms.
- tcp inflight (BDP) calculation is disabled.

 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

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

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
>   
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"