From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by lists.bufferbloat.net (Postfix) with ESMTPS id 9A6903ED89 for ; Wed, 23 Dec 2015 05:31:32 -0500 (EST) Received: from hms-beagle.home.lan ([217.247.221.45]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcBPV-1adZPY2TDR-00jXbU; Wed, 23 Dec 2015 11:31:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <57200484-FC7E-4DD9-9BE0-8278515FB70F@gmx.de> Date: Wed, 23 Dec 2015 11:31:27 +0100 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <53905DAE-AEBB-42BA-9B87-2E58222D05EB@gmx.de> References: <03C8DFA1-4BA1-491C-96F9-F67F87A2EFBB@gmail.com> <57200484-FC7E-4DD9-9BE0-8278515FB70F@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:OqmLGuWgJmUrim66hfbE7VovXLT2cCwRJsRJTk9OhuIyVA5ms3W djySjFisM5PULYmaFwl8ZNpF4RIQrHakxusdg6NqgnZiH8JroyVuiB0IAm2BDknc/W9KXps 2czkQ8x6dNx0FR/xTdAQbBSFrGGADcBHcxbRFmJz27tkK5XXs/LPCFtme++bAbsRq+DuyvW joqgM8NK0DgAD8P8z53FQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Zx3oNCDb8M0=:sx2g9jfIQ4q50i6XYHCbmC xHOQ/xNces2JEV31a1yPS0okeFJOiFYNcpm1AHuXXGhUnLgQspuS0eYM6ddMvcDThzwXAxPax PGOyx9u03GtXrlzJs58da1QpgQ+kjCz4+md3cQeF1QUwEyFJsq7BAwWJH1T11wrCkmjzIIpMu 33RUBA8n6pfEHBzDT1FBQ9T62c85jquRIehNk9HHeq+KjPlljwYDYZns0pYkDhikiR/BbueRs 0qjDpRgLxaWCnq8WzATvYwL/XaJjA2wBJuCiuV1eJUytpHhjjcW3U529X1vTcauANXDz2f6ZK LjmrgzvGrs+mo8Xu9LqxDJBi9EcPHiJtdZuwP2J/rM1NlDlzlWAr1mOt+j0/zk8schrE21M1T tLJtBW29+fYPqcK/VkCjpQKVy6/Uh67C1ONK0ItQOed97MxYiyh8cT/MreJ8OZa8iJjj6pDeI eF2/kyM9MgwdvC0qcwUk4c8GtQA8eEBV5gBEj2N5d8v8SvskmQCvtMYkbgGc5HTRDMq7HPdox T3GbgdHgmzMPkTBAJ29gSx5f6VkVI/3bdDPODpSbQkg1frlkKLboleHiY4jHEmPJRBUXdHfbW MSLtakZO1E+5/kxRiPU5vaaXmzvaAYwVvJFdDuUN+k6S7a6VrdI+9nI81p2bgDahdKyKb4UmH DvPFhMg6X/Hpd7wRybx7ksDSHqKpkHE+l8DqKO2uMhP8KIqB20AIey0fyMEJ4zoFjYgstvfl4 vsQjh9933lMnk0hVkMb7+oINh6koSuxZHWAoQdXv/4k5kr43TLIdXYRagpJvkOPZZDmCkawFp aaOB9Nf 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:31:33 -0000 Hi Jonathan, > On Dec 23, 2015, at 11:01 , moeller0 wrote: >=20 > Hi Jonathan, >=20 >> 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. >=20 > 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. To add to myself, multiple internal hosts accessing the same = external host should result in each flow using up to each hot=E2=80=99s = bandwidth share. > (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?) >=20 > Which of the three options will handle that well dual-X or triple-iso? >=20 > Best Regards > M. >=20 >=20 >>=20 >> Merry Christmas... >>=20 >> - Jonathan Morton >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake