1

I'm working on a TCP implementation with UDP socket in C, and I'm trying to make the timeout variable with this algorithm

estimatedRTT = (1-a)*EstimatedRTT + alpha*SampleRTT
devRTT = (1-beta)*devRTT + beta*abs(sampleRTT-estimatedRTT);
timeout = estimatedRTT + 4*devRTT;

but I don't understand how to calculate the sampleRTT. The problems I encountered are 2:

  1. If I calculate the sampleRTT as the round trip time of each packet (the time between sending the packet and receiving the related acknowledgment), the timeout will increase forever in case of packet loss. For example, let's say I have a timeout value of 100, I send 1 packet and it is lost, therefore retransmitted for example 3 times. When I receive the ACK, I will calculate the new timeout and it will certainly have increased compared to the previous value, as I have calculated a sampleRTT equal to 300 (3 times the previous timeout, due to the 3 retransmissions). At this point I send a new packet and this too, before arriving, will have to be retransmitted a certain number of times, as it will be lost. And so on. If the loss rate is constant in a network, the timeout will never stop increasing. But, for me, this does not reflect the state of network congestion, because if there is packet loss, a higher value timeout will not reduce losses, at least not directly, and the bandwidth is underutilized
  2. Let's suppose that the sender sends 3 packets, the first is lost while the other two arrive at their destination, and it retransmits only the first. At this point the sender will receive a cumulative ACK, containing the acknowledgment for all 3 packets. In this case, how do I calculate the sampleRTT, given that I don't have an ACK available for each packet?

I hope I was clear.

2 Answers 2

0

I did a little research and this is what I found out:

  1. To prevent timeouts from increasing indefinitely due to packet loss, TCP implementations often use Karn's algorithm. It involves:
  • Ignoring Retransmission RTTs: When a packet is retransmitted, its RTT is not used to update the timeout value.
  • Recalculating Timeout after Successful Transmission: Once a packet is successfully acknowledged, the new timeout is calculated based on the most recent successful transmission's RTT.
  1. Cumulative ACKs: When a cumulative ACK acknowledges multiple packets, the sampleRTT is typically calculated based on the RTT of the earliest unacknowledged packet in the window.

  2. Timeout backoff: You can also Implement timeout backoff to limit the growth of the timeout value in case of packet loss.

Other methods like Smoothed RTT (SRTT) and Deviation Factor (DevRTT) might be useful.

0

the timeout will increase forever in case of packet loss.

There's no RTT information for lost segments, so you don't count unACKed segments, just ACKed ones. For retransmitted segments, you'd count the last attempt.

Let's suppose that the sender sends 3 packets, the first is lost while the other two arrive at their destination, and it retransmits only the first.

That means that SACK is used, which gives you proper RTT for the last two segments - without SACK, all three segments would be retransmitted. The RTT for the retransmitted first one you get after retransmission and successful ACK.

You might want to check out TCP's specification in RFC 9293, including several helpful links.

1
  • Thank you for the answer. Just a last thing. Suppose that I count the sampleRTT with the last attempt. Let's say that the sender sends a packet and receive the ACK, but immediately after a timeout retransmission, due to a delay of the packet: I will count a "wrong" sampleRTT value. In this case, the real RTT value could be timeout+epsilon, but if I count the last attempt, I lose this information, and my sampleRTT will be just epsilon. What about this case?
    – Matteo
    Dec 24, 2023 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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