TFRC and TFMCC co-evolved. The original motivation to be equation-based was multicast, but then we realised it was well suited to multimedia, and hence TFRC branched off the multicast work. If you look at the original TFRC Sigcomm paper, we discuss the use of t_RTO = 4 RTT for unicast usage, but the idea originally came from multicast constraints. With multicast, there is no way to measure the RTT variance (you'd get a feedback implosion if you tried). You could measure the one-way variance, but this wouldn't tell you too much about what a competing TCP would see, so whatever you do with multicast you cannot accurately measure what a TCP would get for t_RTO. But then we realized that different TCP implementations themselves get orders of magnitude different results for t_RTO when they co-exist along the same path: some implement the 1 second minimum, some do not; some have fine-grain timers, some do not. There wasn't any reasonable TCP that would should try and be equivalent to. But of course this only matters when the loss rate is very high - otherwise the term including t_RTO is not significant. So we went with a rough approximation - t_RTO = 4 RTT is an attempt to make a fairly conservative estimate that would land somewhere in the middle of the large range of behaviours regular TCPs implement, and stems from the inability to measure RTT variance in multicast. For TFRC, if you can measure the variance you can more accurately implement a particular variant of the TCP t_RTO algorithm (But which variant? I don't think there's consensus on the right thing for TCP). Anyway our experience at the time showed that the approximation seemed OK. But if experience since then shows otherwise, it could be changed - it's certainly not set in stone. - Mark On Dec 27, 2007 1:05 AM, Sally Floyd <sallyfloyd@xxxxxxx> wrote: > > 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? > > I am not a co-author of TFMCC, so I don't know all of the > design decisons. > > The response function in RFC3448 (TFRC) is as follows: > > s > X = ---------------------------------------------------------- > R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) > > By using b=1 and t_RTO=4 RTT, you get the following: > > s > X = ---------------------------------------------------------- > R*(sqrt(2*p/3) + (12 *(sqrt(3*p/8) * p * (1+32*p^2)))) > > (Note the parentheses after R in the denominator.) > > > The response function in TFMCC is as follows: > > 8 s > X = --------------------------------------------------------- > (1) > R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2))) > > This looks to me the same as the response function for TFRC, > with b=1 and t_RTO = 4 RTT, but mutliplied by a factor 8. > > (Given that X is the transmit rate in bytes per second, I don't > see why the factor of 8 is ok. But it does use t_RTO = 4 RTT.) > > - Sally > http://www.icir.org/floyd/ > > >
