Subject: Req: Doubt regarding the MANAGING THE RTO TIMER

From: Srinivas Amaravadi <[email-masked]>
Date: Tue, 13 Nov 2001 10:19:15 +0530

Hi  All,

Here is a small doubt in RFC  2988 section 5.3  page4

  (5.3) When an ACK is received that acknowledges new data, restart the
          retransmission timer so that it will expire after RTO seconds
          (for the current value of RTO).

Why should the timer restart ??? section 5.1 and 5.2 are clear but 5.3 is 
not clear

Thanks

Srinivas

---

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 13 Nov 2001 09:01:29 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Srinivas Amaravadi
> Sent: 13. marraskuuta 2001 6:49
> To: [email-masked]
> Subject: Req: Doubt regarding the MANAGING THE RTO TIMER
>
>
> Hi  All,
>

If the timer is not restarted a spurious RTO can easily occur. Imagine the
slow start phase and that the RTO value is updated once per RTT. The RTT can
double between two samples due to queuing delay. If RTO is not restarted, a
spurious timeout will occur before a new RTT sample is collected.

More discussion can be found in:
Reiner Ludwig, Keith Sklower, The Eifel Retransmission Timer. Appears in ACM
Computer Communications Review, Vol. 30, No. 3, July 2000.
http://iceberg.cs.berkeley.edu/publications.html

In my opinion to avoid spurious RTOs TCP should collect RTT samples more
frequently than once per window, and restart the timer also on fast
retransmit, and possibly on partial ACKs and DUPACKs.

Andrei