Subject: Re: [Tsvwg] TCP Question about Fast-retransmit:

From: "Andrei Gurtov" <[email-masked]>
Date: Sun, 6 Jan 2002 14:57:42 +0200

Sanjay-

Restarting the retransmit timer upon fast retransmit is a common
implementation strategy among existing TCPs. However, it's not yet
recommended in any RFC to my knowledge.

It is indeed a useful feature to decrease probability of a spurious timeout
during fast recovery. But the additional time it gives is really only time
to receive 3 DUPACKs, which is usually much  less than RTT. It happens
because the retransmit timer is restarted upon an ACK just before DUPACKs
start to arrive. In other words, the actual time when the retransmit timer
fires is RTT+RTO counting from the moment when the segment for which DUPACK
arrives had been originally transmitted.

Andrei

----- Original Message -----
From: "sanjay kaniyar" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 28, 2001 1:41 AM
Subject: [Tsvwg] TCP Question about Fast-retransmit:

> Upon reception of a 3rd duplicate acknowledgement, sender TCP retransmits
> what it thinks is the missing segment and goes ahead with the rest of the
> alogorithm.
>
> In case where the RTO is closely tracking the true RTT of the connection,
it
> would invariably end up handling a retransmission timeout because - by the
> time duplicate acks are received by the sender, approximately 1 RTT would
> have expired and by the time any ack for the new data arrives, 1 more RTT
> would have expired.
>
> So, why not restart the Retransmission timer when a fast-retransmit
happens?
>
> Thanks,
> Sanjay
>
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg