From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 1D51621F1A0 for ; Thu, 23 Apr 2015 03:18:01 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so9605392lbb.3 for ; Thu, 23 Apr 2015 03:17:59 -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=/tUymTAYQKwb+38CaD3/eBmjo6qKleo1MeuFN0RFv8Q=; b=G8McrVy7j+aBB0PTghGFIaegQKYBrtRGVDzcDGwJdAGdlC9xVZOhXHHwayApCPYEOv V//DYlw/vcgPDBi9O/ysRg5sOBDLLmSRUQhQai63yTBxCCO9k5PD6KK5sWYeQLu3jnMO rNgaidAA9K1LYsz786vxkRPEXmiXGAuzD2twhljLu0AjCIjC4bsAjc6nyhtp6zKdWlrw Z07S1RmPs/A/zhTcJRNCEunRtKtZaOKEQhJQmzGq3n4IkR2k1OliF6iLu65NhaerhHkF 5sF6+J5ATSgbwr/SrUIguxR/Sra0Jt4JYiYTjCKI8PkTxuqtfU7qeoQCMyv66+WG0WSM 1Vsw== MIME-Version: 1.0 X-Received: by 10.112.205.225 with SMTP id lj1mr1786208lbc.27.1429784279715; Thu, 23 Apr 2015 03:17:59 -0700 (PDT) Received: by 10.112.202.103 with HTTP; Thu, 23 Apr 2015 03:17:59 -0700 (PDT) In-Reply-To: <1429771718.22254.32.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> Date: Thu, 23 Apr 2015 12:17:59 +0200 Message-ID: From: renaud sallantin To: Eric Dumazet Content-Type: multipart/alternative; boundary=001a11c3ce14191693051461980e 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 10:18:30 -0000 --001a11c3ce14191693051461980e Content-Type: text/plain; charset=UTF-8 Hi, 2015-04-23 8:48 GMT+02:00 Eric Dumazet : > Wait, this is a 15 years old experiment using Reno and a single test > bed, using ns simulator. > > Naive TCP pacing implementations were tried, and probably failed. > > Pacing individual packet is quite bad, this is the first lesson one > learns when implementing TCP pacing, especially if you try to drive a > 40Gbps NIC. > > https://lwn.net/Articles/564978/ > > Also note we use usec based rtt samples, and nanosec high resolution > timers in fq. I suspect the ns simulator experiment had sync issues > because of using low resolution timers or simulation artifact, without > any jitter source. > > Billions of flows are now 'paced', but keep in mind most packets are not > paced. We do not pace in slow start, and we do not pace when tcp is ACK > clocked. > 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? > > Only when someones sets SO_MAX_PACING_RATE below the TCP rate, we can > eventually have all packets being paced, using TSO 'clusters' for TCP. > > > > On Thu, 2015-04-23 at 07:27 +0200, MUSCARIELLO Luca IMT/OLN wrote: > > one reference with pdf publicly available. On the website there are > > various papers > > on this topic. Others might me more relevant but I did not check all of > > them. > > > Understanding the Performance of TCP Pacing, > > Amit Aggarwal, Stefan Savage, and Tom Anderson, > > IEEE INFOCOM 2000 Tel-Aviv, Israel, March 2000, pages 1157-1165. > > > > http://www.cs.ucsd.edu/~savage/papers/Infocom2000pacing.pdf > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a11c3ce14191693051461980e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

2015-04-23 8:48 GMT+02:00 Eric Dumazet <<= a href=3D"mailto:eric.dumazet@gmail.com" target=3D"_blank">eric.dumazet@gma= il.com>:
Wait, this is a 15 years old experiment using Reno and a single test
bed, using ns simulator.

Naive TCP pacing implementations were tried, and probably failed.

Pacing individual packet is quite bad, this is the first lesson one
learns when implementing TCP pacing, especially if you try to drive a
40Gbps NIC.

https://lwn.= net/Articles/564978/

Also note we use usec based rtt samples, and nanosec high resolution
timers in fq. I suspect the ns simulator experiment had sync issues
because of using low resolution timers or simulation artifact, without
any jitter source.

Billions of flows are now 'paced', but keep in mind most packets ar= e not
paced. We do not pace in slow start, and we do not pace when tcp is ACK
clocked.

We did an extensive work on th= e Pacing in slow start and notably during a large IW transmission.
Benefits are really outstanding! Our last implementation is just a s= light modification of FQ/pacing
  • Sallantin, R.; Baudoin, C.; Cha= put, E.; Arnal, F.; Dubois, E.; Beylot,=20 A.-L., "Initial spreading: A fast Start-Up TCP mechanism," Loc= al Computer Networks (LCN), 2013 IEEE 38th Conference on , vol., no., p= p.492,499, 21-24 Oct. 2013
  • Sallantin, R.; Baudoin, C.; Cha= put, E.; Arnal, F.; Dubois, E.; Beylot,=20 A.-L., "A TCP model for short-lived flows to validate initial=20 spreading," Local Computer Networks (LCN), 2014 IEEE 39th Conferenc= e on , vol., no., pp.177,184, 8-11 Sept. 2014
  • draft-sallantin-tcpm-in=
itial-spreading, safe increase of the TCP's IW
Did you consider using it or something similar?=20
=C2=A0

Only when someones sets SO_MAX_PACING_RATE below the TCP rate, we can
eventually have all packets being paced, using TSO 'clusters' for T= CP.



On Thu, 2015-04-23 at 07:27 +0200, MUSCARIELLO Luca IMT/OLN wrote:
> one reference with pdf publicly available. On the website there are > various papers
> on this topic. Others might me more relevant but I did not check all o= f
> them.

> Understanding the Performance of TCP Pacing,
> Amit Aggarwal, Stefan Savage, and Tom Anderson,
> IEEE INFOCOM 2000 Tel-Aviv, Israel, March 2000, pages 1157-1165.
>
> http://www.cs.ucsd.edu/~savage/papers/Infocom2000pacing= .pdf


__________________________________= _____________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--001a11c3ce14191693051461980e--