I am new to networking and learning about TCP Timer Management and read this in my textbook:

"If the value of time-out (RTO) is too small then unnecessary re-transmission will take place. If time-out is too long, then performance will degrade because re-transmission will be delayed for the long time whenever a packet is lost."

I want to know why there is need or reason for delaying the re-transmission and not instantly resend the lost packet ?


The reason you don't "instantly resend the lost packet" is that neither side knows a packet has been lost.

  • If the transmitted packet was lost, sender sent something and is still waiting for an ACK; receiver is waiting for a segment which didn't arrive, which to the receiver looks identical to sender being quiet.
  • If the ACK was lost, sender is in the identical situation, but receiver sent an ACK and thinks it's up to date.

For an intuitive understanding of this, consider how you behave when you send email. You send something, expecting a reply. After a while, if nothing comes, you send another. How long you wait (the RTO) depends on your expectations, reasonable or otherwise. Similar behaviour happens on the phone, where if the other end doesn't say something for a while (RTO) , you say "Are you still there?". You will notice that on the phone you adjust your RTO depending on the quality of the line and how well you know the other person.

Only the sender knows, having sent something and waiting a little while, that surely the other end should have responded by now.

How long should the RTO be? Consider a theoretical situation where the outgoing packets and returning ACKs take exactly 10 ms. The RTO must be more than 20 ms or the send will be constantly and pointlessly retransmitting. So let's say 10.001 ms. But in real life there will be variation and jitter in the timing. So we might say let's take the 99th percentile time, which might be 11 ms. Or 1.1 x max(RTT), assuming we keep track of send-to-ACK times as RTT, but that would mean one very long delayed ACK, during a route change, would punish throughput for the rest of the TCP connection, so we had better track changes over time. As RTO matters so much for networking throughput, there has been a great deal of research about it. Kirk McKusick tells an amusing story about when they were at Berkeley and a fluid dynamics person came to tell them to put in a polynomial calculation for this -- they laughed him off at first -- and the dramatic effect even one more term made after they were convinced to try it. A very good description of one way to generate values in practice is http://sgros.blogspot.com/2012/02/calculating-tcp-rto.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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