From owner-freebsd-net@FreeBSD.ORG  Sun Mar 20 12:24:20 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2194716A4CE
	for <freebsd-net@freebsd.org>; Sun, 20 Mar 2005 12:24:20 +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 7839F43D1F
	for <freebsd-net@freebsd.org>; Sun, 20 Mar 2005 12:24:19 +0000 (GMT)
	(envelope-from demizu@dd.iij4u.or.jp)
Received: from localhost (124.117.138.210.xn.2iij.net [210.138.117.124])
	by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j2KCOIg15826;
	Sun, 20 Mar 2005 21:24:18 +0900 (JST)
Date: Sun, 20 Mar 2005 21:24:59 +0900 (JST)
Message-Id: <20050320.212459.21971983.Noritoshi@Demizu.ORG>
From: Noritoshi Demizu <demizu@dd.iij4u.or.jp>
To: freebsd-net@freebsd.org
In-Reply-To: <20050316.215730.84382579.Noritoshi@Demizu.ORG>
References: <20050316.215730.84382579.Noritoshi@Demizu.ORG>
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: TCP SACK of FreeBSD stable
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Mar 2005 12:24:20 -0000

Upon a request, I made two experiments to compare the TCP SACK behaviors
when Limited Transmit is on and off.

I put the new results at http://www.demizu.org/~noritosi/memo/2005/0320/

  1. In the first RTT of the recovery mode, FreeBSD stable sends one
     data segment for each duplicate ACK segment.  As a result, the
     outstanding window size may not be halved while a loss is detected.

  2. FreeBSD stable retransmits data upon the arrival of the first
     SACK block higher than the data.  As a result, FreeBSD stable
     would retransmit data segments unnecessarily when data segments
     are reordered.

  3. FreeBSD stable seems not to retransmit data higher than
     snd_recover even if the data can be infered as lost.

Any comments are welcome.

Thank you.

Regards,
Noritoshi Demizu