Who wants SACK? (Re: was My planned work on networking stack)
brooks at one-eyed-alien.net
Wed Mar 10 07:41:55 PST 2004
On Wed, Mar 10, 2004 at 12:37:11PM +0100, Harti Brandt wrote:
> On Tue, 9 Mar 2004, Mike Silbersack wrote:
> MS>On Tue, 9 Mar 2004, Kevin Oberman wrote:
> MS>> Selective ACKnowledgment (SACK) allows acknowledgment of received
> MS>> packets in a TCP window so that only the missing/damaged packet needs to
> MS>> be re-transmitted. This is normally of little value on a LAN where ACKs
> 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 have a
> MS>> 10 or 20 MB window, this is a big deal.
> 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 other
> MS>holes which must be filled or if new data can be transmitted.
> 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.
> 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
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040310/3433c15c/attachment.bin
More information about the freebsd-net