Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.

From: Mark Allman <[email-masked]>
Date: Thu, 10 Jan 2002 23:08:26 -0500

> > Yes.  But, if you can detect a spurious retransmit (and go-back-n
> > misbehavior) you can avoid it in the future.  So, there is still
> > value in detection no matter when you do so.  I am not saying that
> > use of the DSACK method is *preferred*.  I am simply noting that if
> > someone does not want to incur the cost of using timestamps and
> > eifel there is still *something* that can be done.
> 
> But how does one spurious timeout correlate to the next timeout?
> I don't know how TCP can say the next timeout must be spurious
> given that the previous one is...

Oh, you can't.  (Or, at least it is not obvious to me that you can.)

What I meant was that if you know you took a spurious timeout (or
did a needless fast retransmit) you can take that as an indication
that your estimator is not working as well as you might like (i.e.,
the RTO is not waiting long enough for an ACK to return).  So, you
can tweak the estimator somehow (or alter the dup ack threshold
somehow) in an attempt to come up with a better trigger for
determining loss so that maybe you can prevent further spurious
retransmits (and the resulting negative behavior).

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

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

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 Jan 2002 20:38:41 -0800 (PST)

> retransmits (and the resulting negative behavior).

This makes more sense.  Let's forget about fast retransmit for
the moment and concentrate on spurious timeout.  It seems to me
that one RTO algorithm cannot really handle many different network
characteristics.  For example, the MAX method suggested by Andrei
does not work well, IMHO, in a conventional network.  But it may
work well in his GPRS network.  As far as I know, all TCP 
implementations nowadays have only 1 RTO calculation algorithm builtin.
Does it make sense for TCP to completely switch to another RTO 
calculation algorithm given certain conditions, or given some hints from
outside, say from apps?

Reiner's Eifel algorithm (ignoring his Eifel RTO calculation for
the moment because I don't think it also works well for the RTT
spikes people are talking about here) chooses to stop the damage 
of a spurious timeout immediately.  To some people, it may make TCP 
very agrressive if the detection turns out to be false.  Looking at 
it more conservatively, it is possibly better for TCP to try to
avoid it, as Mark suggested.  But given the current RTO algorithm, I'm
afraid it may not be possible.   And if the alternate algorithm is
actually hinted by an app (or human) which knows exactly the network 
condition, it can avoid the spurious timeout altogether (is this
possible?).

Do people in the wireless world have something in their mind about
an appropriate RTO calculation algorithm which TCP can switch to
when it knows that it is OK to do that?

							K. Poon.
							[email-masked]