Forward Acknowledgement原理

本文深入探讨了FACK算法的工作原理及其实现细节,包括如何精确估计网络中未确认的数据量,以及与SACK和Reno TCP等算法的区别。通过对比不同算法在数据丢失情况下的性能表现,展示了FACK算法在网络拥塞控制方面的优势。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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,所以不会出现上述问题。

 

转载于:https://www.cnblogs.com/aiwz/archive/2012/02/07/6333397.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值