Lars, - | > It is a chicken-and-egg problem. In its current form, the TFRC implementation buys | > no compelling performance advantage over using UDP. | | Performance will never be the reason for people to chose TFRC or DCCP over UDP | - having congestion control by definition means that there are situations in | which you will loose performance. The reason for choosing TFRC or DCCP will be | the desire for a well-reviewed rate control scheme to avoid having your app | cook up its own home-grown scheme. | I see your point. Application developers perhaps think in a different dimension than network engineers, but if the performance of the scheme in the real world interacts negatively with application performance or leads to a deterioration of perceived performance, the acceptance will be low or not existing. Your point is good, to me it seems however that both requirements (well-reviewed by network engineers and well-reviewed by application developers or actual testers) are necessary. | > There are other problems in using TFRC, the present problem is that the receiver | > often gets the estimated RTT wrong. | | Understood. But would it really matter to you whether you took these fixes to | the TSVWG rather than to the DCCP WG? Not at all. You comments have helped to clarify the situation, thanks a lot indeed.
