Re: TCP Delayed Ack implementation in 6.1

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

Relevant Pages