Should all sent segments be requeued after a TCP retransmission timeout expires?

Question

I am developing a TCP implementation and could not find a clarification to this in the relevant RFCs (793, 1122, 5681, 6298). When the retransmission timer expires, the first segment which has once been sent but has not yet been acknowledged is retransmitted, and CWND is set to one segment. Then slow-start is supposed to be used, which will increase CWND by one segment for each new ACK.

The question is whether the other already sent segments are effectively re-queued for transmission as if they had never been sent. Particularly, suppose an ACK is received which increases CWND sufficiently to allow sending one of the remaining already-sent segments, but does not acknowledge it. Should such a segment be transmitted now, or only upon the next expiration of the retransmission timer?

Example:

• The following segments are sent for the first time (represented by their sequence numbers): 1000, 2000, 3000, 4000. Both CWND (congestion window) and SND_WND (receiver window) were large enough for these segments to be sent.
• The retransmission timer expires before any ACK is received. Segment 1000 is retransmitted. Slow-start begins and hence CWND is reduced to 1000 (=MSS).
• An ACK num 2000 is received, acknowledging the first but not any other segments. CWND is increased to 2000 as per the slow-start algorithm.
• At this point, the CWND permits transmission of segments 2000 and 3000. Are segments 2000 and 3000 transmitted now, or would it take another expiration of the retransmission timer to transmit segment 2000?

Answer 1

According to RFC 793, TCP uses a retransmission timer per segment in its retransmission queue. That means segment 2000 in your example will only be retransmit when its own retransmission timer expires.

When ACK num 2000 is received, the CWND allows for 2000 outstanding bytes. But at this point, there are 3000 bytes outstanding, so nothing extra is sent. TCP waits for the respective retransmission timers before resending segments 2000, 3000 and 4000.

However, in your example scenario, four segments are sent at once, meaning their respective retransmission timers will expire at (almost exactly) the same time. That would result in the retransmission of segments 2000 and 3000 immediately after retransmitting segment 1000.

To clearly answer the question, RFC 793's TCP will not "wait for another expiration of the retransmission timer" because there is no such thing as "the retransmission timer". TCP will wait for the expiration of any of the currently active retransmission timers to retransmit the corresponding segment.

In reality, TCP has evolved since 1981.

For example, Fast Retransmit (RFC 2581/5681) is an exception to the above rule. After receiving three duplicate acks indicating the out-of-order reception of a segment, fast retransmit will kick in retransmitting a segment before its retransmission timer expires.

TCP is byte-stream oriented, and the retransmission queue holding previously sent segments is only one of many ways to implement retransmissions.

A TCP implementation might as well do without such a queue and generate a new segment starting from the first unacknowledged byte in the buffer. No specification requires this to be the exact copy of a previously sent segment. It could have a different size or contain a partially overlapping part of the bytestream.

Introducing features like selective acknowledgments further complicates things.

Answer 2

In your example 2000 and 3000 are transmitted "now". The retransmission timer is only there to signal the possiblity of lost packets, you've "been there done that" once you've started retransmission.