Date: Fri, 27 Apr 2007 16:33:00 -0400 From: Preethi Natarajan <nataraja@cis.udel.edu> To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@freebsd.org, "Paul D. Amer" <amer@cis.udel.edu> Subject: Re: TCP Delayed Ack implementation in 6.1 Message-ID: <46325DFC.7020006@cis.udel.edu> In-Reply-To: <Pine.BSF.4.58.0704271622120.77388@niwun.pair.com> References: <463214E4.9090401@cis.udel.edu> <Pine.BSF.4.58.0704271622120.77388@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46325DFC.7020006>