The principle analysis of TCP fast retransmission and fast recovery

Translated from: http://blog.csdn.net/zhangskd/article/details/7174682

Time-out retransmission is an important mechanism for the TCP protocol to guarantee the reliability of data, and the principle is to open a timer after sending a data.
If there is no ACK message sent to the datagram for a certain amount of time, the data is sent again until it is successfully sent. This is the data
A patching mechanism given in case of packet loss. In general, retransmission occurs after a timeout, but if the sending side receives more than 3
Repeat ACK, you should realize that the data is lost and needs to be re-routed. This mechanism does not need to wait until the retransmission timer overflows, so call
Do fast retransmission, and after fast retransmission, because the walk is not slow start but congestion avoidance algorithm, so this is called fast recovery algorithm.

Fast retransmission and fast recovery are designed to: quickly recover lost packets.
Without fast retransmission and fast recovery, TCP will use a timer to request a transfer pause. There are no new packets during the pause period
Be sent.
Fast retransmission and fast recovery algorithms are presented in 4.3BSD and are described in RFC2001 and RFC2581.
Rapid retransmission and rapid recovery have gone through several stages.

1. Tahoe

The Tahoe algorithm is an earlier version of TCP. Its core idea is to let CWnd rapidly approximate the available channel capacity in exponential growth, and then
Slowly approaching equilibrium. The Tahoe includes 3 basic congestion control algorithms: Slow start, congestion avoidance, and fast retransmission.

As we can see, there is no fast recovery algorithm for Tahoe. This is also its shortcomings.
When 3 duplicate ACK is received or in the case of timeout, Tahoe is 1 and then enters the slow start phase. This will cause a net
, on the other hand, greatly reduces the utilization of the network.
In other words, once a swap is found, CWnd is returned to its original shape.

Without the fast recovery algorithm, new packets cannot be sent during the recovery of lost packets, with a throughput of 0. And actually
If you use this time to send the appropriate amount of new packets, you can greatly improve the transmission efficiency when packet loss. This is the fast recovery name
Origin.

2. Reno

Compared to Tahoe, Reno increases the fast recovery phase, which means that after fast retransmission, it enters the congestion avoidance phase rather than the slow
The start phase.
Reno prevents the communication path from going empty after Fast retransmit.
Reno Sender uses additional incoming DUP ACKs to clock subsequent outgoing packets.
Algorithm Description:

[Java]View PlainCopy

2. Step1:
4. if (dupacks >= 3) {
6. Ssthresh = Max ( 2, CWnd/ 2);
8. CWnd = Ssthresh + 3 * SMSS;
10. }
14. Step2: Retransmission of lost groupings
18. Step3: After each receipt of a duplicate ACK acknowledgement, cwnd++
22. STEP4: When a ACK acknowledgment is received for the newly sent data, CWnd = Ssthresh, this ack can be
24. After the lost grouping, all packets sent before the first duplicate ACK are confirmed.

In the fast recovery phase, CWnd adds 1 for each duplicate ACK received, and when a non-duplicate ACK is received, the CWnd = Ssthresh,
Into the congestion avoidance phase; If a time-out retransmission occurs, the Ssthresh is half of the current CWnd, CWnd = 1, re-entering
Slow start phase.
Reno Fast Recovery phase exit Condition: A non-duplicate ACK is received.

3. NewReno

Reno cannot effectively handle multiple groupings lost from the same data window, so there is a newreno.
Newreno modified the Reno fast recovery algorithm to handle the "partial acknowledgment" that occurs when multiple segments of a window are lost simultaneously
(Partial ACKs, which arrives in the fast recovery phase and confirms the new data, but it only confirms that part of the send before it enters the fast retransmit
Data).
In this case, the Reno exits the fast recovery state, waits for a timer overflow or a duplicate acknowledgment ack to arrive, but Newreno
Does not exit the fast recovery state, but instead:

[Java]View PlainCopy

1. Step1: Retransmission immediately after that part of the message segment ACK, the Congestion window is equal to the portion of its minus partial ack.
3. Step2: For new data that has been confirmed, cwnd++
5. Step3: For the first or every partial ACK, the retransmission timer resets.  And each time you reset CWnd = Original CWnd/ 2.

The Newreno algorithm has variable recover, whose value is the maximum sending sequence number when a packet loss is detected. Only if the data before recover
After the report has been confirmed, the rapid recovery can be introduced into the congestion avoidance phase.
When the timeout is exceeded, the maximum sequence number that is sent is saved in the recover variable, ending the fast recovery process.
Newreno does not support sack.

4. SACK

During Fast Recovery, SACK maintains a variable calledpipe that represents the estimated number
of packets outstanding in the path.
The sender is sends new or retransmitted data when the estimated number of packets in the path
is less than the congestion window. The variable pipe is a incremented by one when the sender either
Sends a new packet or retransmits an old packet. It is decremented by one when the sender receives
A DUP ACK packet with a SACK option reporting the new data have been received at the receiver.

Use of the pipe variable decouples The decision of the if to send a packet from the decision of which
packet to send.

The sender maintains a data structure, Thescoreboard, that remenbers acknowledgements from
Previous SACK option. When the sender was allowed to send a packet, it retransmits the next packet
From the list of packets inferred to is missing at the receiver. If There is no such packets and the
Receiver ' s advertised window is sufficiently large, the sender sends a new packet.

When a retransmitted packet was itself dropped, the SACK implementation detects the drop with a
Retransmit timeout, retransmitting the dropped packet and then slow-starting.
The sender exits Fast Recovery when a Recovery acknowledgement is received acknowledging
All data is outstanding when Fast Recovery is entered.

[Java]View PlainCopy

