LINK="#3366FF" VLINK="#A000A0">

"The Linux Gazette...making Linux just a little more fun!"


(?) The Answer Guy (!)


By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/


(!) A Reader Answers: What is the TCP/IP SACK feature?

From Tom Kludy on Thu, 04 Feb 1999

(?) What is the TCP/IP SACK feature? What does it do?

(!) SACK = Selective ACKnowledgement. It is an extension to TCP/IP which allows you to acknowledge reception of specific packets. (read on)

(?) Why do we need/want it?

(!) When sending a group of packets across a network, you need the receiver to acknowledge those packets that are received. TCP without SACK simply acknowledges the last packet that was received. (Actually, the ACK has the number of the next packet requested, but that's neither here nor there). However, with TCP there are usually several packets in transit between the source and destination at any one time. That means that the source will not recognize that the destination has dropped a packet until it sees the same ACK several times (4, I think) or until a timeout has passed. It then resends the packet that has been dropped.
Let's say that there is are 10 packets in route between the source and destination. Along the line, packets 1,2,3, and 4 are received, and ACKed. Packet 5 is dropped, but all other packets are delivered successfully (6,7,8,etc). The receiver will ACK 5 upon receiving 4, 6, 7, 8, etc. But since there are 10 packets in transit between source and destination, the receiver won't see the repeating ACKs until it has sent all packets up to about packet 25 (since, at the same time the receiver should be receiving packet 5, the sender is sending packet 15 (5+10), plus the 10 packet delay until the sender gets the ACK).
At this point, the sender finally knows that packet 5 has been dropped, and resends it. But it doesn't know that the receiver has successfully received packets 6 through 25. So, it must wait until the receiver gets the new packet 5, and returns "ACK 26", before it knows where to restart. It will take 20 packet-transmission times to get this ACK (or, one whole round-trip-time). As you can guess, this slows things down considerably. SACK allows the receiver to say "I've missed packet 5, but I've received packets 6-25". This allows a much quicker transmission restart, since the source knows within a 1/2 round-trip-time where to resume transmission (instead of a whole round-trip-time).

(?) It the Linux implementation any better or worse than others? (Or is it some feature where you pretty much either have it or you don't and there is no "better" or "worse")?

(!) I think it falls under "there is no better or worse", except that if the underlying TCP implementation is more efficient, then SACK might help even more..
Hope I have answered the answer guy :) Please note that this is all from memory, as I haven't dealt with this in quite a while.
-Tom Kludy
(!) Yes. Your answer was perfect. I'm forwarding it to my editors as is.


Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 38 March 1999


[ Answer Guy Index ] 1 2 3 4 5 6 7 8 9 10 11
12   14   16 17 18 19   21 22
23 24   26   28 29 30 31 32  


[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]