From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 19:21:58 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 F3EA916A4CE for ; Tue, 8 Feb 2005 19:21:57 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA91643D45 for ; Tue, 8 Feb 2005 19:21:57 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j18JLnuM092345; Tue, 8 Feb 2005 11:21:50 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1DD4177A6A5; Tue, 8 Feb 2005 14:21:46 -0500 (EST) To: "Daikichi Osuga" From: Mark Allman In-Reply-To: <003901c50da5$8a9f7c80$5beb15ac@mig.yrp.nttdocomo.co.jp> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Rocket Man MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 08 Feb 2005 14:21:46 -0500 Sender: mallman@icir.org Message-Id: <20050208192146.1DD4177A6A5@guns.icir.org> cc: Ethan Blanton cc: freebsd-net@freebsd.org Subject: Re: SACK retransmits multiple segments respond to single dupack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 19:21:58 -0000 --=-=-= Content-Type: text/plain > I had experiments with FreeBSD SACK implementation. FreeBSD SACK > retransmits multiple segments respond to single dupack. It breaks > "packet conservation principle". > > In OpenBSD SACK implementation, > retransmission from SACK hole is limited to single segment. > "sack_rxmit" and "sendalot" are exclusive. > > I think solution is introducing mechanism to estimate amount of > outstanding segments. For example, "pipe" alogorithm is well known. > http://www.icir.org/floyd/talks/sf-sacks-96.pdf Note that in RFC3517 we explicitly allow sending multiple retransmits on a "dupack". Basically, SACK allows for robustness in the face of ACK loss and so as long as the total amount of data sent is in line with the congestion control algorithms this is fine. The downside is that there is the potential for increased burstiness. We don't think this is a terribly big deal. We have recent results that say that small scale bursting doesn't hurt the connection all that much. See: Ethan Blanton, Mark Allman. On the Impact of Bursting on TCP Performance. Proceedings of the Workshop for Passive and Active Measurement, March 2005. To appear. http://www.icir.org/mallman/papers/burst-pam05.ps allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCCRFKWyrrWs4yIs4RAsVUAJ9LfSzOHJlKpgtij0SnqFFXpG6nawCeNm0X ag09NZHDSG0DpLKlZDUiw5Q= =DkRs -----END PGP SIGNATURE----- --=-=-=--