From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6694D3B2A0 for ; Sun, 27 Mar 2016 04:20:48 -0400 (EDT) Received: from hms-beagle.lan ([93.237.70.232]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MB2G8-1aaE373EbE-009xM4; Sun, 27 Mar 2016 10:20:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> Date: Sun, 27 Mar 2016 10:20:44 +0200 Cc: Allan Pinto , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:9HFrHHEBrB7aAZC0rJSoPBWl4nc5ci9gXsUZfTBTIThIXK3ej4B HeL8AgULhtv+vpRfXlGdzo7tmCjR+3bpToP3reSQMKb1BVXwD3/RNJJ3XwtRb2WaquTqkOq Hu7tWuNZkgoDtihgaes/sR0Q9KoyLCbrewcBF/f/tcxMdZqXUOG4OfiHg5NNsAFDp1WfoOv CJ90Jv4zGq1+hHoq84Teg== X-UI-Out-Filterresults: notjunk:1;V01:K0:aUFR71z6g0E=:8/2GVUFkqtHks6vOdpai7m dCSLseHLOILUb/0iNJlluXzr8zgg+1TKyH50uR7Okp3vqYEDnnpJwhKQcOAaowk7i8uXa1Eo7 viSJqvaQRfVRWHb7tri2iO3DJnlZpH7s777GzlPyv9m3mQcbX1PWzxFe/N713tOYg4fQTY6yh wXWGoCU6TVmC2BCwBb6d9kmdbZh0EWHAXZaZvtaJf0+1JGsuNXMA14tmbrmVbzHvfmNOp6m6N agx+kC3Iv+19Y8UsKZHHCUv0MU3q/zHBDy5J3JZujHSlJ1XEvVqMr+HMc6VUMExv22/ukcX4z sElESPIivdlkDam5fcyfkMGE7xChRRb1tP1X7Ympw+fy61QqyrekwiBWx4GnVLGCzGlFkByf9 ne1ez03zetiFm/zTACT6yMSMY/gtCRBeZe7T0OGnnjrZxFp02IS5Ny8yxcIwIh8k+50WEKQ5O iTC+Udps75ycnfuVPw9EoxmVCK0HAdvPUcvJevxLcUmHRDoPmFzbfjANYq8M+OMysyzcbGAOl 1Tm/vJTCCwIed5adyS1KMnAJxeqeHboS/jzc+QeAC4Mg8ciy9zQ/4maY26pfKU/3zuiK/U3S0 FPSbR7mMWqAYMIjgcrMJMudNRVd7IH8HJtsg9RulsKEvnXwNpdhsUIK15xj2dNO58MuM++iMN w30P+zYGCZ4rWn/84NE+vMJQdc1cQpLsQRAYSGGPPwbgvJmqwADyei6XURfcfAnofd6u963El sUlJDIvrFyAUgyXXc/Vt21wjAU3Ix7kypqlaPLMtNCwRn1LSCUz52LpnHtU7mzaBlpeJ13Rbl d/PYKng Subject: Re: [Cake] cake separate qos for lan 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: Sun, 27 Mar 2016 08:20:48 -0000 Hi Allan, > On Mar 27, 2016, at 09:35 , Jonathan Morton = wrote: >=20 >=20 >> On 27 Mar, 2016, at 08:31, Allan Pinto wrote: >>=20 >> Cache-Server >> | >> internet Gateway ---> L2 switch --> LInux router with cake - - [ = pppoe connection ] --> customer >=20 > Aha - that is a different topology than we usually assume. So the = egress side of the port is the right one to consider. It=E2=80=99s nice = to see Cake being considered for the provider's side of the link. >=20 > Interesting. >=20 > Cake doesn=E2=80=99t have its own facilities to do the sort of = specific discrimination you want. All the mechanisms it has are geared = to sharing a fixed capacity as equitably as is feasible. So you will = need to divide the traffic using some other mechanism, and pass it = through two separate instances of Cake. >=20 > Ideally you want one instance set for the capacity of the physical = link, with all traffic passing through it, and the second instance set = for the allocation for non-cache traffic, with the cache traffic = bypassing it. The customer will then get full link capacity when = accessing the cache and nothing else, and latency will still be = controlled well with a complex mix of traffic. >=20 > I recommend you use the IMQ mechanism = (http://lartc.org/howto/lartc.imq.html) to achieve the ideal = configuration above: While IMQ seems more complete than IFB, ifb made it into the = main-line kernel, so IMQ will be staying out in the cold, so it might be = more future-proof to just use IFBs from the get-go; unless you are happy = to keep compiling out of tree modules (which you wll have to do anyways = for cake, but cake hopefully will be included/offered upstream). >=20 > ip link set imq0 up >=20 > tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth = $FULL_RATE triple-isolate I would respectfully recommend to avoid the symbolic overhead = parameters and use =E2=80=9Coverhead NN=E2=80=9D instead (with NN being = the number in bytes), as the current state of the symbolic parameters is = under-documented and inconsistent.=20 >=20 > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth = $NONCACHE_RATE flows >=20 > iptables -t mangle -A PREROUTING -o ppp0 -s $CACHE_IP -j IMQ =E2=80=94to= dev 0 >=20 > That reminds me - we need to update the documentation to properly = describe the overhead and triple-isolation keywords. =20 We first need to fix the overhead keywords I believe, having = some of them re-set the overhead to a fixed number and some being = modifiers that can be reasonably added to other overhead keywords with = no distinction of this fact in either the parameter name or = documentation is sub-optimal=E2=80=A6 The current state where one can = supply multiple keywords on the commend line with some being additive = and some resetting the the overhead to a fixed value is highly = surprising.=20 And IMHO just documenting this inconsistency better is not the = right solution. I would vote for making all of the additive and document = that well; this will allow to do the right thing easily but will also = allow for the unforeseeable in the future (and I actually had a patch = ages ago that pushed the behaviour further in the =E2=80=9Cright=E2=80=9D = direction). Best Regards Sebastian > You might need a different overhead setting than =E2=80=9Cpppoe-vcmux=E2= =80=9D depending on the details of your link. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake