TCP and Successive Fast Retransmits

Previous

8.0.- TCP and Successive Fast Retransmits

In May 1995, Sally Floyd wrote TCP and successive fast retransmits: Here is a summary of this paper:

The problem

In this note we point out a longstanding problem for current Tahoe and Reno TCP implementations that results from invoking Fast Retransmit more than once in one roundtrip time. The problem is illustrated by packet trace from simulations. We have seen the same behavior in packet traces of TCP traffic on the Internet.

Given current TCP implementations, for a TCP connection with a large congestion window and multiple nonconsecutive packet drops within one window of data, it is possible for the TCP source to execute the Fast Retransmit procedure twice for one window of packets. For Tahoe TCP, this can occur when there are at least two nonconsecutive runs of packet drops in one window of data.

This problem is somewhat more difficult to duplicate in simulations with Reno implementations. With Reno implementations, the source essentially assumes that only one packet has been dropped, retransmits that dropped packet, and instead of waiting for the ACK to be received, continues transmitted new packets.

For multiple packet drops in one roundtrip time, the Reno source often has to wait for a retransmit timer to recover (given the absence of Selective ACKs). And in some circumstances with Reno, the ability to have multiple Fast Retransmits in a single roundtrip time can avoid the wait for a retransmit timer timeout, in the absence of Selective ACKs. However, it is also possible for a second Fast Retransmit to be invoked from duplicate ACKS received from packets retransmitted during the slowstart triggered by the retransmit timer timeout.

Recommendations

One fix to the problem of multiple Fast Retransmits is not to treat duplicate ACKs that acknowledge packets from the same window as packets from a previous Fast Retransmit as an indication of continued congestion.

In the Tahoe TCP implementation in our simulator, the fix was done using an extra variable high_seq to record the highest sequence number outstanding when the TCP initiated a Fast Retransmit or responded to an ECN or a retransmit timer timeout. Duplicate ACKs that did not acknowledge data higher than this sequence number, not necessarily being an indication of congestion, would not trigger a Fast Retransmit. Once the TCP source transmitted a packet higher than the variable high_seq, then the variable would be disabled (e.g., set to zero) until the next congestion event.

In a Reno TCP implementation, the issues are slightly different. One possilibity would be to set the variable high_seq when the TCP source responds to an ECN or to a retransmit timer timeout, but not to set it when TCP initiates Fast Retranmit/Fast Recovery. This would still allow multiple Fast Retransmits during Fast Recovery, but would prevent the sequence of a Fast Retransmit/Fast Recovery, a timeout, and then a second Fast Retransmit/Fast Recovery for the same window of data.

The disadvantage of this fix is that, for both the Tahoe and the Reno cases, and for acks that do not acknowledge data greater than high_seq, the TCP source cannot distinguish duplicate acks resulting from retransmitted packets that had previously been correctly received by the receiver, and duplicate acks resulting from packet losses. In the absence of Selective ACKs, it is inevitable that any fix would rely on incomplete information, and therefore would occasionally result in suboptimal behavior.

Thus, the most robust and appropriate fix to this problem would be to implement Selective ACKs. The problem of multiple Fast Retransmits described in this section only occurs because the source retransmits packets that have already been correctly received by the receiver. With Selective ACKs, this behavior could generally be avoided.

Previous

Content

Next