<p dir="ltr"><br>
Le 23 avr. 2015 16:10, "Eric Dumazet" <<a href="mailto:eric.dumazet@gmail.com">eric.dumazet@gmail.com</a>> a écrit :<br>
><br>
> On Thu, 2015-04-23 at 12:17 +0200, renaud sallantin wrote:<br>
> > Hi,<br>
><br>
> > ...<br>
> ><br>
> > We did an extensive work on the Pacing in slow start and notably<br>
> > during a large IW transmission.<br>
> ><br>
> > Benefits are really outstanding! Our last implementation is just a<br>
> > slight modification of FQ/pacing<br>
> >       * Sallantin, R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.;<br>
> >         Beylot, A.-L., "Initial spreading: A fast Start-Up TCP<br>
> >         mechanism," Local Computer Networks (LCN), 2013 IEEE 38th<br>
> >         Conference on , vol., no., pp.492,499, 21-24 Oct. 2013<br>
> >       * Sallantin, R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.;<br>
> >         Beylot, A.-L., "A TCP model for short-lived flows to validate<br>
> >         initial spreading," Local Computer Networks (LCN), 2014 IEEE<br>
> >         39th Conference on , vol., no., pp.177,184, 8-11 Sept. 2014<br>
> >         draft-sallantin-tcpm-initial-spreading, safe increase of the TCP's IW<br>
> > Did you consider using it or something similar?<br>
><br>
><br>
> Absolutely. We play a lot with these parameters, but the real work is on<br>
> CC front now we have correct host queues and packet scheduler control.<br>
></p>
<p dir="ltr">Do you really consider that the slow start is efficient?<br>
 I may miss something but RFC6928 has been pushed by Google because there were a real need to update it. Results are very good, except when one bottleneck link is shared by several connections. We demonstrated that an appropriate spreading of the IW solves this and improves RFC6928 performance. </p>
<p dir="ltr">> Drops are no longer directly correlated to congestion on modern<br>
> networks, cubic has to be replaced.<br>
><br>
><br>
></p>
<p dir="ltr">By curiosity, what is now responsible for the drops if not the congestion? <br></p>