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

[Luca De Cicco]

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/3eb81894/attachment-0001.html