1. Introduction
Transmission Control Protocol (TCP) is a communications standard that enables application programs and computing devices to exchange messages over a network. It is designed to send packets across the internet and ensure the successful delivery of data and messages over networks.
In this tutorial, we’ll examine TCP retransmission: its definition, causes, and how it works.
2. TCP Retransmission
TCP provides a reliable byte-stream transport service, building upon the best-effort datagram delivery service provided by the Internet Protocol. TCP achieves this by dividing data into TCP segments and transporting these segments in IP packets. As we know, unlike the User Datagram Protocol (UDP), TCP uses a three-way handshake process used to establish a TCP connection, as illustrated below:
After establishing the connection, the sender starts transmitting TCP segments to the receiver. However, one or some TCP segments sent by the sender may get lost on the way before reaching the receiver. This causes the receiver to send the acknowledgment (ACK) with the same ACK number to the sender. As a result, the sender retransmits the same segment to the receiver. This is called TCP retransmission. The retransmission of packets is one of the differences between TCP and UDP.
3. Causes of Packet Loss
Not all packets sent to a link are necessarily received successfully by the receiver at the other end of the link. There are a number of possible causes of packet loss. These may occur as frames travel across a link, and include:
- Loss due to channel noise is often characterized by random frame loss. Channel noise may also result from other traffic degrading channel conditions
- Frame loss due to channel interference. This interference can be random, structured, and in some cases even periodic
- A link outage, a period during which the link loses all or virtually all frames, until the link is restored. This is a common characteristic of some types of link, e.g., mobile cellular radio.
Other forms of packet loss are not related to channel conditions, but include:
- Loss of a frame transmitted in a shared channel where a contention-aware MAC protocol is used (e.g., due to collision). Here, many protocols require that retransmission is deferred to promote stability of the shared channel (i.e., prevent excessive channel contention)
- Packet discards due to congestion. Queues will eventually overflow as the arrival rate of new packets to send continues to exceed the outgoing packet transmission rate over the link
- Loss due to implementation errors, including hardware faults and software errors. This is recognized as a common cause of packet corruption detected in the endhosts
The rate of loss and patterns of loss experienced are functions of the design of the physical and link layers. These vary significantly across different link configurations. The performance of a specific implementation may also vary considerably across the same link configuration when operated over different types of channels.
4. When TCP Retransmission Occurs?
The sender discovers that the TCP segment is lost when
- either the time-out timer expires
- or it receives three duplicate acknowledgments
4.1. Retransmission After Time out Timer Expiry
Each time the sender transmits a TCP segment to the receiver, it starts a time-out timer.
Now, the following two cases are possible:
- The sender receives an ACK for the sent segment before the timer goes off. In this case, the sender stops the timer
- The sender does not receive any ACK for the sent segment, and the timer goes off. In this case, the sender assumes that the sent segment is lost. The sender retransmits the same segment to the receiver and resets the timer
The figure below illustrates an example of TCP retransmission after the time-out timer expiry:
4.2. Retransmission After Receiving 3 Duplicate ACKs
When the sender receives three duplicate ACKs for a TCP segment sent by it, it will assume that the corresponding segment is lost. The sender then retransmits the same segment without waiting for its time-out timer to expire. This is known as early retransmission or fast retransmission.
Consider that the sender sends 5 TCP segments to the receiver, as depicted in the figure below:
The second TCP segment gets lost before reaching the receiver. The sequence of steps taking place are:
- On receiving Segment 1, the receiver sends ACK asking for Segment 2 next (original ACK)
- On receiving Segment 3, the receiver sends ACK asking for Segment 2 next (1st duplicate ACK)
- On receiving Segment 4, the receiver sends ACK asking for Segment 2 next (2nd duplicate ACK)
- On receiving Segment 5, the receiver sends ACK asking for Segment 2 next (3rd duplicate ACK).
Now, the sender receives 3 duplicate ACKs for Segment 2 in total. So, the sender assumes that Segment 2 is lost. Retransmission is established for Segment 2 without waiting for the timer to go off.
It is noted that after receiving the retransmitted Segment 2, the receiver does not send the ACK asking for Segment 3, or 4, or 5, but sends the ACK asking for Segment 6 directly from the sender. This is because previous segments have already been received, and ACKs for them have already been sent (although wasted in asking for Segment 2).
5. Conclusion
In this article, we covered the concept and principles of TCP retransmission.
We have learned what are the reasons that cause packet loss on the network links. We also learned the two main rules for establishing TCP retransmission, which are the expiration of the time-out timer and the receipt of three duplicate ACKs at the sender. By employing the retransmission mechanism, the TCP protocol guarantees the delivery of packets from the sender to the receiver and thus provides reliable communication and increases the performance of the network.