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?


  • 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?

2 Answers 2


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.

  • 1
    Can you provide a normative reference? Also your answer is the opposite of the other answer by marctxk. Nov 25, 2016 at 17:09
  • I have expanded my answer, I hope it helps.
    – Gerben
    Nov 26, 2016 at 20:03
  • That seems to make sense, thanks. However I will probably not implement a per-segment retransmission timer, because currently I do not even track how the transmitted data has been segmented, let alone when individual segments have been sent. As you say, I "generate a new segment starting from the first unacknowledged byte in the buffer" which seemed like a simpler design. I should also mention, that lwIP takes the approach of simply requeuing all segments upon timer expiration (but not upon fast retransmit). Nov 27, 2016 at 9:22
  • Could you provide a quote from RFC 793 that mentions one independent retransmission timer per segment in the retransmission queue? Other sources I've consulted say there is just one global retransmission timer that is reset upon the receipt of any ACK. I haven't been able to shine a light on this myself, I've scanned the RFC for any mention of "timeout" and in particular "retransmission timeout", and to be honest it is quite vague in this regard, but from the wording it seems to me there is only one retransmission timeout. I would set a bounty but I don't have enough rep.
    – Anakhand
    Feb 12, 2021 at 10:23
  • Actually, I think I might have found it. RFC 793#section 2.6 (emphases mine): "When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted."
    – Anakhand
    Feb 12, 2021 at 11:07

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.

  • 1
    Can you provide a normative reference? Also your answer is the opposite of the other answer by Gerben. Nov 25, 2016 at 17:09
  • @AmbrozBizjak I'll see if I can find a reference later
    – marctxk
    Nov 29, 2016 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.