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

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

 



On 23 August 2010 15:00, Saverio Mascolo <saverio.mascolo@xxxxxxxxx> wrote:
> what the applications that would need TFRC today? everything seems
> handled by TCP or UDP...

and everything seems handled by Microsoft ... so why looking at new
transport protocols ;)

> On Mon, Aug 23, 2010 at 7:28 AM, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> 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.
>>
>> 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
>>
>
>
>
> --
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4, 70125 Bari Italy
> Tel. +39 080 5963621
> Fax. +39 080 5963410
> email:mascolo@xxxxxxxxx
>
> http://c3lab.poliba.it
>
>
> =================================
>  This message may contain confidential and/or legally privileged information.
>   If you are not the intended recipient of the message, please destroy it.
>  Any unauthorized dissemination, distribution, or copying of the material in
>  this message, and any attachments to the message, is strictly forbidden.
>



-- 
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed"



[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