Subject: Re: Doubt regarding the MANAGING THE RTO TIMER

From: Mark Allman <[email-masked]>
Date: Tue, 11 Dec 2001 11:09:08 -0500

> I find it bogus that RFC2988 hardwires the minimum RTO to 1
> second. I haven't found any motivation for that. If the
> retransmission timer is implemented as a hardbeat timer, an RTO
> minimum of 2 x the granularity (as in BSD) is sufficient. I have
> data to confirm this, and hope to write that up some time next
> year.

We've discussed this before...  But, a clarification...

RFC 2988 was written so that there would be **a** standard on how to
manage the RTO.  We essentially took Van's algorithm and codified
it.  The minimum of 1 second is a traditional aspect of the RTO
timer.  And, the work that Vern and I did found that the 1 second
minimum does, in fact, serve to keep the timer conservative.  

My understanding (I won't speak for Vern) of RFC 2988 is that it
*was not* intended to be the end-all-be-all of RTO schemes.  If
someone has something that works better (where "better" is
intentionally left vague) then I'd be happy to see RFC 2988
relegated to historical.  But, I have not yet seen the evidence that
such an algorithm exists (not to say that I think your particular
algorithm is in any way bad -- just that I have not yet been
convinced that it is the Right solution).

allman

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

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 11 Dec 2001 18:32:11 +0100

At 17:09 11.12.2001, Mark Allman wrote:
>We've discussed this before...

Yep :-)

>manage the RTO.

I know, and I think that was a good thing to do. Don't get me wrong, I'm 
glad that we have RFC2988. It's a good document! I only wanted to point out 
some known issues with it in this discussion.

>The minimum of 1 second is a traditional aspect of the RTO
>timer.

That's the one thing about RFC2988 that I never bought, and I raised that 
issue when RFC2988 was last called. What you codified was pretty much what 
is found in the BSD4.4-Lite implementation of TCP, and that one sets RTO to 
2x granularity, and not 1 second.

>And, the work that Vern and I did found that the 1 second

It sure does.

>(not to say that I think your particular
>algorithm is in any way bad --

Just as a warning to those who want to experiment with that timer we 
proposed in ACM Computer Communications Review, Vol. 30, No. 3, July 2000. 
It has (at least) two severe flaws:
- proposing that the RTTVAR weight factor should be adaptive was a bad idea 
:-( In later work, we found that it should stay constant at 2 or 4 
depending on whether every packet is timed or not.
- what we termed the "REXMT-Restart Bug" really is not a bug, but instead 
an extremely valuable safeguard against spurious timeouts in case of 
rapidly increasing RTTs; even more so when timing every packet. Maybe that 
was a built-in but undocumented feature of those who implemented the timer 
in BSD4.4-Lite?

The other features we proposed seem to work fine, though :-) More in a 
paper some time next year.

///Reiner

---

From: [email-masked]
Date: Tue, 11 Dec 2001 21:16:46 +0300 (MSK)

Hello!

> depending on whether every packet is timed or not.

But do you still insist on time constants proportional to cwnd? :-)

> rapidly increasing RTTs;

With disbalanced weight and ewma constants: no doubts. With small weight
your algorithm would calculate strongly underestimated rto when rtt increases.

> 			even more so when timing every packet.

Do you have new paper explaing this? Without explanations this sounds
strange: timing each packet cannot be worse than timing each rtt
in this situation.

No matter, the value of this safeguard is real, but different.
What's about slow start it restarts timer too lately (with sampling
each rtt) and to wrong timeout, so that its usefullness for this
is just plain luck. Its real value was shown to me by Andrey Gurtov
about year ago: it allows to avoid RTO waiting for outstanding segments
trigger fast retransmit. This is real effect.

Alexey

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 12 Dec 2001 00:44:46 +0100

>But do you still insist on time constants proportional to cwnd? :-)

The gains (1/4 and 1/8) should be made proportional to the flight size when 
timing every packet.
The RTTVAR weight (4) should remain a constant, e.g., 2, 3, or 4, although 
3 might be a bad choice because of computing complexity.

>your algorithm would calculate strongly underestimated rto when rtt increases.

I don't follow. Please, explain in more detail.

>Do you have new paper explaing this?

Can you read German? :-) A student of mine finished his diploma thesis on this.

>Without explanations this sounds

Consider packet N and N+1. If the RTT for N suddenly increases (compared to 
SRTT) then chances are that the RTT for N+1 will also be increased. 
Restarting the retransmission timer when the ACK for N arrives, indirectly 
factors that RTT increase into the retransmission timer setting for N+1. 
For this safeguard to be there all the time requires that every packet is 
timed.

>trigger fast retransmit. This is real effect.

True.

///Reiner

---

From: [email-masked]
Date: Wed, 12 Dec 2001 21:22:56 +0300 (MSK)

Hello!

> 3 might be a bad choice because of computing complexity.

Well, it is just basic invariant which holds VJ's formula minimally sane:

alpha + beta*gamma >= 1

In this case calculated rto is never less than the last sample.

So, when selecting low beta (as in your earlier approach) you have
to select high gamma. As soon as you hold beta at 1/4..1/2 now, gamma=2..4
is valid.

But your new approach is dubious anyway. We (linux) experienced sad failure
with gain of 1/4 and sampling each packet. rttvar collapses to zero each burst
of ACKs while one cwnd leaving rto at bare srtt value. This happens in reality
when ACKs are compressed at receiver (I called this "erratic ACKs"),
I can supply tcpdumps between solaris and linux, showing this failure.

Conclusion: rttvar MUST remember information at least over one cwnd.
Otherwise, the scheme is deemed to be insane. Partucularly, BSD with
RTTM is sick of this too, but survives only because it simply does
not use caluclated RTO for all 100% of internet connections holding
it at 500...1000msec instead.

> Can you read German? :-) A student of mine finished his diploma thesis on this.

Alas. Though I learned it in school my memory holds only a few of words.
Anyway, are his thesises with color pictures and formulas?
They should be intelligible not depending on language problems. :-)

> For this safeguard to be there all the time requires that every packet is 

I did not understand. When sampling only each rtt you even have no chances 
to sense the increase, not speaking about prediction of further increase.

Sampling each packet cannot be worse in result.

Probably you were hit by the effect of too high gain in rttvar
and by effect of "erratic acks". Restart also results in some relief
in this case.

Alexey

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 12 Dec 2001 20:21:44 +0000 (GMT)

On Wed, 12 Dec 2001, Reiner Ludwig wrote:

> Can you read German? :-)

Ja, sicherlich - und wir haben auch Babelfish und woerterbucher.

> A student of mine finished his diploma thesis on this.

Geben Sie den URL an, bitte.

L.

Reiner shy about citing his work? There's a first time for everything.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 13 Dec 2001 01:47:30 +0100

>Ja, sicherlich - und wir haben auch Babelfish und woerterbucher.

I have to appologize. The diploma thesis I referred to is written in 
English :-) So forget about the Babelfish.

>Geben Sie den URL an, bitte.

That's the tricky part, but I'll get that fixed. Please, let me know via 
direct mail (not bothering people on the lists) if you're interested in 
getting a copy of that thesis.

///Reiner

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 13 Dec 2001 13:25:12 +0000 (GMT)

On Thu, 13 Dec 2001, Reiner Ludwig wrote:

> English :-)

so easy the two to confuse it is.

L.