Subject: Re: Retransmissions without explanation

From: Jamshid Mahdavi <[email-masked]>
Date: 19 May 1999 09:14:39 -0700

[This is in response to a note on tcpsat about retransmit timers
firing too early on long connections.]

I have seen unwanted retransmit timouts (i.e. bugs) of this nature in
two other implementations as well.  All of these implementations have
in common more accurate timers.  I suspect it would be useful to have
more detailed documentation on the use of timers and computation of
RTO.  However, it isn't clear to me that there is a lot of consensus
on a number of the issues.

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?

Interestingly, I see no discussion of these issues in the TCPSAT
drafts, and I don't believe I have seen them covered in any of the
other relevant places either (i.e. pilc or tcl-impl).

I'd be happy to pull together ideas on this subject if people are
interested in seeing such a document.

--Jamshid

PS.  On a process note, I'm thinking this belongs under tcp-impl, so
I've sent this note to tcp-impl and BCC'd tcpsat (where the
conversation started).

---

From: "Umesh Mallugari" <[email-masked]>
Date: Thu, 20 May 1999 14:07:09 +0530

Yes, Jamshid, this is a practical issue that has been out of thought
for a long time.

I think the following points you mentioned are related.
> - Always time the RTO from the last packet in flight.

And, I vote for the idea that adjustment/computation should be based on 
the last packet in flight because it is more related to the  current
network
conditions.
At the same time, there should be a minimum. So, the following points are
also worth the thought.
> - Should there be a minimum deviation?
However, attention to speed must be kept in mind while implementing these.

-Umesh.

----------
> From: Jamshid Mahdavi <[email-masked]>
> To: [email-masked]
> Subject: Re: Retransmissions without explanation
> Date: Wednesday, May 19, 1999 9:44 PM
> 
>

---

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

> 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?

The surprising answer is No.  In a nutshell, the reason is that there's no
good RTO setting (no real sweet spot) - you're always trading off waiting
longer vs. retransmitting unnecessarily.  Related to this, another surprising
finding is that an RTO timer that "adapts" by just using the first RTT
measurement of a connection often does almost as well as those that attempt
to track the RTT evolution.  (Of course, in some circumstances that estimator
will be disastrous.)

But perhaps further discussion should be deferred until we put the paper
on-line, which should be sometime tomorrow.

		Vern

---

From: Mark Allman <[email-masked]>
Date: Fri, 21 May 1999 14:16:13 -0400

As Vern mentioned yesterday, we have recently put together a paper
that may be of interest to folks on this list.  The abstract and a
pointer to the paper are attached below.  Please let us know if you
have any comments!

allman

---
Mark Allman, Vern Paxson.  On Estimating End-to-End Network Path
Properties.  ACM SIGCOMM, September 1999.  To appear. 

The more information about current network conditions available to a
transport protocol, the more efficiently it can use the network to
transfer its data.  In networks such as the Internet, the transport
protocol must often form its own estimates of network properties
based on measurements performed by the connection endpoints.  We
consider two basic transport estimation problems: determining the
setting of the retransmission timer (RTO) for a reliable protocol,
and estimating the bandwidth available to a connection as it begins.
We look at both of these problems in the context of TCP, using a
large TCP measurement set [Pax97b] for trace-driven simulations.
For RTO estimation, we evaluate a number of different algorithms,
finding that the performance of the estimators is dominated by their
minimum values, and to a lesser extent, the timer granularity, while
being virtually unaffected by how often round-trip time measurements
are made or the settings of the parameters in the
exponentially-weighted moving average estimators commonly used.  For
bandwidth estimation, we explore techniques previously sketched in
the literature [Hoe96,AD98] and find that in practice they perform
less well than anticipated.  We then develop a receiver-side
algorithm that performs significantly better.

---

From: Mark Allman <[email-masked]>
Date: Fri, 21 May 1999 14:24:24 -0400

Sorry for the extra mail...  I forgot to include a pointer to the
paper...

> Properties.  ACM SIGCOMM, September 1999.  To appear. 

http://roland.grc.nasa.gov/~mallman/papers/estimation.ps

allman