From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 20BBB21F362 for ; Thu, 23 Apr 2015 07:38:49 -0700 (PDT) Received: by layy10 with SMTP id y10so14251199lay.0 for ; Thu, 23 Apr 2015 07:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ngKclNdhDpQJVXijvOceD4KrzNB5lfKwP86zgDtvXTs=; b=wDpG0MKI+iFSh6m9zStn/yT3hbVNRpogfgbKbVuQRlq4Sh9eZQf7FIwAQIiCnYelEz TYTCkVmUT2ncxWrT7mEQoBUc5DzJun+wzvOE2B9mQCMVw8S0fZhVHeRiBnH1OdVUUO0H Rw7wO3eQ8mKntWMVCzdNkPj3GHLH4d1/OzmpRdsv4H45NIv7Ries7N+RSmO3IRRRBnqq Tpd/mc9JwxRBkOuO96ayU4N2FfxJBfE+td7qagMbLwbkj1NQazlRaJhWtNqQL2ONU09K QxQx8yTH2h5dFyOmVlQpdK5bl+iek+DsBXbo7XXEG/nXOIt2VO7Yr3o6GM1vRJT9bYbc +btA== MIME-Version: 1.0 X-Received: by 10.112.198.136 with SMTP id jc8mr2713028lbc.22.1429799926682; Thu, 23 Apr 2015 07:38:46 -0700 (PDT) Received: by 10.112.202.103 with HTTP; Thu, 23 Apr 2015 07:38:46 -0700 (PDT) Received: by 10.112.202.103 with HTTP; Thu, 23 Apr 2015 07:38:46 -0700 (PDT) In-Reply-To: <1429798255.22254.48.camel@edumazet-glaptop2.roam.corp.google.com> References: <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <20150422040453.GB36239@sesse.net> <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <553882D7.4020301@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> <1429798255.22254.48.camel@edumazet-glaptop2.roam.corp.google.com> Date: Thu, 23 Apr 2015 16:38:46 +0200 Message-ID: From: renaud sallantin To: Eric Dumazet Content-Type: multipart/alternative; boundary=001a11c343eebadb3d0514653cad Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 14:39:20 -0000 --001a11c343eebadb3d0514653cad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 23 avr. 2015 16:10, "Eric Dumazet" a =C3=A9crit= : > > 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? --001a11c343eebadb3d0514653cad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le 23 avr. 2015 16:10, "Eric Dumazet" <eric.dumazet@gmail.com> a =C3=A9crit :
>
> 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<= br> > > during a large IW transmission.
> >
> > Benefits are really outstanding! Our last implementation is just = a
> > slight modification of FQ/pacing
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0* Sallantin, R.; Baudoin, C.; Chaput, E= .; Arnal, F.; Dubois, E.;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Beylot, A.-L., "Initial spr= eading: A fast Start-Up TCP
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism," Local Computer = Networks (LCN), 2013 IEEE 38th
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Conference on , vol., no., pp.49= 2,499, 21-24 Oct. 2013
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0* Sallantin, R.; Baudoin, C.; Chaput, E= .; Arnal, F.; Dubois, E.;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Beylot, A.-L., "A TCP model= for short-lived flows to validate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initial spreading," Local C= omputer Networks (LCN), 2014 IEEE
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A039th Conference on , vol., no., = pp.177,184, 8-11 Sept. 2014
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sallantin-tcpm-initial-spr= eading, 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 w= ere a real need to update it. Results are very good, except when one bottle= neck link is shared by several connections. We demonstrated that an appropr= iate spreading of the IW solves this and improves RFC6928 performance.

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

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

--001a11c343eebadb3d0514653cad--