Subject: Re: [Tsvwg] early retransmit

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 12 Mar 2003 11:11:48 +0200

Mark Allman wrote:

>Mark Allman, Konstantin Avrachenkov, Urtzi Ayesta, Josh
    Blanton. Early Retransmit for TCP, February 2003. Internet-Draft
    draft-allman-tcp-early-rexmt-00.txt (work in progress).

http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-00.txt

Another possible hack could be as follows. When cwnd<4 do not trigger fast
retransmit even if 3 DUPACKs are received. The rationale is that DUPACKs in
such case come from unnecessary retransmissions in the past (or duplication
which is less likely). They do not indicate a lost packet since there is
unsufficient flight size to trigger enough "good" DUPACKs.

I guess this hack conflicts somehow with LT and ER...

Andrei

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 12 Mar 2003 07:44:34 -0500

> Another possible hack could be as follows. When cwnd<4 do not
> trigger fast retransmit even if 3 DUPACKs are received. The
> rationale is that DUPACKs in such case come from unnecessary
> retransmissions in the past (or duplication which is less
> likely). They do not indicate a lost packet since there is

Ah-ha!

Right, so there are lots of such cases.  But, I think that using
bugfix (ala RFC 2582) alliviates that problem, right?  In which case
it would be good to add a dependancy of bugfix on implementing ER.
Or, are there some corner cases that would not be caught by bugfix?

Thanks!

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 12 Mar 2003 17:04:59 +0200

> Or, are there some corner cases that would not be caught by bugfix?

Right, bugfix prevents this problem. However, denying all fast retransmits
until the recovery point (what the bugfix does) might be too cruel. This
hack is milder and might be more suitable for general use.

As an example against the bugfix consider a handover of a TCP connection
from a network X with 100-KB buffer to a network Y with 10-KB buffer (I
don't argue that this is a common case in the Internet). All outstanding
segments get lost, TCP recovers with go-back-N after a timeout. However,
since fast retransmits are denied, every CA cycle until the recovery point
has to be recovered with a timeout. The throughput is low.

Alternatively, it's possible to construct a case where bugfix is very useful
to prevent unnecessary retransmits. My point is that there is a slippery
tradeoff about bugfix, and I don't know if there is enough consensus to put
it on the standard track.

Also, this hack prevents against duplication in absence of a timeout, while
the bugfix does not. I know duplication is considered rare, but it can occur
frequently due to bicasting over several access links.

Sally has Newreno on the TSVWG agenda in SF and maybe we will hear what is
the plan about bugfix, since it's currently a part of RFC2582. At least this
beast needs a better name.

Either way, I think that ER draft should mention that DUPACKs after a
timeout are not considered.

Andrei

---

From: Mark Allman <[email-masked]>
Date: Wed, 12 Mar 2003 10:12:30 -0500

> > > trigger fast retransmit even if 3 DUPACKs are received.	    

So, maybe I don't understand the "hack".  My reading of the above
(from your original note) basically says that we wouldn't use ER.
That is, ER says that if cwnd<4 you can fast retransmit on less
dupacks.  The above says we cannot.  What am I missing?

(And, I agree with you ... our naming scheme is grand.  We have
"bugfix" and now we're talking about adding a "hack" to a spec! :)

allman

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 13 Mar 2003 10:14:34 +0200

>dupacks.  The above says we cannot.  What am I missing?
Maybe the solution is to use ER during normal transmission (when not 
below snd_max after timeout). Otherwise use "bugfix" or "hack".

That does not allow the "hack" to protect against duplication. But since 
ER addressess a much more common case, perhaps it should be used...

Andrei