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

From: "sanjay kaniyar" <[email-masked]>
Date: Sun, 06 Jan 2002 12:49:31 -0800

Thanks Andrei.

I don't understand why you say the time required to receive 3 dup-acks would 
be usually much less than the RTT though. In a case where any one of the 
last 3 segments of a window sent are lost, this time would be (slightly 
greater than) 1 RTT. I guess, this is what you meant when you said it would 
be '1 RTT + 1 RTO'?

Sanjay

>From: "Andrei Gurtov" <[email-masked]>
>To: "sanjay kaniyar" <[email-masked]>, <[email-masked]>
>CC: "Reiner Ludwig" <[email-masked]>
>Subject: Re: [Tsvwg] TCP Question about Fast-retransmit:
>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
> >
>

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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

---

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 8 Jan 2002 14:42:15 +0200

Sanjay,

You right when the window and network delay is relatively small, then
receiving 3 DUPACKs takes time close to one RTT.

Figure2 of the tech report shows fast retransmit with and without restart of
the retransmit timer http://www.cs.helsinki.fi/u/gurtov/papers/report01.html

Section 3.3 of the Eifel timer paper explains the issue of REXMT=RTO+RTT
http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html

Andrei

---

From: Noritoshi Demizu <[email-masked]>
Date: Wed, 09 Jan 2002 12:02:26 +0900

Andrei,

 > receiving 3 DUPACKs takes time close to one RTT.

When you use Limited Transmit [RFC3042], it may take 3 RTTs in the
worst case.

  Example scenario:
  1. sent data(1). got ack(2). cwnd becomes 2MSS.
  2. sent data(2) & data(3). start rxmt timer. but data(2) lost.
  3. got ack(2) again. dupacks=1. (1RTT later from 2.)
  4. sent data(4) because of limited transmit.
  5. got ack(2) again. dupacks=2. (2RTT later from 2.)
  6. sent data(5) because of limited transmit.
  7. got ack(2) again. dupacks=3. (3RTT later from 2.)
  8. sent data(2) because of fast retransmit.
  9. got ack(6).

In the case where 3 RTT < RTO < 4 RTT, if retransmission timer is not
restarted by step 8, data(2) will be sent again without waiting for
the ACK for the packet sent by step 8.

Thinking of other scenarios with limited transmit, if retransmission
timer is not restarted on fast retransmit, spurious retransmit could
occure if RTO < 4 RTT. (RTO < 2RTT for cases without limited transmit)

Regards,
Noritoshi Demizu

---

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 9 Jan 2002 15:08:11 +0200

Noritoshi,

Thanks for a very interesting example!

I also observed  that LT makes a spurious timeout more likely during fast
recovery due to a longer DUPACK series.

Andrei