[Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic

[Luca De Cicco]

Sorry please disregard the previous message.

LDC


On Thu, Dec 1, 2011 at 12:11 AM, Luca De Cicco <ldecicco at gmail.com> wrote:

> Vedi per esempio questo parla di video transfer.
>
> Luca
>
>
> On Wed, Nov 30, 2011 at 11:00 PM, Yuchung Cheng <ycheng at google.com> wrote:
>
>> It would be nice to see real-world large-scale measurements in addition
>> to modelings. AFAIK, most short Web transactions finish within slow-start,
>> and video transfers over TCP often implement user-level rate limiting.
>>
>> Any good technical papers people recommend?
>>
>> On Wed, Nov 30, 2011 at 1:31 PM, Murari Sridharan <muraris at microsoft.com>wrote:
>>
>>> NIST did a very comprehensive study along these lines comparing and
>>> documenting different congestion algorithms.
>>> http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm
>>>
>>> Thanks
>>> Murari
>>>
>>> -----Original Message-----
>>> From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On
>>> Behalf Of sannikov
>>> Sent: Wednesday, November 30, 2011 6:56 AM
>>> To: Saverio Mascolo
>>> Cc: iccrg; end2end-interest
>>> Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic
>>>
>>> Hello.
>>>
>>> I'm not so familiar with CUBIC, but it is really aggressive.
>>> And as far as I know Linux implementation is little bit differ from the
>>> original.
>>> Did have original version same problems?
>>>
>>> --
>>> With best regards, Alexander Sannikov.
>>>
>>> On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <
>>> saverio.mascolo at gmail.com> wrote:
>>> > yes!
>>> >
>>> > On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl  wrote:
>>> >  This should really go to ICCRG, I'd say (added to recipients). May I
>>> ask
>>> > to continue this (interesting!) discussion there?
>>> >
>>> >  On 11/30/11 12:10 PM, mascolo at poliba.it [2] wrote:
>>> >   Dear all,
>>> >
>>> >  we know that TCP BIC/Cubic is default in Linux and as a consequence
>>> > 50% of servers employs TCP BIC/Cubic.
>>> >
>>> >  Our measurements say that there could be reasons not to deploy TCP
>>> > BIC/Cubic. These reasons  are in our opinion rooted in its more
>>> > aggressive probing phase. In particular, in common network conditions,
>>> > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or
>>> TCP
>>> > Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or
>>> TCP
>>> > Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or
>>> > Westwood+.
>>> >
>>> >  In other terms, it seems that its more aggressive probing increases
>>> both
>>> > throughput and retransmissions but leaving unchanged the goodput. This
>>> is
>>> >  neutral for the users but negative for the network.
>>> >
>>> >  I appreciate your views.
>>> >
>>> >  Thanks for the attention and best regards,
>>> >
>>> >  Saverio Mascolo
>>> >
>>> >  ----------------------------------------------------------------
>>> >  This message was sent using IMP, the Internet Messaging Program.
>>> >
>>> >  _______________________________________________
>>> >  Iccrg mailing list
>>> >  Iccrg at cs.ucl.ac.uk [3]
>>> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4]
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> Iccrg at cs.ucl.ac.uk
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> Iccrg at cs.ucl.ac.uk
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>
>>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111201/a656b099/attachment.html