Date: Tue, 8 Mar 2005 18:39:07 +0100 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Mark Tinguely <tinguely@casselton.net> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.x and OS-X tcp performance Message-ID: <20050308173907.GG26999@insomnia.benzedrine.cx> In-Reply-To: <200503081411.j28EB0Hv001184@casselton.net> References: <20050308101633.GC26999@insomnia.benzedrine.cx> <200503081411.j28EB0Hv001184@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote: > The server is not telling the client that a packet has been lost. > The first two ACKs are correct duplicate ACKs, but the remaining > ACKs coming from he server have window adjustments, so the > client does not treat them as duplicate ACKs coming from a packet > loss. Ah, I didn't realize that duplicates must have the same window sizes, that explains it. Now I wonder why the server should be using the same window size on those near duplicate ACKs. It looks like th_win is recalculated every time in tcp_output(), based on how full the receive buffer is (the win = sbspace(&so->so_rcv); statement). Assuming there is usually some window space left when a loss occurs, and the sender will continue to fill the window with some more segments until the dupacks should trigger a fast retransmit, why should the receiver not adjust its window size in every ack? This seems not to occur in most cases, otherwise fast retransmit would rarely work. In this particular case, the server is increasing the window size with subsequent ACKs. What does this mean? The receive buffer became less full so quickly? The receive buffer was enlarged? Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050308173907.GG26999>