Skip site navigation (1)Skip section navigation (2)
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>