0

TCP uses various mechanisms to detect packet loss and decide when to retransmit segments. In this question, I am asking about the timeout-based retransmission, wherein a TCP retransmits certain segments upon the expiration of a certain timer. Is this a single global retransmission timer, i.e. one timer for all the segments in the retransmission queue, or is there one independent retransmission timer for each segment in the queue?

Specifically, the (mutually exclusive) options that I think might be possible are these:

  • Option A: There is one single, global, timer.
    • When a segment is sent, if the timer wasn't active, it is started, and a copy of the segment is placed in the retransmission queue.
    • When an ACK arrives that acknowledges that specific segment (possibly among others), it is removed from the retransmission queue.
    • Whenever any ACK arrives, no matter what data it is acknowledging, the retransmission timer is reset.
    • When the timer expires (no ACKs have been received in that time window), retransmit some (possibly just one) of the segments at the front of the retransmission queue and reset the timer (possibly with a longer duration).
    • When the retransmission queue becomes empty, cancel the timer.
  • Option B: Each segment in the retransmission queue has its own independent timer.
    • When a segment is sent, a copy is placed in the retransmission queue, a new retransmission timer is associated with it, and the timer is started.
    • When an ACK arrives that acknowledges that specific segment (possibly among others), it is removed from the queue and its associated timer is cancelled.
    • When the timer of a specific segment expires, that segment is retransmitted and the timer is reset.

I'm considering other options that might be the case, but they are variations on these two.

Here is how my confusion came to be. First, this answer says:

According to RFC 793, TCP uses a retransmission timer per segment in its retransmission queue.

This supports option B. Recently, in the networked systems course I'm taking, the lecturer mentioned this mechanism in a way that seemed to imply that there was only one timer (option A). I asked him this specific question, and he confirmed that there is only one timer and that it is reset by any ACK received. Of course, this contradicted my previous belief, so I tried to access a primary source myself to try to shine a light on this. The original version of RFC 793, in section 2.6, mentions the following (emphases mine):

When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgement for that data is received, the segment is deleted from the queue. If the acknowledgement is not received before the timer runs out, the segment is retransmitted.

Moreover, in section 3.9 of the same document, under the "RETRANSMISSION TIMEOUT" header, this is written:

For any state if the retransmission timeout expires on a segment in the retransmission queue, send the segment at the front of the retransmission queue again, reinitialize the retransmission timer, and return.

In the way it's worded, it seems it is specifying one independent timer per segment in the retransmission queue (option B); although, to be honest, it's quite vague to me.

But then, the most recent version of RFC 793 doesn't include the first quoted paragraph (or any equivalent, as far as I can tell), but the second one is still there. Then again, section 5 of RFC 6298 reads as follows:

5. Managing the RTO Timer

An implementation MUST manage the retransmission timer(s) in such a way that a segment is never retransmitted too early, i.e., less than one RTO after the previous transmission of that segment.

The following is the RECOMMENDED algorithm for managing the retransmission timer:

  • (5.1) Every time a packet containing data is sent (including a retransmission), if the timer is not running, start it running so that it will expire after RTO seconds (for the current value of RTO).

  • (5.2) When all outstanding data has been acknowledged, turn off the retransmission timer.

  • (5.3) When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire after RTO seconds (for the current value of RTO).

When the retransmission timer expires, do the following:

  • (5.4) Retransmit the earliest segment that has not been acknowledged by the TCP receiver.

  • (5.5) The host MUST set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in (2.5) above may be used to provide an upper bound to this doubling operation.

  • (5.6) Start the retransmission timer, such that it expires after RTO seconds (for the value of RTO after the doubling operation outlined in 5.5).

[...]

This is clearly specifying option A. But it says that this is just the recommended algorithm, so maybe it is not part of the "core" TCP standard?

I'm incredibly confused. Could you help me settle this issue with an authoritative reference?

2
  • See if RFC 2018 might help you. TCP has had several improvements in the last 40 years. – Ron Trunk Feb 12 at 14:57
  • Thanks, but I don't see how SACKs relate to retransmission timeouts or this specific issue? – Anakhand Feb 12 at 16:19
1

Note that the "most recent version" you linked to is just a draft with no real implication.

RFC 793 doesn't actually specify this - early RFCs were like that and left much room for optimization. The timer variant is specific to a given implementation. However, we can safely assume that most implementations use your option A - a single, socket-specific timer.

Note that the timer is only restarted when data is transmitted, not for an otherwise empty ACK segment.

4
  • "Note that the timer is only restarted when data is transmitted, not for an otherwise empty ACK." To paraphrase: "only ACKs that are valid and acknowledge previously unacknowledged data trigger the resetting of the timer"; is this correct? – Anakhand Feb 12 at 16:18
  • I was referring to transmitted data and empty ACK (segments). You are talking about received ACKs. – Zac67 Feb 12 at 16:31
  • Ah, I think I understand what you mean: if the timer is not currently active, it is only created again when the sender sends some data (and not when it sends out an empty ACK). Is this it? – Anakhand Feb 12 at 17:42
  • Yep, that's it. – Zac67 Feb 12 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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