2. Step 1:
4. Fast Recovery is initiated,
6. Pipe-1 (for the packet assumed to the been dropped).
8. Pipe +1 (for the packet retransmitted)
10. CWnd = CWnd/ 2
12. Step 2:
14. If pipe <= cwnd,sender retransmits packets inferred to be missing.
16. If There is no such packets, Sender sends new packets.
18. Step 3:
20. When sender receives a DUP ACK, pipe = pipe- 1
22. When sender sends a new/retransmit to old packet, pipe = pipe +1
24. Step 4:
26. For partial acks:pipe = pipe- 2
28. (one for original dropped packet,one for retransmitted packet)
30. Step 5:
32. All packets outstanding before Fast Recovery were acked,
34. Exit Fast Recovery.
36. When exiting fast recovery, CWnd also reverts to Ssthresh, which goes into congestion avoidance.

Unlike Reno, the following are:

(1) When to send packet: determined by the calculation of pipe changes, is no longer calculated CWnd changes.
(2) which packet to send: It is up to the sack to carry the information and react more quickly.

1: Is it an effect to repeatedly drop packets within a window?

Answer: Yes. If you lose only one package, you will be able to confirm all the packages in this window when you receive a non-duplicate ACK. And then into the congestion
Avoidance phase. This is what Reno wants to achieve.
If you lose more than one package, you cannot confirm all of the packages in this window when you receive a non-duplicate ACK. However, the quick recovery is also exited,
Enter the congestion avoidance phase.

There are two possible scenarios at this time:
(1) Rapid re-transmission and rapid recovery for many times. Also found lost packets, again into the fast retransmission and rapid recovery. Note that every time you enter
Ssthresh and CWnd are halved when fast retransmission and fast recovery. Multiple drops will eventually cause the Ssthresh index to decrease.
By painting the CWnd (t) graph, it is found that not only is the throughput of this period very low, but also the starting point for congestion avoidance after recovery is very low, from
The resulting throughput is also very low.

(2) After repeated rapid retransmission and rapid recovery, then a transmission timeout occurs.
So what are the conditions that occur when a transmission timeout occurs?

1) When both packets is dropped from a window of data, the Reno sender was forced to wait for a
Retransmit timeout Whenever the congestion window is less than packets when Fast
Recovery is initiated, and whenever the congestion window is within and packets of the receiver ' s
Advertised window when Fast Recovery is initiated.

2) when three packets was dropped from a window of data, the Reno sender was forced to wait for
A retransmit timeout whenever the number of packets between the first and the second dropped
Packets is less than 2 + 3W/4, for W the congestion window just before the Fast retransmit.

The probability of this situation is great, that is, a window appears 3 drops, there is a large probability of a timeout. Window size when a packet is dropped
Is 15, there are three drops, then no matter the order of packet loss, 2 times after the FR/FR, there will always be a timeout.
Timeouts are generally due to unacknowledged packets > can be used by CWnd, cannot send new data, and there is not enough in the network
Repeat ACK to trigger fr/fr.

Question 2: Why does it increase CWnd when congestion occurs?

Answer: When the packet is detected, the window is CWnd. At this time the network has a maximum of CWnd packages (In_flight < CWnd). Whenever you receive
A duplicate ACK indicates that there is a packet leaving the network and reaching the receiving end. Then, the network can also accommodate 1 more packages. By
The sliding window on the sending side cannot be moved, so if you want to keep in_flight, you can make cwnd++.
This way, you can increase throughput. In fact, the new packets sent during fast recovery are more than the CWnd that caused the packet loss.
has been greatly reduced.

Performance analysis

The Tahoe does not have a fast recovery mechanism, and after the packet is dropped, it not only re-sends some data that has been successfully transferred, but also the throughput during recovery
is not high.
With the information that sack option carries, we are able to know in advance which packets are missing. Newreno can only be restored within each RTT
A lost packet, so if n packets are lost, then fast recovery will continue to N*rtt time, when N compares
Big time, it was quite a long period. Sack, however, does not have this limitation and relies on the information of sack option, which can simultaneously recover
Multiple packets, faster and smoother recovery.
When multiple drops occur in the same window, both sack and Newreno can eventually recover more quickly and smoothly. and the Reno
Often time out, and then use slow start to recover, this time Reno performance is like Tahoe, will result in the repetition of accepted data
Transfer. Reno Recovery period, there will be low throughput, long recovery time, do not have to re-send data, recovery after the end of the threshold is too low and so on some questions
Serious impact on performance.

Conclusion

Through the above analysis we can see:

It is a fundamental consequence of the absence of SACK that the sender have to choose between
The following strategies to recover from lost data:

(1) retransmitting at the most one dropped packet per round-trip time

(2) retransmitting packets that might has already been successfully delivered.

Reno and New-reno Use the first strategy, and Tahoe uses the second.
With SACK, a sender can avoid unnecessary delays and retransmissions, resulting in improved
Throughput.

Sack of the poor

It says a lot of good things about sack, so let's talk about its shortcomings.

For a large BDP network where the number of packets is in flight, the procesing overhead of
SACK information at the end points can is quite overhelming because each SACK block invokes
A large packet buffers of the sender for acked packets in the block, and every
Recovery of a loss packet causes the same search at the receiver.

In the BDP network, this problem is particularly noticeable and can cause a number of problems by consuming the CPU heavily. To a certain extent, at this time
Sack, like a Dos attack, consumes a lot of CPU per traversal, a time complexity of O (n^2), n packets in
The number of flight.

The system overload can cause serious problem:it can cause multiple timeouts (as even packet
Retransmission and receptions are delayed) and a long period of zero throughput.

Of course, this is a matter for the medium-sized BDP (100~1000) or large-scale BDP network to consider, for the general BDP and
There is no big problem with the words.

The principle analysis of TCP fast retransmission and fast recovery