> Later, Gerrit wrote: > > > It is a chicken-and-egg problem. In its current form, the TFRC > implementation buys no compelling performance advantage over using UDP. > > (let's ignore the word "performance" here, I think it doesn't quite fit - > but it's about the compelling advantage, i.e. reason to use it) > > THIS is EXACTLY what we want to achieve with MulTFRC: > http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html > > I think that we need things like these, that give the potential users of > DCCP some sort of "service", i.e. some reason to use the protocol. That is why I have suggested a separate thread for the other issues. One of these is that wireless performance of TFRC is really very bad and I have doubts whether multiple parallel TFRC connections can solve this problem.
But perhaps the underlying ideas; IMHO the most promising approach for WiFi TFRC is TFRC Veno. I am cc:-ing Leandro who has done some work with TCP Veno. What is appealing is that just the TCP equation changes, plus Veno-like RTT monitoring. Gerrit
