SACK is generally viewed as a method to address data recovery, it has not been widely investigated to
address congestion control issues.
FACK decouples the congestion control algorithms (which determine when and how much
data to send) from the data recovery algorithms (which determine what data to send).
multiple packets loss in a window
Floyd pointed out that multiple segment losses can cause Reno TCP to lose its Self-clock, resulting
in a retransmission timeout. These timeouts can cause a substantial performance degradation.
During the timeout interval, no data is sent. In addition, the timeout is followed by a period of Slow-start.
This sequence of events underutilizes the network over several round-trip times, which results in a
significant performance reduction on long-delay links.
TCP Vegas
Through the use of delay measurements, TCP Vegas attempts to eliminate the periodic self-induced
segment losses caused in Reno TCP. The Vegas Congestion Avoidance Mechanism (CAM) algorithm
modifies the "linear increase" phase of congestion avoidance.
Conservation of packets
Conservation of packets requires that a new segment not be injected into the network until an old
segment has left. This principle leads to an inherent stability by ensuring that the number of segments
in the network remains constant. Other schemes, especially rate-based transmission, can cause the
number of segments in the network to grow without bound during periods of congestion, because
during congestion the transmission time for segments increases. TCP implements conservation of
packets by relying on "Self-clocking": segment transmissions are generally triggered by returning
acknowledgements. TCP's Self-clock contributes substantially to protecting the network from
congestion.
Fast Recovery
The Fast Recovery algorithm attempts to estimate how much data remains outstanding in the network
by counting duplicate ACKs. It artificially inflates cwnd on each duplicate ACK that is received, causing
new data to be transmitted as cwnd becomes large enough.
Fast Recovery allows one (halved)
window of new data to be transmitted following a Fast Retransmit.
FACK Design Goals
The requisite network state information can be obtained with accurate knowledge about the forward
most data held by the receiver. By forward-most, we mean the correctly-received data with the highest
sequence number. This is the origin of the name "forward acknowledgement."
The goal of the FACK algorithm is to perform precise congestion control during recovery by keeping
an accurate estimate of the amount of data outstanding in the network.
The FACK Algorithm
When a SACK block is received which acknowledges data with a higher sequence number than the
current value of snd.fack, snd.fack is updated to reflect the highest sequence number known to have
been received plus one.
The FACK algorithm uses the additional information provided by the SACK option to keep an explicit
measure of the total number of bytes of data outstanding in the network. In contrast, Reno and
Reno + SACK both attempt to estimate this by assuming that each duplicate ACK received represents
one segment which has left the network.
The FACK algorithm is able to do this in a staightforward way by introducing two new state variables,
snd.fack and retran_data.
TCP's estimate of the amount of data outstanding in the network during recovery is given by:
awind = snd.nxt - snd.fack + retran_data
Triggering Recovery
Reno invokes Fast Recovery by counting duplicate acknowledgements:
if ( dupacks == 3 ) {
...
}
This algorithm causes an unnecessary delay if several segments are lost prior to receiving three
duplicate acknowledgements. In the FACK version, the cwnd adjustment and retransmission are
also triggered when the receiver reports that the reassembley queue is longer than 3 segments:
if ( ( snd.fack - snd.una ) > (3*MSS) ) || (dupacks == 3) ) {
...
}
Ending Recovery
The recovery period ends when snd.una advances to or beyond snd.nxt at the time the first loss
was detected. During the recovery period, cwnd is held constant; when recovery ends TCP
returns to Congestion Avoidance and performs linear increase on cwnd.
性能比较
The conservative approach promoted by IETF is to consider all unacknowledged data to be
outstanding in the network. The Forward Acknowledgements algorithm takes a more
aggressive approach and considers the unacknowledged holes between the SACK blocks
as lost packets. Although this approach often results in better TCP performance than the
conservative approach, it is overly aggressive if packets have been reordered in the network,
because the holes between SACK blocks do not indicate lost packets in this case.
Due to the large number of lost segments, Reno + SACK underestimates the window during
recovery, and requires several round trip times to complete recovery.
FACK divides its window size by two, waits half of an RTT for data to exit the network, and
then proceeds to retransmit lost segments.
SACK的处理：when sender receives a dup ack, pipe = pipe - 1
然而，如果此packet前面有N个丢包呢？那么应该 pipe = pipe - N 才对。
SACK的处理，For partial acks ：pipe = pipe -2 (one for original dropped packet, one for
retransmitted packet。
在恢复packet后，pipe才对其丢失做出反应，不及时。
所以说，如果在一个窗口内丢失了大量的数据包，SACK可以及时的知道丢了哪些数据包，知道
要重传哪些包。但是，pipe没跟上，pipe不能准确地反映实际情况，也就是没有剔除掉丢失的
数据包，低估了可以传输的数据量。
pipe的计算属于Fast Recovery中的拥塞控制方面。
If more than half a window of data is lost, the window estimate of Reno + SACK will not be
sufficiently accurate.
这个时候，不能精确计算pipe就显得致命了。pipe > cwnd，不能发送数据！而实际上网络中根本
就没有数据了！这会引起超时，接着用慢启动恢复，同Tahoe。
由于FACK可以精确计算pipe，所以不会出现上述问题。