Date: Tue, 9 Mar 2004 16:12:07 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: 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: <20040309160821.P705@odysseus.silby.com> In-Reply-To: <20040309214205.3EE2D5D07@ptavv.es.net> References: <20040309214205.3EE2D5D07@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Mar 2004, Kevin Oberman wrote: > Selective ACKnowledgment (SACK) allows acknowledgment of received > packets in a TCP window so that only the missing/damaged packet needs to > be re-transmitted. This is normally of little value on a LAN where ACKs > arrive quickly and windows are smaller and no use on slow circuits. On > fat pipes with latency and big windows it is a huge win as it allows you to > recover much faster from a packet drop. 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). If you have a > 10 or 20 MB window, this is a big deal. That's not correct. Non-SACK TCP doesn't drop any additional packets vs SACK. The difference is that SACK allows the transmitter to transmit the packet which fills the "hole" and then immediately start transmitting new data (or fill other holes.) Non-SACK senders have to wait to receive an ACK after retransmitting the hole in order to find out if there are other holes which must be filled or if new data can be transmitted. 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. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040309160821.P705>