From owner-freebsd-net@FreeBSD.ORG Tue Mar 9 20:28:07 2004 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 737E516A4CE; Tue, 9 Mar 2004 20:28:07 -0800 (PST) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 376FE43D45; Tue, 9 Mar 2004 20:28:07 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 415E077A6D5; Tue, 9 Mar 2004 23:28:04 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E136C10F8AF; Tue, 9 Mar 2004 23:28:04 -0500 (EST) To: Mike Silbersack To: Kevin Oberman To: Brad Knowles From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wild Horses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Mar 2004 23:28:04 -0500 Sender: mallman@icir.org Message-Id: <20040310042804.E136C10F8AF@lawyers.icir.org> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Who wants SACK? (Re: was My planned work on networking stack) 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: Wed, 10 Mar 2004 04:28:07 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Brad Knowles: > Out of curiosity, can someone provide some pointers as to where SACK > really helps? Is this just for high-speed WANs and doesn't help on > LANs, or is it useful in both contexts? Also, at what speeds/packet > sizes does SACK start to become really useful? >=20 > I'm just wondering if there aren't a lot of people who could benefit > from something like this, only they don't know it.=20=20 I think that it is generally a nice addition to TCP. The space where SACK helps quite a lot is when a connection loses more than one packet From=20a window of data (i.e., more than one loss per RTT). Since losses tend to be bursty this happens more often than one might think by just looking at the loss rate. Without SACK, TCP can usually handle one loss per RTT with no problem (using fast retransmit). More losses, however, will cause retransmission via the RTO timer -- which is slow. Kevin Oberman: > If you don't have SACK, you need to re-transmit all of the packets in > flight within the window while with SACK, you need only retransmit the > dropped packet(s).=20 This is not actually quite right on a couple of fronts. First, as mentioned above if you have only a single loss from a window of data then fast retransmit will take care of it without any problem. Second, TCP is not quite a go-back-n protocol even after the RTO. TCP definately resends a lot more data than it has to without SACK. But, it doesn't retransmit the entire window either. Mike Silbersack: > SACK itself really doesn't do much, it's all the new congestion > control schemes (FACK, Rate Halving, etc) that come shipped with most > SACK implementations that do the work and contain most of the > complexity. Right. (And, I'll plug RFC3517 as a very heavily vetted method for using SACK information. I am probably biased. But, I think it is very nice. I have grown to like it more and more since it was published. Its robustness keep surprising me!) allman =2D- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFATplUWyrrWs4yIs4RAux+AJ9hkhtz9pbfK7OHw/j8eq9LQInubQCeIJ4d XTnTNOmmZqGgKOPefI6y5cw= =exgs -----END PGP SIGNATURE----- --=-=-=--