Hi, Thanks a lot for answering my question! This has been a confusion for me for quite some time now... > > 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 should have been more explicit about the reason for 3*RTT, sorry. According to RFC 2988, the initial value for SRTT is R and the initial value for RTTVAR is R/2 (where R is the first RTT measurement). I also don't know why it's R/2, but probably that value doesn't make a huge difference after a few updates... Anyway, if the same intuition that led to the choice of R/2 would have been applied for setting RTO in TFRC, it seems to me that the choice should have been SRTT + 4*RTTVAR = R + 4*R/2 = 3*R. That's what I meant. > 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. So it's a somewhat arbitrary choice; well, I just wanted to know the reason for choosing this value - so thanks a lot for this clarification! > 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. Thanks again! Cheers, Michael PS: again, from my previous email - this is still off-topic for DCCP, but still unanswered (and I'll move the question to RMT in a few days if nobody reacts): why was RTO replaced with 4 instead of 4*RTT in TFMCC?
