TCP Timeout and Retransmission(4)
Spurious Timeouts and Retransmissions
Under a number of circumstances, TCP may initiate a retransmission even when no data has been lost.
Such undesirable retransmissions are called spurious retrans- missions and are caused by spurious timeouts (timeouts firing too early) and other reasons such as packet reordering, packet duplication, or lost ACKs.
A number of approaches have been suggested to deal with spurious time- outs.
They generally involve a detection algorithm and a response algorithm.
The detection algorithm attempts to determine whether a timeout or timer-based retransmission was spurious.
The response algorithm is invoked once a timeout or retransmission is deemed spurious.
The response algorithms typically involve congestion control changes as well, and those aspects are discussed in Chapter 16.
When they(ack6,7,8) arrive, TCP begins to retransmit additional segments that have already been received, starting with the segment following the ACKed segment.
This causes TCP to behave in an unde- sirable “go-back-N” behavior pattern and in turn
causes a collection of duplicate ACKs to be generated and returned to the sender, possibly triggering fast retrans- mit as well.
Several techniques have been developed to mitigate these problems. We now have a look at some of the more popular ones.
Duplicate SACK (DSACK) Extension
DSACK or D-SACK, which stands for duplicate SACK [RFC2883], is a rule, applied at the SACK receiver and interoperable with conventional SACK senders,
that causes the first SACK block to indicate the sequence numbers of a duplicate segment that has arrived at the receiver.
The main purpose of DSACK is to deter- mine when a retransmission was not necessary and to learn additional facts about the network.
With it, a sender has at least the possibility of inferring whether packet reordering, loss of ACKs, packet replication, and/or spurious retransmis- sions are taking place.
The change to the SACK receiver is to allow a SACK block to be included even if it covers sequence numbers below (or equal to) the cumulative ACK Number field.
(It applies equally well in cases where the DSACK information is above the cumulative ACK Number field;
this happens for duplicated out-of-order seg- ments.)
DSACK information is included in only a single ACK, and such an ACK is called a DSACK.
DSACK information is not repeated across multiple SACKs as conventional SACK information is. As a consequence, DSACKs are less robust to ACK loss than regular SACKs.
The Eifel Detection Algorithm
Forward-RTO Recovery (F-RTO)
(this is another retransmission detection method）
The Eifel Response Algorithm
(update metrics like RTT, RTO etc)
Packet Reordering and Duplication
In both of these cases, we wish TCP to be able to distinguish between packets that are reordered or
duplicated and those that are lost. As we shall now see, this is sometimes not so simple.
Reordering
Packet reordering can occur in an IP network because IP provides no guarantee that
relative ordering between packets is maintained during delivery.
This can be beneficial (to IP at least), because IP can choose another path for traffic (e.g., that is faster)
Reordering may take place in the forward path or the reverse path of a TCP connection (or in some cases both).
The reordering of data segments has a some- what different effect on TCP as does reordering of ACK packets.
If reordering takes place in the reverse (ACK) direction, it causes the sending TCP to receive some ACKs that move the window significantly forward followed by some evi- dently old redundant ACKs that are discarded.
This can lead to an unwanted burstiness (instantaneous high-speed sending) behavior in the sending pattern of TCP and also trouble in taking advantage of available network bandwidth,
because of the behavior of TCP’s congestion control (see Chapter 16).
If reordering occurs in the forward direction, TCP may have trouble distin- guishing this condition from loss.
When reordering is moderate (e.g., two adja- cent packets switch order), the situation can be handled fairly quickly.
When reor- derings are more severe, TCP can be tricked into believing that data has been lost even though it has not.
This can result in spurious retransmissions, primarily from the fast retransmit algorithm.
Because a TCP receiver is supposed to immedi- ately ACK any out-of-sequence data it receives in order to
help induce fast retrans- mit to be triggered on packet loss, any packet that is reordered within the network causes a receiver to produce a duplicate ACK.
If fast retransmit were to be invoked whenever any duplicate ACK is received at the sender, a large number of unnec- essary retransmissions would occur on network paths where a small amount of reordering is common.
To handle this situation, fast retransmit is triggered only after the duplicate threshold (dupthresh) has been reached.
The effect is illustrated in Figure 14-13.
The left portion of the figure indicates how TCP behaves with light reordering, where dupthresh is set to 3.
In this case, the single duplicate ACK does not affect TCP. It is effectively ignored and TCP over- comes the reordering.
The right-hand side indicates what happens when a packet has been more severely reordered. Because it is three positions out of sequence, three duplicate ACKs are generated.
This invokes the fast retransmit procedure in the sending TCP, producing a duplicate segment at the receiver.
The problem of distinguishing loss from reordering is not trivial.
Dealing with it involves trying to decide when a sender has waited long enough to try to fill apparent holes at the receiver.
Fortunately, severe reordering on the Internet is not common [J03], so setting dupthresh to a relatively small number (such as the default of 3) handles most circumstances.
Duplication
Although rare, the IP protocol may deliver a single packet more than one time.
This can happen, for example, when a link-layer network protocol performs a retransmission and creates two copies of the same packet.
As we can see, the effect of packet 3 being duplicated is to produce a series of duplicate ACKs from the receiver.
This is enough to trigger a spurious fast retransmit, as the non-SACK sender may mistakenly believe that packets 5 and 6 have arrived earlier.
With SACK (and DSACK, in particular) this is more easily diagnosed at the sender.
With DSACK, each of the duplicate ACKs for A3 con- tains DSACK information that segment 3 has already been received.
