TCP Selective Acknowledgments (SACK) and Forward Acknowledgment (FACK)

Papers

TCP Rate-Halving

NIMI
Autotuning

Projects
TCP Rate-Halving
NIMI
Autotuning
SACK/FACK
Technology
Integration

Software
TCP Implementations
TReno
Traceroute
Windowed Ping

Websites
TCP Performance
Debugging
Performance
Tuning
TCP Friendly

Related Projects
NLANR
NCNE Engineering
Services
NCNE GigaPop
PSC
LBNL NRG

Miscellaneous
Staff
Help
Search
Web Feedback

TCP Selective Acknowledgements (SACK) and Forward Acknowledgement (FACK)

TCP SACK is a protocol enhancement defined in RFC2018 which allows receivers to specify precisely which segments have been received, even in the presence of packet loss. TCP SACK is an IETF Proposed Standard and has been implemented for most major operating systems.

TCP FACK is a set of new heuristics for handling the congestion window during periods of loss. It includes a number of ideas which other groups have worked on in parallel, but rolls them all up into one package. A detailed description of the algorithms are given in our FACK Note.

PSC implementations of SACK/FACK are available from our implementations page.

Some frequently asked questions about SACK TCP:

When does the receiver renege? After receiver renege, what's happening in the receiver's queue?
I think timeout occurs when:
- ALL (S)ACKs dropped,
- ALL (S)ACKs delayed so much (>RTO), or,
- there's no trigger to generate ACK because ALL data segment dropped.
Is there any reason not listed?

When does the receiver renege? It's hard to understand the status of receiver's queue. After receiver renege, what's happening in the receiver's queue?: First consider a non-SACK receiver. It queues all packets received, even if they are out of sequence, acking the highest-numbered packet for which all data has been received.
It is possible that some implementations may discard unacked packets if memory becomes limited. In practice, I don't know of any implementations that do this, but it is allowed since the packets have not been acked.
The addition of SACK to the receiver doesn't change this behavior, except that some of the discarded packets may already have been SACKed. This condition would cause the receiver to SACK-renege.
I think timeout occurs when ALL (S)ACKs dropped, ALL (S)ACKs delayed so much (>RTO) or there's no trigger to generate ACK because ALL data segment dropped. Is there any reason not listed?: Since SACK (by itself) doesn't change the congestion control behavior of TCP, a timeout can occur if more than half of the data packets or acks are lost. Here's why:
The sender sends out a window of data. The first packet and half of the other packets are lost. When three dupacks are received, cwnd is cut in half. The sender must wait until 1/2 window of acks are received before it is allowed to send again. Since half the packets were lost, this never happens. A timeout results one RTO later.

| Networking | Feedback | Home

This material is based in whole or in part on work supported by the National Science Foundation under Grant Nos. 9415552, 9870758, 9720674, or 9711091. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).

© Pittsburgh Supercomputing Center (PSC), Carnegie Mellon University
URL: http://www.psc.edu/networking/sack-fack.html
Revised: Monday, 08-May-2006 15:14:32 EDT

TCP Selective Acknowledgements (SACK) and Forward Acknowledgement (FACK)

When does the receiver renege? It's hard to understand the status of receiver's queue. After receiver renege, what's happening in the receiver's queue?

I think timeout occurs when ALL (S)ACKs dropped, ALL (S)ACKs delayed so much (>RTO) or there's no trigger to generate ACK because ALL data segment dropped. Is there any reason not listed?