Skip site navigation (1)Skip section navigation (2)
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>