Michael -
On Dec 19, 2007, at 9:00 AM, Michael Welzl wrote:
Hi all,
I'm confused by the idea of setting RTO=4*RTT in TFRC.
From RFC 3448:
--
We further simplify this by setting t_RTO = 4*R. A more accurate
calculation of t_RTO is possible, but experiments with the current
setting have resulted in reasonable fairness with existing TCP
implementations [9].
--
(where [9] is Joerg Widmer's master thesis).
I'd like to understand where the number 4 comes from. Was that
just a magic number that worked well in Joerg's tests?
If we apply the same intuition (whatever it was) that led to
the choice of RTT/2 as an initial value for RTTVAR in RFC 2988
and forget about the EWMA processes for a minute, it would seem
reasonable to set RTO to RTT + 4 * RTT/2 = 3*RTT instead...
The RTO for TCP, from RFC 2988, is:
SRTT + 4*RTTVAR.
I don't remember that any particular measurement studies were used
to get TFRC's rough estimate of 4*RTT for the RTO. If one wanted
to look for something more precise, one could look at
measurements of the range of values of RTTVAR in real-world
connections, and then taking a conservative estimate.
(I don't know off-hand of the worst-case possible value for RTTVAR,
if there is one.)
I think that setting RTO to 3*RTT would be fine, and I think that
setting
RTO to 4*RTT is also fine.
Given that TFRC doesn't compute RTTVAR directly (in order to reduce
the computational load), I think it is a good idea for TFRC to use
a *conservative* estimate of RTO, so that TFRC doesn't have
a sending rate that is too high in highly congested environments.
(In times of low congestion, with a low loss event rate, the RTO
term doesn't have much effect on TFRC's sending rate one way or
another.)
Also, I wonder how people apply the equation in other settings -
is it a common thing to set RTO to 4*RTT when using it, or
is this specific to TFRC?
I don't know off-hand of any other places where it is used.
- Sally
http://www.icir.org/floyd/
