Date: Wed, 10 Mar 2004 07:41:41 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: freebsd-net@freebsd.org Subject: Re: Who wants SACK? (Re: was My planned work on networking stack) Message-ID: <20040310154139.GA14892@Odin.AC.HMC.Edu> In-Reply-To: <20040310123237.V61186@beagle.fokus.fraunhofer.de> References: <20040309214205.3EE2D5D07@ptavv.es.net> <20040309160821.P705@odysseus.silby.com> <20040310123237.V61186@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2004 at 12:37:11PM +0100, Harti Brandt wrote: > On Tue, 9 Mar 2004, Mike Silbersack wrote: >=20 > MS> > MS>On Tue, 9 Mar 2004, Kevin Oberman wrote: > MS> > MS>> Selective ACKnowledgment (SACK) allows acknowledgment of received > MS>> packets in a TCP window so that only the missing/damaged packet need= s to > MS>> be re-transmitted. This is normally of little value on a LAN where A= CKs > MS>> arrive quickly and windows are smaller and no use on slow circuits. = On > MS>> fat pipes with latency and big windows it is a huge win as it allows= you to > MS>> recover much faster from a packet drop. If you don't have SACK, you = need > MS>> to re-transmit all of the packets in flight within the window while > MS>> with SACK, you need only retransmit the dropped packet(s). If you ha= ve a > MS>> 10 or 20 MB window, this is a big deal. > MS> > MS>That's not correct. Non-SACK TCP doesn't drop any additional packets = vs > MS>SACK. The difference is that SACK allows the transmitter to transmit = the > MS>packet which fills the "hole" and then immediately start transmitting = new > MS>data (or fill other holes.) Non-SACK senders have to wait to receive = an > MS>ACK after retransmitting the hole in order to find out if there are ot= her > MS>holes which must be filled or if new data can be transmitted. > MS> > MS>SACK itself really doesn't do much, it's all the new congestion control > MS>schemes (FACK, Rate Halving, etc) that come shipped with most SACK > MS>implementations that do the work and contain most of the complexity. >=20 > For satellite pipes with drops that are not the result of congestion, but > of transmission errors SACK helps. With congestion control only you get no > throughput no matter what you do (I did some tests with a simulated > 50MBit/sec GEO link with errors). But this is a rather limited > application. For that matter, there are sufficent drops on 10GbE from data errors to insure that two boxes connected back to back won't achieve line speed on a single TCP session. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFATzcxXY6L6fI4GtQRAqTDAKDlCGkr03SBdrHmE6clLj4KjiLuIQCdFTg7 hsqoox+1LkIhef/yYr4dFvc= =t/mZ -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040310154139.GA14892>