From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by lists.bufferbloat.net (Postfix) with ESMTPS id DED6D3C9F0 for ; Fri, 15 Jan 2016 03:05:37 -0500 (EST) Received: from u-089-d068.biologie.uni-tuebingen.de ([134.2.89.68]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1aJzO301vk-0001Fe; Fri, 15 Jan 2016 09:05:35 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Fri, 15 Jan 2016 09:05:34 +0100 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <5693E8FA.4000803@darbyshire-bryant.me.uk> <56941191.1010601@darbyshire-bryant.me.uk> <452D0F47-931B-4412-AC59-C308388AA1E4@gmail.com> <02A10F37-145C-4BF9-B428-BC1BDF700135@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:zILGd53sZ0b+8MLb2uSljQNxuEtSd113TmyxLdy8ssXnd0x03vY RaEEvEqP8Y8o31EW1wM6WLh9aJOkJR0bQJqQkKluic+fZOWpbFxETCKJvA2GabIR11e8Yx+ EkSXvF9N0zKs0m+j1kyg3FbfD/Jm166O1oorY7qq4DoDa0hoq/wYF29oquevSfzV7yAaeie 0WdRn4PL9+QqsZ5K+/b5g== X-UI-Out-Filterresults: notjunk:1;V01:K0:j4FI/tCiTMA=:vhW23rVKvFnsZBWtSG5HPo LweUVHe0hkbaF/1tPZ+e3JDZ+sVGETR6So4lFwoZ4WyKn3YPp1JJa8BJnr93VQsg2f9oxJTE2 OgnIbLvqm5KZGC2wWQmhsPAZ6wM+HkjzxzUc1Q5r6WSPtYwr6FYTEwls0JjA1YD3WIJ4Ag23V PAW6sxWcJmX/GoVknkT+CQWReRtOTgv5lLCpVw/UZ9CWAJElsGbP/9euh0IsR46VTu7ry9q/J X7AkxEgnRhGqP4dfetXc+snF3B9apkFoU/ae99vPxFcGITAdIs3NYggSYBJwWgdMe2drFWL3p ZFRfxv4jtoPKPY7tFNLOzH6kAmuvOyrxh2AvHOD2jZLkU1xkAlzt47lSQXpcJ4Ey+2kPrhwit CV/vSTwHM36djdFT/uwb3cndrOQLQUPvLi1P/T0/ELspAekwWrtY/zliR1zVvIRmDYr7+rvb/ RPViDF8KPlLWp4urQIjJAoSpG/hajSRDkfPP25aJAz2iJtjaGP0kjkDUX+s29+avXO/kTVUIa TcQS0qNbXvmzYItfVNFNlMWPPPYrNvgLEcnBk2rwp6VYKQQxVAqDqaUoDXtuGLb3nRwOnfHdX WfEJXoHkMS8LbrARqJjlZqQLwNWcI4fC+rcsr/+8PaeoRZfdvi9m4nDgLq8orfsHZLxWLhM3j TSL4zGXE6dMJCwK98OzmableU9dDxSaaX8muU8oa1KCpPRSBPY9Dw1DgenGJqsx62+bvPFYxU uqWOEnTap6hI+zGTNskMm/94R1eq5cTrNDlULEmaPjgapveUi5qePLXvGdWLKE3Uq3cQjnj0k DGVs22Q Subject: Re: [Cake] triple flow isolation 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: Fri, 15 Jan 2016 08:05:38 -0000 Hi Jonathan, > On Jan 15, 2016, at 01:05 , Jonathan Morton = wrote: >=20 >=20 >> On 14 Jan, 2016, at 20:53, moeller0 wrote: >>=20 >> So I have not grokked the triple algorithm fully (aka not at all), = but I already know that what user=E2=80=99s are looking for is fairness = by internal host IPs. Now, since as I explained before ingress and = egress really are too flexible to use as direction pointers, I assume we = are looking for some configuration parameter that contains a direction; = so as long as =E2=80=9Ctriple=E2=80=9D allows to request fairness by = source IP or by destination IP (since these might change depending on = the interface cake is running on) all will be fine. I just do not see = how a simple unidirectional parameter like =E2=80=9Ctriple-iso=E2=80=9D = will allow to take the fact into account that ingress and egress are = only relative to the sqm interface and do not necessarily align with the = internal/WAN ingress and egress=E2=80=A6 But as I said before I do not = claim I understand what triple-iso intends to accomplish in detail. >=20 > The short version is that, in theory at least, I=E2=80=99ve found a = way to ensure fairness without needing to know which side of the = interface is which. =20 Could you please explain the fairness you are talking about = here? I still want to test cake in my environment and will do a much = better job if I know what behavior to expect, and frankly I am unsure = what triple-iso is supposed to guarantee (I know this is my own = responsibility, but getting a high level description seems more = efficient than trying to deduce this from the implementation, especially = given that you are not fully satisfied withe the current = implementation). Thanks in advance. > By accounting for *both* source and destination host fairness at the = same time, and not placing one above the other in importance, it should = all work out in the end. The method by which I do so is probably = interesting enough to write a paper about, once I=E2=80=99ve got it = working in practice. >=20 > At this point, I strongly suspect I=E2=80=99ve made an implementation = blunder, since even single-stepping through the theoretical = algorithm=E2=80=99s behaviour, packet by packet, produces approximately = the desired results - which are however not reproduced in actual = measurements on my LAN. Time to add more stats to the multitude already = present! >=20 > If you want to be explicit about directionality, that=E2=80=99s what = the two new =E2=80=9Cdual=E2=80=9D modes are for. The =E2=80=9Ctriple = isolation=E2=80=9D algorithm is still used, but the undesired attribute = is ignored. The =E2=80=9Ctriple=E2=80=9D mode combines their effects. This is the part I can not get my head around: fairness by = internal host IP (what people seem to request, with, as you alluded to = before, DSCP tiers per internal host IP and per flow fairness in each = tier) basically will not generally allow fairness by external IP. E.g. = three internal hosts talk to 6 external hosts, fairness by internal IP = will try to give 1/3 of the bandwidth to the internal hosts, fairness by = external IP will give 1/6, now unless the connections are symmetric = (each internal IP talks to the same number of external IPs) the actual = bandwidth distribution will deviate from either 1/3 or 1/6, so what = level of fairness will triple-iso aim for? With explicit directionality = I can easily see how to enforce either 1/3 or 1/6 in the example... Best Regards Sebastian >=20 > - Jonathan Morton >=20