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

[Yuchung Cheng]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20111130/0cc0d1c4/attachment.html