From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by lists.bufferbloat.net (Postfix) with ESMTPS id 312C73ED5E for ; Wed, 23 Dec 2015 05:01:51 -0500 (EST) Received: from hms-beagle.home.lan ([217.247.221.45]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqALY-1agbDH1aro-00dksV; Wed, 23 Dec 2015 11:01:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <03C8DFA1-4BA1-491C-96F9-F67F87A2EFBB@gmail.com> Date: Wed, 23 Dec 2015 11:01:45 +0100 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <57200484-FC7E-4DD9-9BE0-8278515FB70F@gmx.de> References: <03C8DFA1-4BA1-491C-96F9-F67F87A2EFBB@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:7SS3J8uP0R22lBUC9ApNAEhG10T7StF0bJLMv6Q9YZwx6AXOsE+ mfWlrLgVd7nYNZqNFCHAfZthBZ76k+enrSUVJtgslRI11GfJoPTRyO4Rb6PuUjhdBBo4stj GcYVbAl0ccD4Z2nvFGxnLnJQb/96pyyqU4jheHBm8PNmzFNRlL+/GkB+diWp4lxgFrCK7+n Kue97SqE7L51cnmT0+voA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Yc1kcOO4dEo=:C7mfPLVQEB9Xgljga6eQ2X UJQK7tFqYIZgBoyhraA0irk5TmHkpCrgKklEIYc9G9sUWvSomk3NddqPuPZTbMQ9o8rVH/FBX PnE2Sm2W9wG1yqjGhFthD4QYYvDEXWJY/mG6pm1zsb7RtAziLIkwAN5SnPJFqlHzHOhEQtbbW eAdejnUuoZbnyoVauGSEtfQGbD+fVDnpknwgjhYZ2wtfCw4Woyda850zf42p6NY3rrJyxfIJ8 XtTdrM1O03JjGJ2OYWN5L4Yq/gbxKYd3jQQkwvfI50eEsP3vruIQT/932dQj71XIX/0xY9++O suaHr0EXL3dCV3yUXC/wOFsLtknfYDZZnZYzK6bBxw+A4ZuWPxucclM3oW+YC16nLn/JbsYnf B7nsGSGzpk2bS1Svs+3wCFOj35iljwwxkaWTLOIN1uk6LKMZ2siUrC5T8BVCK1NAV8Qsfg/rh feZldzIqiPijoYu/lCetZYJeiLCYp043pKOzLoVCfWs4jgRzUG+CWTZhdD7U0yvtaPDl78g6Z 28ui26roEQPfl5kNT/mdBby9ucvGi+KkvUmaqP6wQNEWD4VQT/YpsdSpNFZjQpq1xOjHSKN9D 7G0nMNWUcZtPnU50vlufOXKnX7XEdrmKVHwacwScu5+Az8eVHag4//bxLKROvjWqkK7YYBWaA f7J39c9GqDdJxdHIJ/3aExekeYjcZHVHV6e56OOShRbBz0rHmflwS7D2qk4Ive/fg1gGDV8E9 GhOhtnuIZGWJm2NLdl79n1ts/dSXqzRrDIS5lmMSsGJIl4+tfxaBBZfdk/n+7yzsWYYzsrFLJ hZTOcOk Subject: Re: [Cake] Christmas Cake X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 10:01:51 -0000 Hi Jonathan, > On Dec 23, 2015, at 07:28 , Jonathan Morton = wrote: >=20 > With spectacularly good timing, I=E2=80=99ve finally worked out the = last kinks of how to make the triple-solation scheme work in practice. = Or at least I hope I have - it still needs concrete testing. At least = my PowerBook didn=E2=80=99t blow up when I started running it, so it=E2=80= =99s probably safe to deploy straight away. >=20 > So that=E2=80=99s the big update I put in last night. >=20 > I also made a couple of small but significant tweaks to the Codel = implementation, bringing it closer to the published ideal behaviour. = This seems to have improved my own connection under heavy ingress load, = so it=E2=80=99s probably on the right track. >=20 > It no longer attempts to vary the trigger point based on queue growth = speed, but it *will* now trigger instantly if an entire interval=E2=80=99s= worth of traffic arrives in one queue all at once. The = inverse-square-root calculation is also now performed to 32-bit = precision, matching the range of the count variable and possibly saving = some instructions in the process. >=20 > I=E2=80=99d like to see the results of testing the new = =E2=80=9Ctriple-isolation=E2=80=9D flag. It should pass all tests = involving one host-pair just as well as =E2=80=9Cflows=E2=80=9D does. = Additionally, it should share bandwidth fairly between multiple hosts on = either side of the link, regardless of any imbalance in the number of = flows involved. For example, one flow between A and B, two flows = between C and D, where both paths pass through the same Cake instance, = should result in each of C-D=E2=80=99s flows receiving half the = throughput of the A-B one. Interesting, now I have a question (since reading the code only gets my = that far), the typical scenario people want is basically to enforce per = source host fairness on egress and per destination-host fairness on = ingress, because in a torrent swarm as far as I can see there will not = be multiple flows between internal_C and external_D, but rather between = internal_C and external_ALPHABET. And the stated goal often seems to be = fairness per internal host address. (In your description it is unclear = what happens if internal C started also talking to external E, will this = increase C=E2=80=99s share of bandwidth or not and what will be the = bandwidth ratio of C2E as compared to the C2D aggregate?) Which of the three options will handle that well dual-X or triple-iso? Best Regards M. >=20 > Merry Christmas... >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake