Re: Who wants SACK? (Re: was My planned work on networking stack)

On Tue, 9 Mar 2004, Mike Silbersack wrote:

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 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>
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>
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
application.

harti