Sorry please disregard the previous message.<div><br></div><div>LDC<br>
<br><br><div class="gmail_quote">On Thu, Dec 1, 2011 at 12:11 AM, Luca De Cicco <span dir="ltr"><<a href="mailto:ldecicco@gmail.com">ldecicco@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Vedi per esempio questo parla di video transfer.<span class="HOEnZb"><font color="#888888"><br>
<br>Luca</font></span><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Wed, Nov 30, 2011 at 11:00 PM, Yuchung Cheng <span dir="ltr"><<a href="mailto:ycheng@google.com" target="_blank">ycheng@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<div>
<br></div><div>Any good technical papers people recommend?</div><div><div><div><br></div><div><div class="gmail_quote">On Wed, Nov 30, 2011 at 1:31 PM, Murari Sridharan <span dir="ltr"><<a href="mailto:muraris@microsoft.com" target="_blank">muraris@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">NIST did a very comprehensive study along these lines comparing and documenting different congestion algorithms.<br>
<a href="http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm" target="_blank">http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm</a><br>
<br>
Thanks<br>
<span><font color="#888888">Murari<br>
</font></span><div><div><br>
-----Original Message-----<br>
From: <a href="mailto:iccrg-bounces@cs.ucl.ac.uk" target="_blank">iccrg-bounces@cs.ucl.ac.uk</a> [mailto:<a href="mailto:iccrg-bounces@cs.ucl.ac.uk" target="_blank">iccrg-bounces@cs.ucl.ac.uk</a>] On Behalf Of sannikov<br>
Sent: Wednesday, November 30, 2011 6:56 AM<br>
To: Saverio Mascolo<br>
Cc: iccrg; end2end-interest<br>
Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic<br>
<br>
Hello.<br>
<br>
I'm not so familiar with CUBIC, but it is really aggressive.<br>
And as far as I know Linux implementation is little bit differ from the original.<br>
Did have original version same problems?<br>
<br>
--<br>
With best regards, Alexander Sannikov.<br>
<br>
On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo <<a href="mailto:saverio.mascolo@gmail.com" target="_blank">saverio.mascolo@gmail.com</a>> wrote:<br>
> yes!<br>
><br>
> On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl wrote:<br>
> This should really go to ICCRG, I'd say (added to recipients). May I<br>
ask<br>
> to continue this (interesting!) discussion there?<br>
><br>
> On 11/30/11 12:10 PM, <a href="mailto:mascolo@poliba.it" target="_blank">mascolo@poliba.it</a> [2] wrote:<br>
> Dear all,<br>
><br>
> we know that TCP BIC/Cubic is default in Linux and as a consequence<br>
> 50% of servers employs TCP BIC/Cubic.<br>
><br>
> Our measurements say that there could be reasons not to deploy TCP<br>
> BIC/Cubic. These reasons are in our opinion rooted in its more<br>
> aggressive probing phase. In particular, in common network conditions,<br>
> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or<br>
TCP<br>
> Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or<br>
TCP<br>
> Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or<br>
> Westwood+.<br>
><br>
> In other terms, it seems that its more aggressive probing increases<br>
both<br>
> throughput and retransmissions but leaving unchanged the goodput. This<br>
is<br>
> neutral for the users but negative for the network.<br>
><br>
> I appreciate your views.<br>
><br>
> Thanks for the attention and best regards,<br>
><br>
> Saverio Mascolo<br>
><br>
> ----------------------------------------------------------------<br>
> This message was sent using IMP, the Internet Messaging Program.<br>
><br>
> _______________________________________________<br>
> Iccrg mailing list<br>
> <a href="mailto:Iccrg@cs.ucl.ac.uk" target="_blank">Iccrg@cs.ucl.ac.uk</a> [3]<br>
> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a> [4]<br>
<br>
_______________________________________________<br>
Iccrg mailing list<br>
<a href="mailto:Iccrg@cs.ucl.ac.uk" target="_blank">Iccrg@cs.ucl.ac.uk</a><br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br>
<br>
</div></div><br>_______________________________________________<br>
Iccrg mailing list<br>
<a href="mailto:Iccrg@cs.ucl.ac.uk" target="_blank">Iccrg@cs.ucl.ac.uk</a><br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Iccrg mailing list<br>
<a href="mailto:Iccrg@cs.ucl.ac.uk" target="_blank">Iccrg@cs.ucl.ac.uk</a><br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br></div>