Date: Thu, 11 Mar 2004 20:29:07 -0800 From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com> To: "Mike Silbersack" <silby@silby.com>, "Kevin Oberman" <oberman@es.net> Cc: freebsd-net@freebsd.org Subject: RE: Who wants SACK? (Re: was My planned work on networking stack) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040604EF@xch-nw-27.nw.nos.boeing.com>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Mike Silbersack [mailto:silby@silby.com] > Sent: Tuesday, March 09, 2004 2:12 PM > To: Kevin Oberman > Cc: Brad Knowles; freebsd-current@freebsd.org; freebsd-net@freebsd.org > Subject: Re: Who wants SACK? (Re: was My planned work on networking > stack)=20 >=20 >=20 > SACK itself really doesn't do much, it's all the new=20 > congestion control > schemes (FACK, Rate Halving, etc) that come shipped with most SACK > implementations that do the work and contain most of the complexity. >=20 That's not quite true. Basic SACK by itself can be very helpful,=20 especially if NewReno is the non-SACK fallback, in long delay = environments=20 characterized by bursty losses (multiple packets in one window). =20 With NewReno, you end up only recovering one packet per RTT, which=20 can in some cases be much worse than just taking a timeout and=20 starting over. See below paper for some experimental traces=20 of this: http://citeseer.ist.psu.edu/henderson99transport.html (not that I don't think that the more recent RFCs are an improvement on basic SACK) As for who/when to do this, I and perhaps others have been discouraged=20 from taking a stab at a SACK patch in the past, because of a sentiment that it should be undertaken as part of a bigger rewrite of TCP. =20 Tom p.s. Niels Provos ported our Berkeley BSDi-based SACK extension to OpenBSD several years ago-- that might be something to look at as a starting point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6938661A6EDA8A4EA8D1419BCE46F24C040604EF>