The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Transport Layer Protocols            9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)                 9  TCP/IP Transmission Control Protocol (TCP)                      9  TCP Reliability and Flow Control Features and Protocol Modifications

TCP Segment Retransmission Timers and the Retransmission Queue 1 2 3 4 TCP Adaptive Retransmission and Retransmission Timer Calculations

Policies For Dealing with Retransmission When Unacknowledged Segments Exist

This then leads to an important question: how do we handle retransmissions when there are subsequent segments outstanding beyond the lost segment? In our example above, when the server experiences a retransmission timeout on Segment #3, it must decide what to do about Segment #4, when it simply doesn't know whether or not the client received it. In our “worst-case scenario”, we have 19 segments that may or may not have shown up at the client after the first one that was lost.

We have two different possible ways to handle this situation.

This is the more “conservative”, or if you prefer, “optimistic” approach. We retransmit only the segment that timed out, hoping that the other segments beyond it were successfully received.

This method is best if the segments after the timed-out segment actually showed up. It doesn't work so well if they did not. In the latter case, each segment would have to time out individually and be retransmitted. Imagine that in our “worst-case scenario” that all 20 500-byte segments were lost. We would have to wait for Segment #1 to time out and be retransmitted. This retransmission would be acknowledged (hopefully) but then we would get stuck waiting for Segment #2 to time out and be resent. We would have to do this many times.

This is the more “aggressive” or “pessimistic” method. Whenever a segment times out we re-send not only it but all other segments that are still unacknowledged.

This method ensures that any time there is a hold up with acknowledgments, we “refresh” all outstanding segments to give the other device an extra chance at receiving them in case they too were lost. In the case where all 20 segments were lost, this saves substantial amounts of time over the “optimistic” approach. The problem here is that these retransmissions may not be necessary. If the first of 20 segments was lost and the other 19 were actually received, we'd be re-sending 9,500 bytes of data (plus headers) for no reason.

TCP Segment Retransmission Timers and the Retransmission Queue 1 2 3 4 TCP Adaptive Retransmission and Retransmission Timer Calculations