Re: [Bloat] DSLReports Speed Test has latency measurement built-in

[renaud sallantin <renaud.sallantin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

Le 23 avr. 2015 16:10, "Eric Dumazet" <eric.dumazet@gmail.com> a écrit :
>
> On Thu, 2015-04-23 at 12:17 +0200, renaud sallantin wrote:
> > Hi,
>
> > ...
> >
> > We did an extensive work on the Pacing in slow start and notably
> > during a large IW transmission.
> >
> > Benefits are really outstanding! Our last implementation is just a
> > slight modification of FQ/pacing
> >       * Sallantin, R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.;
> >         Beylot, A.-L., "Initial spreading: A fast Start-Up TCP
> >         mechanism," Local Computer Networks (LCN), 2013 IEEE 38th
> >         Conference on , vol., no., pp.492,499, 21-24 Oct. 2013
> >       * Sallantin, R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.;
> >         Beylot, A.-L., "A TCP model for short-lived flows to validate
> >         initial spreading," Local Computer Networks (LCN), 2014 IEEE
> >         39th Conference on , vol., no., pp.177,184, 8-11 Sept. 2014
> >         draft-sallantin-tcpm-initial-spreading, safe increase of the
TCP's IW
> > Did you consider using it or something similar?
>
>
> Absolutely. We play a lot with these parameters, but the real work is on
> CC front now we have correct host queues and packet scheduler control.
>

Do you really consider that the slow start is efficient?
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.

> Drops are no longer directly correlated to congestion on modern
> networks, cubic has to be replaced.
>
>
>

By curiosity, what is now responsible for the drops if not the congestion?

[-- Attachment #2: Type: text/html, Size: 2288 bytes --]