Subject: Re: Retransmissions without explanation

From: Vern Paxson <[email-masked]>
Date: Thu, 20 May 1999 13:15:59 PDT

> Here are some issues which I think are unresolved, or could use better
> documentation:
> 
> - How to modify the RTO calculation when doing 1323 timestamps.  The
>   idea here is that you are getting measurements more quickly, so you
>   might want to adjust the moving average calculation.
> 
> - Running with fine-grained clocks.
>   1.  Should you?
>   2.  Are adjustments to the computations needed?  (Remember delayed
>       ack might tack on 200msec).
> 
> - Always time the RTO from the last packet in flight.
> 
> - Should there be a minimum RTO?
> 
> - Should there be a minimum deviation?

Mark Allman and I are just finishing final copy for a paper to appear in
SIGCOMM '99 that looks in detail at a number of these tradeoffs.  We'll send
an announcement to the list within a couple of days.  The brief version is:

	(1) The moving average coefficients don't matter, so even though
	    you're running a lot more measurements through it with RTTM
	    than previously, that has little effect on the effectiveness of
	    the RTO computation.

	(2) Finer granularity clocks are a win primarily because there's
	    less chance of the deviation being computed as 0 ticks (your
	    last point above).  Below 100 msec you get diminishing benefit
	    as you make the granularity finer.

	(3) You don't really have to worry about things like timing the
	    last packet in flight because RTO has an implicit last-RTT term
	    added into it (because the timer is restarted as new data is
	    sent; pointed out by Reiner Ludwig).

	(4) The #1 biggest effect on how well the estimator performs is its
	    minimum value - there definitely should be a minimum RTO.

- Vern

---

From: Jamshid Mahdavi <[email-masked]>
Date: 20 May 1999 14:28:05 -0700

> 	    than previously, that has little effect on the effectiveness of

Hmmm, I wonder if that statement holds in both senses: does doing all
of the extra measurements also not *improve* the quality of the RTO
computation?  I'd imagine that the key factor here would be transients
such as initial slowstart or path changes.

> 	    sent; pointed out by Reiner Ludwig).

I'm pretty sure that I've seen at least one implementation which
doesn't do this.  To be honest, I was never quite able to figure out
how you could *not* do this.  But the point which I thought was worth
putting in writing somewhere is that you should only take a timeout if
you believe *all* the packets in flight have been dropped.  As opposed
to beleiving that *some* packet in flight was dropped.

> 	    minimum value - there definitely should be a minimum RTO.

Good to hear this.  I've been looking at this on and off for a little
while now and was pretty convinced that there needed to be either a
min RTO or a min deviation.  To my mind, the deviation term makes more
sense to impose a minimum on, because even on long paths I believe you
could still see the occasional spike in delay.

--J

---

From: Rick Jones <[email-masked]>
Date: Thu, 20 May 1999 15:30:29 -0700

> But the point which I thought was worth

Shouldn't that be "if you think enough packets have been dropped such
that you will not trigger fast rtx?" How one divines that is currently
beyond me :)

rick jones
-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 20 May 1999 16:57:45 -0700 (PDT)

> such as initial slowstart or path changes.

In BSD TCP, I'd say taking more measurements does not improve the quality
of RTO computation.  The reason is that the minimum is already 1s.  With
normal terrestrial links, this is usually more than enough to guarantee that
a segment has been lost.  So I guess the question should be asked in the
context of TCP using fine grain timer.

> to beleiving that *some* packet in flight was dropped.

I think this may not be a good idea.  Look at an hypothetical example.  If
TCP used your notion, and a connection just sent a segment out every 0.5
RTO, then the timer would never fire even TCP did not get any acks at all!
From a robustness point of view, I don't think this is a good practise.

> could still see the occasional spike in delay.

I agree with this.  This is what we did in Solaris 7.  We put a minimum on the
deviation.  And that is why I suggest people to set tcp_rexmit_interval_extra
in Solaris 2.6, instead of setting tcp_rexmit_interval_min.  In 2.6, the
smoothed deviation can go too low to be effective at all.  And there is the
200ms delay ack timer which can be triggered after a long run of segments,
when smoothed deviation can be much lower than 200ms.  Thus I suggest the
minimum should be at least 200ms.

							K. Poon.
							[email-masked]