From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound02.roaringpenguin.co.uk (outbound02.roaringpenguin.co.uk [109.69.238.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1CC243B2A4 for ; Thu, 30 Nov 2017 07:31:23 -0500 (EST) Received: from relay.smtp.pnsol.com (ec2-54-246-165-192.eu-west-1.compute.amazonaws.com [54.246.165.192]) by outbound02.roaringpenguin.co.uk (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAUCVIO7014511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Nov 2017 12:31:19 GMT Received: from mail.la.pnsol.com ([172.20.5.206]) by relay.smtp.pnsol.com with esmtp (Exim 4.82) (envelope-from ) id 1eKNzb-0000Hj-Ka; Thu, 30 Nov 2017 12:31:03 +0000 Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1eKNzY-00027r-Vd; Thu, 30 Nov 2017 12:31:00 +0000 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1eKNzY-0000yC-Pn; Thu, 30 Nov 2017 12:31:00 +0000 Content-Type: multipart/signed; boundary="Apple-Mail=_51059F3D-617D-4F0F-8208-EF26435C58A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Neil Davies X-Mailbutler-Link-Tracking-Uuid: In-Reply-To: Date: Thu, 30 Nov 2017 12:31:04 +0000 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , bloat Message-Id: <57A2696A-F95C-4EEC-95B7-45EC4C2ADA55@pnsol.com> References: <87shd18c51.fsf@toke.dk> <874lpe8y2f.fsf@toke.dk> To: Jonathan Morton X-Mailer: Apple Mail (2.3273) X-Spam-Score: undef - relay 54.246.165.192 marked with skip_spam_scan X-CanIt-Geo: ip=54.246.165.192; country=IE; region=Leinster; city=Dublin; latitude=53.3389; longitude=-6.2595; http://maps.google.com/maps?q=53.3389,-6.2595&z=6 X-CanItPRO-Stream: pnsol-com:outbound (inherits from pnsol-com:default, PredictableNetworkSolutions:default, Wholesale:default, CTL:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-CanIt-Archive-Cluster: Rl4fxI1RVOq/TTUYGiKHQwqlXy8 X-CanIt-Archived-As: pnsol-com/20171130 / 06UEcvjjm X-Scanned-By: CanIt (www . roaringpenguin . com) on 109.69.238.89 Subject: Re: [Bloat] Bufferbloat in high resolution + non-stationarity X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 12:31:24 -0000 --Apple-Mail=_51059F3D-617D-4F0F-8208-EF26435C58A0 Content-Type: multipart/alternative; boundary="Apple-Mail=_528BDCA3-DB00-4829-9AD8-767627567267" --Apple-Mail=_528BDCA3-DB00-4829-9AD8-767627567267 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The key design goal was to create assured bounds on loss and delay for = designated classes during extended periods of load saturation. The mechanisms, to some extent, are not the issue - the ability = configure it and know a-prori (to a given error bound) what would happen = to the traffic flows was our primary goal. The key point we found as we did this work is (as you remark below) that = current systems don=E2=80=99t mange the two degrees of freedom that is = present in every queueing system, whereas this one does. As anyone who = has done any control theory will tell you that is the first essential = step to being able control. We note that what queueing mechanisms do (with respect to = application=E2=80=99s performance outcomes) is share the delay and loss = (which occurs when the queueing system is non-empty) between the flows = that are in competition at the moment in time - this is what this = mechanism does. If you want a larger evaluation, including what needs to be done when = transmission capacity changes (as in 3G/4G/5G etc) take a look at = http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf = - it is a much = richer scenario and provides some strong motivation for why just = managing to bandwidth (and speed) is probably not the right goal for = many emerging use cases. Cheers Neil > On 28 Nov 2017, at 16:16, Jonathan Morton = wrote: >=20 > I read the paper just now, and skimmed through the thesis to determine = that it was talking about the same thing using an order of magnitude = more space. >=20 > It boils down to a Diffserv implementation using a classifier (details = handwaved as usual), policers, shapers, and a strict-priority = tail-dropping queue. The only noteworthy feature is that the position = of the queue's tail depends on the "cherish" metric of each traffic = class, which is used to provide differentiation in loss, leaving the = strict-priority mechanism to provide "urgency" (delay) differentiation. >=20 > =46rom the above, you might reasonably conclude that I'm not very = impressed. >=20 > The paper includes a test scenario versus a plain FIFO and a DRR = system. The DRR was weighted with a-priori knowledge of the relative = traffic volumes, which in fact would have degraded its performance in = delay management. A DRR++ implementation *without* such knowledge would = have outperformed it substantially. >=20 > Toke, reproducing that test load and running it through an unmodified = Cake instance would perhaps be enlightening. >=20 > - Jonathan Morton >=20 > Spam = > Not spam = > Forget previous vote = > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_528BDCA3-DB00-4829-9AD8-767627567267 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The key design goal was to create assured bounds on loss and = delay for designated classes during extended periods of load = saturation. 

The = mechanisms, to some extent, are not the issue - the ability configure it = and know a-prori (to a given error bound) what would happen to the = traffic flows was our primary goal.

The key point we found as we did this = work is (as you remark below) that current systems don=E2=80=99t mange = the two degrees of freedom that is present in every queueing system, = whereas this one does. As anyone who has done any control theory will = tell you that is the first essential step to being able = control. 

We note that what queueing mechanisms do (with respect to = application=E2=80=99s performance outcomes) is share the delay and loss = (which occurs when the queueing system is non-empty) between the flows = that are in competition at the moment in time - this is what this = mechanism does. 

If you want a larger evaluation, including what needs to be = done when transmission capacity changes (as in 3G/4G/5G etc) take a look = at http://www.pnsol.com/public/TP-PNS-CS-2005-11.pdf - = it is a much richer scenario and provides some strong motivation for why = just managing to bandwidth (and speed) is probably not the right goal = for many emerging use cases.

Cheers

Neil
On = 28 Nov 2017, at 16:16, Jonathan Morton <chromatix99@gmail.com> wrote:

I read the paper just now, and skimmed through the thesis to = determine that it was talking about the same thing using an order of = magnitude more space.

It boils down to a = Diffserv implementation using a classifier (details handwaved as usual), = policers, shapers, and a strict-priority tail-dropping queue.  The = only noteworthy feature is that the position of the queue's tail depends = on the "cherish" metric of each traffic class, which is used to provide = differentiation in loss, leaving the strict-priority mechanism to = provide "urgency" (delay) differentiation.

=46rom the above, you might reasonably conclude that I'm not = very impressed.

The paper includes a test = scenario versus a plain FIFO and a DRR system.  The DRR was = weighted with a-priori knowledge of the relative traffic volumes, which = in fact would have degraded its performance in delay management.  A = DRR++ implementation *without* such knowledge would have outperformed it = substantially.

Toke, reproducing that test = load and running it through an unmodified Cake instance would perhaps be = enlightening.

- Jonathan Morton


Spam
Not spam
Forget previous vote
_______________________________________________
Bloat = mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

= --Apple-Mail=_528BDCA3-DB00-4829-9AD8-767627567267-- --Apple-Mail=_51059F3D-617D-4F0F-8208-EF26435C58A0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaH/oJAAoJEPmpMHCy/udqZkoQAKbCYuoL6kiMDJyYjeMWlE+z pYsz6tV20jPEHtFdlh9A2Zs+FVtYZF2s3kzAQ+ucazqdIpnercGEVajqG/p9+CKC /ZJSoWiv8NSjk2Dr3+f/tk22fQqJ6IN/hS5mxV0knW493Wo8GnsTydhPzeke+6a+ 5yregO4BZIMOJ7x/PNrkYgyV5QTGo4pxINZOTrq+fG+NVXZ3P9hIiAqTV6L6vZ7x 8ifVqUZ8ZhnXQEgfDpdQRPtDzqGohCsTV5I7sBGdFDxObBB/3y2wqldFy802waQ6 +3BSguL43CIlrZFTlrg2Exx5f2rR2S0S0HCnEBC5DCXvDAkoclWAK1PfxrM2iZNT w81CVL9VrZyRr71bcOJtdmr3uGK7a1/sP5x7PKPJeYkmOcBYTq1BZv7xet1kqPXc AvkQPWShvUXRhimcZg652FNS4JrGk+kFMoTw+mLUYL7ALu7cBIDizlaIsokrFPtd GkDDlkz9okEFG87+jopaNqC9bhi/4djBXVAL4n7S7PDc7qjDkKAZg8Na+S9OO4u7 4SRcCjxI2igtGGjBq2VIQtnRlzD0drxA212waHdmGMD2rIyKqMT9p9fDCKMc075U OZx4JZA0e8hZvVF9CmsSbAIeO8TQBE6gZ4zmHTDzt3kyvskvcjyFMlMxeedaw4eo pNPzVBRKYZQqH+C+3aST =Uo04 -----END PGP SIGNATURE----- --Apple-Mail=_51059F3D-617D-4F0F-8208-EF26435C58A0--