Re: New I-D revision: TFRC with sender-RTT estimate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux