Subject: Retransmission timer in TCP

From: <[email-masked]>
Date: Wed, 4 Dec 2002 12:17:46 +0100

Hi all,

  RTO computation as in recommended in RFC2988 uses one retransmission timer per transmission window. Does this provide a more robust solution than having one retransmission timer per segment ? 

  I mean:

 1) In the first case any ACK that acknowledges new data resets the timer, so increasing the transmission window ( and RTT) provides a more conservative retransmission timer. Because, RTO *RTT(one packet) + TxWindowDelay(because of buffering), and time for next ACK is roughly RTT(one packet).

 2) In the second case, the retransmission timer of one packet would be only reset when that packet is acknowledged, so time for ACK * RTT(one packet) + TxWindowDelay, and the retransmission timer would be more sensible to delay spikes ( eg. likely in wireless networks). 

  I haven't found much information about how second option is implemented, maybe it is implemented in a different way. Do you know some reference that discuss this difference?. Or maybe this is not really an issue, I'm not sure about if the option 2) is really widely used, or it is really that most common systems (Windows, Solaris, Linux ... etc) just implement RFC2988. 

  Thanks in advance,
  Best regards,
  Rafa

---

From: Mark Allman <[email-masked]>
Date: Wed, 04 Dec 2002 16:22:42 -0500

------- Forwarded Message

Date: Wed, 04 Dec 2002 12:45:30 +0100
To: <[email-masked]>
From: Reiner Ludwig <[email-masked]>
Subject: Re: Retransmission timer in TCP
Cc: <[email-masked]>

At 12:17 04.12.2002, [email-masked] wrote:
>   RTO computation as in recommended in RFC2988 uses one retransmission 
> timer per transmission window. Does this provide a more robust solution 
> than having one retransmission timer per segment ?

One timer per segment causes more burden for the CPU, which is one reason 
why you wouldn't want to do that. Think of busy web servers.

>  1) In the first case any ACK that acknowledges new data resets the 
> timer, so increasing the transmission window ( and RTT) provides a more 
> conservative retransmission timer. Because, RTO *RTT(one packet) + 
> TxWindowDelay(because of buffering), and time for next ACK is roughly 
> RTT(one packet).

This is explored in detail in this paper:
http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html

///Reiner

------- End of Forwarded Message