Differences between Congestion control and Sack

[sawquecisco]

Hi

Wikipedia says that there are 4 Congestion Control Algorithms:

Slow-start; Congestion avoidance; Fast retransmit; Fast recovery

But some documents show "SACK TCP" as an another algorithm. Is that right?

I am having a confusing about classification of TCP Congestion Algorithms.Can you please clarify this?

Thanks...

[Peter Paluch]

Hi,

The TCP Selective ACK is not intended to be used as a congestion algorithm. A congestion algorithm seeks to decrease throughput if congestion is experienced so that the stream is possibly sent at its highest rate without causing congestion on the path towards the receiver. The TCP SACK does no such thing. TCP SACK seeks to improve the TCP throughput in case of multiple segment losses within a single window.

The RFC 2018 gives an extensive explanation and I suggest reading it as the authoritative reference. It says, among other things:

   TCP may experience poor performance when multiple packets are lost
   from one window of data.   With the limited information available
   from cumulative acknowledgments, a TCP sender can only learn about a
   single lost packet per round trip time.  An aggressive sender could
   choose to retransmit packets early, but such retransmitted segments
   may have already been successfully received.

   A Selective Acknowledgment (SACK) mechanism, combined with a
   selective repeat retransmission policy, can help to overcome these
   limitations.  The receiving TCP sends back SACK packets to the sender
   informing the sender of data that has been received. The sender can
   then retransmit only the missing data segments.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

That's true, but perhaps OP seeing mention of SACK with congestion control might be because SACK's detection/notification of lost packets may trigger flow rate reduction.

[Peter Paluch]

Hello Joseph,

Of course, that is true. However, we have to distinguish if the flow rate reduction is the primary and intended result, or whether it is just a side effect.

The SACK was designed, in contrast, to improve the transmission rate. Reading the RFC 2018 further, it says:

   Multiple packet losses from a window of data can have a catastrophic
   effect on TCP throughput. TCP [Postel81] uses a cumulative
   acknowledgment scheme in which received segments that are not at the
   left edge of the receive window are not acknowledged.  This forces
   the sender to either wait a roundtrip time to find out about each
   lost packet, or to unnecessarily retransmit segments which have been
   correctly received [Fall95].  With the cumulative acknowledgment
   scheme, multiple dropped segments generally cause TCP to lose its
   ACK-based clock, reducing overall throughput.

   Selective Acknowledgment (SACK) is a strategy which corrects this
   behavior in the face of multiple dropped segments.  With selective
   acknowledgments, the data receiver can inform the sender about all
   segments that have arrived successfully, so the sender need
   retransmit only the segments that have actually been lost.

   Several transport protocols, including NETBLT [Clark87], XTP
   [Strayer92], RDP [Velten84], NADIR [Huitema81], and VMTP [Cheriton88]
   have used selective acknowledgment.  There is some empirical evidence
   in favor of selective acknowledgments -- simple experiments with RDP
   have shown that disabling the selective acknowledgment facility
   greatly increases the number of retransmitted segments over a lossy,
   high-delay Internet path [Partridge87]. A recent simulation study by
   Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of TCP
   with SACK over the non-SACK Tahoe and Reno TCP implementations.

Even further, there is a complete Secion 5.1 in this RFC called "Congestion Control Issues" that tries to comment on congestion mechanisms in TCP and their coexistence with SACK. Obviously, authors of this RFC did not consider their own SACK as congestion mechanism itself.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Peter, I agree 100% with both your posts.  I was trying to convey that although SACK in itself is not a congestion control algorithm, I can see how mention of it might be mentioned in reference to congestion control, or more rightly, as dealing with packets lost because of congestion (of course, packet lost is not always due to congestion).

On SACK itself, perhaps one of the benefits of it not mentioned in your posts is how much, much better it performs when dealing with large receive windows, especially those scaled beyond 64 KB.

For those interested in additional reading of how different TCP variants deal with congestion and flow control, you might want to start with this (relatively) short paper A Comparative Analysis of TCP Tahoe, Reno, New-Reno, SACK and Vegas, http://inst.eecs.berkeley.edu/~ee122/fa05/projects/Project2/SACKRENEVEGAS.pdf.

[sawquecisco]

I'm having a confusion here because I read this:

SACK (Selective ACK) is used to identify holes in the TCP stream.   This prevents the stack from having to go back to where the loss  occurred and start all over.   So the pkts from the normal ACK field (in  the "normal" ACK field) to the LE is good to go.  But from the LE to  the RE, pkts were lost.  So if the pkts are transferred like this (1,  through 10) 
10  9  8  7  6  5  4  3  2  1  --->
in normal ACK scenario, if pkt 4 is lost, it will look like this to the receiver
10  9  8  7  6  5  XX  3  2  1  --->
So the receiver will repeatedly ack saying "I need pkt 4...I need pkt  4, I need pkt 4" as other pkts (5-10) trickle in.  When three of these  acks are received, it triggers the fast retransmission, BTW.
When SACK is used, the receiver identifies the hole at pkt 4  position.  So it doesn't throw pkts 5-10 away...instead, it sends a SACK  requesting for pkt#4.

Is this right?

If Sack prevents fast restransmission, then it means we can't use sack with fast retransmission right?

Can sack be used in all of the congestion algorithms?

And also why do they call fast retransmission as a congestion algorithm, it seems to me it is not related to "congestion"?