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).
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.
TCP Timestamps Option (TSopt):
Length: 10 bytes
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
1 1 4 4
The Timestamps option carries two four-byte timestamp fields.
The Timestamp Value field (TSval) contains the current value of
the timestamp clock of the TCP sending the option.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.
A TCP may send the Timestamps option (TSopt) in an initial
<SYN> segment (i.e., segment containing a SYN bit and no ACK
bit), and may send a TSopt in other segments only if it re-
ceived a TSopt in the initial <SYN> segment for the connection.
An example of Retransmission of binary exponential backoff:
1 0.000000000 184.108.40.206 -> 220.127.116.11 1091 397 93 TCP 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290178 TSecr=3055373836
2 0.373950055 18.104.22.168 -> 22.214.171.124 1091 397 93 TCP [TCP Retransmission] 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290183 TSecr=3055373836
3 1.245614314 126.96.36.199 -> 188.8.131.52 1091 397 93 TCP [TCP Retransmission] 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290193 TSecr=3055373836
4 2.972354398 184.108.40.206 -> 220.127.116.11 1091 397 93 TCP [TCP Retransmission] 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290213 TSecr=3055373836
5 6.503940084 18.104.22.168 -> 22.214.171.124 1091 397 93 TCP [TCP Retransmission] 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290253 TSecr=3055373836
6 13.628579933 126.96.36.199 -> 188.8.131.52 1091 397 93 TCP [TCP Retransmission] 1091 > 397 [PSH, ACK] Seq=1 Ack=1 Win=8637 Len=15 TSval=290333 TSecr=3055373836
Referenced Links and documents: