The points of TCP retransmission you must know (1)


TCP retransmission is a mechanism to ensure the data integrity and completeness especially in the bad network environment.


Binary Exponential backoff:

A simple example of TCP’s timeout and retransmission mechanism. The first retransmit occurs at time 42.954, followed by other retransmissions at times 43.374, 44.215, 45.895, and 49.255. The intervals between successive retransmissions are 206ms, 420ms, 841ms, 1.68s, and 3.36s, respectively. These times represent a doubling of the timeout between successive retransmissions of the same segment. This doubling of time between successive retransmissions is called a “binary exponential backoff”, If we measure the elapsed time between the initial request and the time at which the connection is finally aborted, the total time is about 15.5 minutes. After that, we will get the error message.


TCP thresholds to resend the same segment:

Logically, TCP has two thresholds to determine how persistently it will attempt to resend the same segment:

Threshold R1 indicates the number of tries TCP will make (or the amount of time it will wait) to resend a segment before passing “negative advice” to the IP layer (e.g., causing it to reevaluate the IP route it is using).

Threshold R2 (larger than R1) dictates the point at which TCP should abandon the connection.

These thresholds are suggested to be at least three retransmissions and 100s, respectively.



How RTO(retransmission timeout) was determined:

In the large variety of environments, TCP needs to dynamically determine its RTO(retransmission timeout).

Fundamental to TCP’s timeout and retransmission procedures is how to set the RTO based upon measurement of the RTT experienced on a given connection. If TCP retransmits a segment earlier than the RTT, it may be injecting duplicate traffic into the network unnecessarily. Conversely, if it delays sending until much longer than one RTT, the overall network utilization (and single-connection throughput) drops when traffic is lost. Knowing the RTT is made more complicated because it can change over time, as routes and network usage vary. TCP must track these changes and modify its timeout accordingly in order to maintain good performance.

Because TCP sends acknowledgments when it receives data, it is possible to send a byte with a particular sequence number and measure the time required to receive an acknowledgment that covers that sequence number. Each such measurement is called an RTT sample. The challenge for TCP is to establish a good estimate for the range of RTT values given a set of samples that vary over time. The second step is how to set the RTO based on these values. Getting this “right” is very important for TCP’s performance.

The RTT is estimated for each TCP connection separately, and one retransmission timer is pending whenever any data is in flight that consumes a sequence number (including SYN and FIN segments).



Karn’s algorithm:

A problem measuring an RTT sample can occur when a packet is retransmitted. Say a packet is transmitted, a timeout occurs, the packet is retransmitted, and an acknowledgment is received for it. Is the ACK for the first transmission or the second? This is an example of the retransmission ambiguity problem.

The paper [KP87] specifies that when a timeout and retransmission occur, we cannot update the RTT estimators when the acknowledgment for the retransmitted data finally arrives. It eliminates the acknowledgment ambiguity problem by removing the ambiguity for purposes of computing the RTT estimate. It is a requirement in [RFC6298].

If we were to simply ignore retransmitted segments entirely when setting the RTO, however, we would be failing to take into account some useful information being provided by the network (i.e., that it is probably experiencing some form of inability to deliver packets quickly). In such cases, it would be beneficial to reduce the load on the network by decreasing the retransmission rate, at least until packets are no longer being lost. This reasoning is the basis for the exponential backoff behavior we saw. TCP applies a backoff factor to the RTO, which doubles each time a subsequent retransmission timer expires. Doubling continues until an acknowledgment is received for a segment that was not retransmitted. At that time, the backoff factor is set back to 1 (i.e., the binary exponential backoff is canceled), and the retransmission timer returns to its normal value. Doubling the backoff factor on subsequent retransmissions is the “second part” of Karn’s algorithm. Note that when TCP times out, it also invokes congestion control procedures that alter its sending rate.

When an acknowledgment arrives for a packet that has been sent more than once (i.e., is retransmitted at least once), ignore any round-trip measurement based on this packet, thus avoiding the retransmission ambiguity problem. In addition, the backed-off RTO for this packet is kept for the next packet. Only when it (or a succeeding packet) is acknowledged without an intervening retransmission will the RTO be recalculated from SRTT.



Karn’s algorithm enhancement:

This algorithm has been a required procedure in a TCP implementation for some time (since [RFC1122]). There is an exception, however, when the TCP Timestamps option is being used (see Chapter 13). In that case, the acknowledgment ambiguity problem can be avoided and the first part of Karn’s algorithm does not apply.


An example of  Retransmission of binary exponential backoff:



Referenced Links and documents:

  • TCP.IP.Illustrated.Volume.1.2nd.Edition

5 thoughts on “The points of TCP retransmission you must know (1)

  1. feminist frequency shirt

    Thank you a bunch for sharing this with all of us you really realize
    what you’re speaking about! Bookmarked. Kindly additionally seek advice from my website =).
    We may have a hyperlink trade agreement between us

  2. payday loans

    Fantastic site you have here but I was wanting to know if you
    knew of any community forums that cover the same topics discussed in this article?
    I’d really like to be a part of community where I can get advice
    from other experienced individuals that share the same interest.
    If you have any recommendations, please let me know. Many thanks!


Leave a Reply

Your email address will not be published. Required fields are marked *