On Aug 23, 2010, at 7:28 AM, Gerrit Renker wrote:
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.
I also doubt that multiple connections would help much for the
wireless problem; the data checksum option is meant to cope with
wireless links, but there it's still not clear what the most
appropriate reaction would be, and how helpful it really is. Some
further research would be needed here.
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.
It seems like you forgot to cc him (but maybe he's on the DCCP list).
What is appealing is that just the TCP equation changes, plus Veno-
like RTT
monitoring.
Yes, that sounds like an interesting combination.
Cheers,
Michael
