Open In App

Packet Loss Detection Algorithms

Improve
Improve
Like Article
Like
Save
Share
Report

TCP uses retransmission for the lost packets during any transmission, but how does packet loss happens and how TCP can detect it. In this article, we are going to discuss packet loss detection algorithms. 

When does a packet loss happen?

Packet loss happens due to the following reasons:

  1. When the receiver’s buffer is full but the sender is sending the packets in large numbers.
  2. When the buffer of intermediary devices i.e. router is full and the sender is sending the packets.

The first case is related to flow control and the receiver advertises its buffer size to the sender to never encounter that situation. The second case is related to congestion control and the sender has to use a combination of slow start and AIMD to avoid that situation. 

Packet loss detection algorithms:

There are three packet loss detection algorithms used by the Linux kernel. These are as follows:

  1. RTO (Retransmission Time Out)
  2. FR (Fast Retransmit)
  3. RACK (Recent acknowledgment)

These algorithms detect the packet loss and the sender reduces the rate of packet transmission to the receiver.

RTO Algorithm:

It was originally proposed by Van Jacobson in ‘Congestion Avoidance and Control’, 1988. 

When a sender sends a packet into the flight it starts a timer which is the function of RTT. This timer runs for an RTO period of time and waits for the acknowledgment to come. If the ACK does not arrive within the RTO period, the corresponding packet is assumed to be dropped. RTO is a function of Round Trip Time (RTT). It is calculated either on a ‘per packet’ basis or a ‘per congestion window (cwnd)’ basis. When the RTO timer expires before the ACK comes, the sender makes a conclusion that the network is congested and it retransmits the lost packet and increases the wait time(RTO) by a factor of 2. This is called the binary exponential backoff technique. It is done in order to allow the network to come out of congested state, it allows it to breathe.

Some important variables used in the computation of RTO
SRTT -> Smoothed RTT
RTTVar -> RTT Variation
RTO -> Retransmission TimeOut
R -> Current RTT measured

When the first RTT measurement (R) is made, the host must set:
SRTT = R
RTTVar = R ÷ 2
RTO = SRTT + (K x RTTVar), where K = 4 as proposed by Van Jacobson in 1988

When a subsequent RTT measurement (R) is made, the host must set:
RTTVar = (1 - β) x RTTVar + β x |SRTT - R|, where β = 1/4
SRTT = (1 - α) x SRTT + α x R, where α = 1/8
RTO = SRTT + (K x RTTVar), where K = 4

Whenever RTO is computed, if it is less than 1 second, then the RTO should be rounded up to 1 second. A maximum value may be placed on RTO provided it is at least 60 seconds. When a retransmission timer expires (i.e., an ACK is not received); the sender retransmits the lost packet and RTO = RTO x 2 The maximum value of RTO should be 60 seconds.

Fast Retransmit algorithm:

Retransmits a dropped packet without waiting for an RTO timer to expire. If ‘three’ duplicate ACKs are received then the sender retransmits the lost packet. Instead of waiting for an RTO period of time, the sender just waits until it gets three duplicate ACKs. This is called Fast Retransmit because 3 duplicates of ACKs take lesser time than RTO. Now, why doesn’t it retransmit after receiving ‘one’ or ‘two’ duplicate ACKs? Because the packet which appears to be dropped might be actually ‘delayed’ and it is not advised to be impatient and prematurely retransmit the packet. Now, why doesn’t it wait for more than three duplicate ACKs to retransmit the dropped packet? Because if it waits longer, the RTO timer might expire. The main goal of Fast Retransmit is to avoid waiting for an RTO to expire.

Duplicate ACK: 

Sender send 6 packets to the receiver at a time. Suppose sender received the ACKs of packet 1 and 2. 

Packet 3 is lost due to network congestion. Receiver received packet 4, 5 and 6.

When packet 4 is received at receiver, it sends the ACK of packet 2 but not for packet 4. ACK for packet 2 is already received. This is called Duplicate ACK.

TCP receiver always acknowledges the packets it has received in order. So, when 1-2-4-5-6 sequence goes out of order, receiver will send ACK for packet 2 only when it receives packet 4-5-6. It says that it has received till packet 2 in order. It will keep on sending duplicate ACKs until it gets all the packets in order.

After 3 duplicate ACKs for 4-5-6 packets, sender retransmits the packet 3. Receiver now gets all packets from 3-6 inorder and will send the ACK-6 which says that it has received till packet 6 inorder. This is called cumulative ACK.

Limitations of FR: 

Fast retransmit is a heuristic that ‘sometimes’ triggers the retransmission of a dropped packet sooner than the regular RTO mechanism. The fast retransmit mechanism does not replace regular timeouts; it just enhances that facility. For example: if packets are dropped at the ‘tail’ of a TCP connection, the fast retransmit mechanism cannot help because it needs at least three duplicate ACKs.

Recent Acknowledgement Algorithm:

A new mechanism called Tail Loss Probe (TLP) addresses the problem of packets getting dropped at the tail of a TCP connection. Additionally, a new packet loss detection technique has been introduced by Google, which is called Recent Acknowledgments (RACK).

Hence, the current packet loss detection methods work together as RACK → Fast Retransmit → RTO 

Linux kernel uses all 3 loss detection algorithms. RACK is used first; when it fails to serve the purpose, Fast Retransmit comes into action; when both fail then RTO comes to rescue.


Last Updated : 21 Feb, 2022
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads