From owner-freebsd-net@FreeBSD.ORG Fri Mar 11 11:19:43 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E566016A4CE for ; Fri, 11 Mar 2005 11:19:42 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4195B43D53 for ; Fri, 11 Mar 2005 11:19:40 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h076.p049.iij4u.or.jp [210.130.49.76]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j2BBJZ917920; Fri, 11 Mar 2005 20:19:36 +0900 (JST) Date: Fri, 11 Mar 2005 20:20:02 +0900 (JST) Message-Id: <20050311.202002.26516944.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org In-Reply-To: <200503081411.j28EB0Hv001184@casselton.net> References: <20050308101633.GC26999@insomnia.benzedrine.cx> <200503081411.j28EB0Hv001184@casselton.net> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 4.x and OS-X tcp performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 11:19:43 -0000 > 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. I made a list of ACKs with ack=4195629532. I added differences with their previous window sizes in parenthesises for each line. (See below) I guess if the difference < 2 * 1448, it would be an ACK sent in reply to an out-of-order data segment (i.e., it really is a dup ACK). Otherwise, it would be a pure window update. I added my guess for each line below. There are 12 dup ACKs, which is equal to the number of data segment beyond the lost packet. And there are 12 window updates. ack 4195629532 win 5792 (-) <- Original ACK ack 4195629532 win 6576 (+784) <- dup ACK (with window update) ack 4195629532 win 6576 (0) <- dup ACK ack 4195629532 win 7240 (+664) <- dup ACK (with window update) ack 4195629532 win 10672 (+3432) <- window update ack 4195629532 win 12720 (+2048) <- dup ACK (with window update) ack 4195629532 win 14768 (+2048) <- dup ACK (with window update) ack 4195629532 win 14768 (0) <- dup ACK ack 4195629532 win 16816 (+2048) <- dup ACK (with window update) ack 4195629532 win 18864 (+2048) <- dup ACK (with window update) ack 4195629532 win 18864 (0) <- dup ACK ack 4195629532 win 20912 (+2048) <- dup ACK (with window update) ack 4195629532 win 22960 (+2048) <- dup ACK (with window update) ack 4195629532 win 22960 (0) <- dup ACK ack 4195629532 win 26032 (+3072) <- window update ack 4195629532 win 29104 (+3072) <- window update ack 4195629532 win 32176 (+3072) <- window update ack 4195629532 win 35248 (+3072) <- window update ack 4195629532 win 38320 (+3072) <- window update ack 4195629532 win 41392 (+3072) <- window update ack 4195629532 win 44464 (+3072) <- window update ack 4195629532 win 47536 (+3072) <- window update ack 4195629532 win 50608 (+3072) <- window update ack 4195629532 win 53680 (+3072) <- window update ack 4195629532 win 56752 (+3072) <- window update There are four dup ACKs whose window field is the same as its previous ACK. If the sender counted them as dup ACKs, the sender was able to do FastRetransmit. But the sender did not. The reason would be that the sender might clear t_dupacks when receiving a window update. In FreeBSD current, line 1909 of tcp_input.c rev 1.268 does this. I am not sure it is a correct procedure. By the way, the receiver application seems to call read() with bufsize=1024. If the bufsize was larger than or equal to 2 * 1448, e.g., 4096, window updates would be sent independently from dup ACKs. Since the number of dup ACKs would be increased, the chance the receiver sends consecutive three dup ACKs might be increaced. Or if the receiver machine was replaced with a faster machine, the receiver application ran faster and the receive buffer would be always almost empty. In this case, the number of window updates would be decreased and the chance the receiver sends consecutive three dup ACKs would be increaced. These may improve the TCP performance in this particular case. Regards, Noritoshi Demizu ps. In tcpdump.osx-fbsd, I saw six retransmission timeouts. Retransmission timeout values are from 1 second to 1.5 seconds. They occupies almost all the total time of the transfer (8.6 seconds). Outstanding window seems less than 10 MSS, and in most cases, it is less than 6 MSS due to advertized window size. So, if Fast Retransmit worked, the TCP performance would be drastically improved in this particular case.