excessive TCP duplicate acks?

[Andre Oppermann]

Andrew Gallatin wrote:
> Andre Oppermann writes:
>  > This thing is really strange and difficult to debug.  A look at the CVS history
>  > of tcp_input/output doesn't show any smoking gun.  ACKs like these are totally
>  > pointless.  There are three places able to cause ACKs: 1) tcp_input decides to
>  > call tcp_output [not the case here as there are no corresponding input packets
>  > to cause this]; 2) tcp_output has a unterminated loop somewhere causing it to
>  > spew the ACKs in rapid succession [unlikely as it holds the tcpcb lock and that
>  > would block inbound packets]; 3) tcp timers are misfiring or not properly dis-
>  > armed [here the logic in tcp_output may/should just ignore it and return w/o
>  > sending any packet].
> 
> When I was taking traces a few weeks ago,  I remember having the
> impression that the acks would start happening when the FreeBSD
> sender didn't have enough space in the window to send any more
> data, and would seemingly continue until the (Linux|Macosx)
> receiver sent an ack which updated the window and allowed
> the FreeBSD sender to send more data.  

Ok, that's an ambulance worth chasing.  Lets see if it leads us to an
accident.

> Are you using a FreeBSD receiver?  Both Linux and MacOSX ack far, far
> less often than we do.  Maybe a FreeBSD receiver acks too quickly
> for you to see the bug?

I'll try reproduce the bug against OSX.

-- 
Andre