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 9D8B73B2A2 for ; Mon, 28 Mar 2016 09:06:58 -0400 (EDT) Received: from hms-beagle.lan ([93.237.70.232]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LvhC4-1ZfbsZ2Rhs-017YVt; Mon, 28 Mar 2016 15:06:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Mon, 28 Mar 2016 15:06:53 +0200 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <4EE1F9D3-3DC2-4EE4-B3E3-577206C82BB0@gmx.de> References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> To: Allan Pinto X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:98tIC3P7wPFCvsTCZN6xdkWQXA7k+vODLJbAq8BiidS+S16yp9C UaAIRNV4d17kpGjDHWMdf0foRY3AWYCz4+cuE3zuIEmtvLDc6IqCCzQrQnw02cp/wRtWMUO SPC0hDLHTViRZo1vXtouwSQDpeEcFsVvuSAuKbFjb6NX9Wh1B2nHt9skQQ4Mntyn3E/b1Rg DxBy3+RUoZItrMUImzhyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:6fKLCfLg5IM=:fyxLvd6WPZdc2QrLXHVgVN 5PKzTHGV/HPJ/ihBdhEYi1FI54hzice8KNPGqMrA7t+xAdefZGxDiibJRdDfWS3mEWbJnGvzt nGo9dviNwjG9Uvo7PK+1+y9K+kuXTOZ5fGO9kU58GTrsOLDGuUPB+mked2LadLUr3d4aFwNL/ 9a4j/1qRPkMIIDV/HZhkJ8J++HtczxLCdEgAQt1IYIH+dWO+4Wt86MrEmrj24PRXz5aTNrdyQ ugY6E7Z7QhJkm682JV/WEv4Wcgke8OcbGvXpjmJ12Ns3qxFyVloQS3ahr0XyQyuHisA3+os29 g6sdjme1/k63m0HUmr9lTSkFwuuabMoXRXNXHs6jOLhMpa/6QSM8vb6JpBi0vPExBrfbIRV0J meI6P5KAfkwk+QUn8qL0EzJq8/XFeBao1jrWNzaReG6qkINRGvYj1mAem8ECzXL1DwmCXEcuu CnXjXe4TIOaCBBBhtu2nb4Yz6WX61qIi/Six5r4AoauqNSs2gTbxmpUVE6tLGP9c7QT8WFh0c nhUiV9ntykrptCbLaz+230J+FmuSd3nmZqcTIWzYnogjGY7aYecO3XuPa7J8/HWqjaLNI9Nfj j34G+uWkLuL2tb54PJS0Jm4oLnNT9etDRjLkBX48SHrryUDLWJbFDfOCyuTclij9bGFGr2qe/ up6E6OizpKgnS9buiOcwl4hTpqMadki2WBWlB08OlOXw7osX5+IxVTrle2g0XJqTxrXsDbk26 krk0duvm3zcR129C7CSEDB3WfL/8MIEkQLFUMvIGX5+cbWdjEjmu0NQuPJWHpGutoj1B65cjl iywrROA 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: Mon, 28 Mar 2016 13:06:59 -0000 Hi Allen, > On Mar 28, 2016, at 14:25 , Allan Pinto wrote: >=20 > Hi Sebastian,=20 > I should have made this more clear please see below topology with = added comments. the customers connecting to the linux router can be in = range from 100 to 2000, so shaping on the switch is not really a option. Oh, I did not advocate shaping on the switch, just on the Linux = router=E2=80=99s interface connecting it to that switch, but it seems i = misunderstood your issue, I assumed you want to shape both = directions=E2=80=A6.=20 > I am right now testing on a i3 machine, but for actual live testing am = planning to test with i7 or a xeon. >=20 > Cache-Server [ connected to internet gateway , = traffic can be sent to it via wccp or policy based routing ] > | > internet---->internet Gateway =E2=80=94> L2 switch [ MEN network on = fiber ] --> LInux router with cake[ includes a pppoe server which = authenticates with radius ] - - [ pppoe connection over a fiber men = network ] --> customer [ customers can be 100 to 2000 ] >=20 > basically the customer will create a broadband connection on his pc to = connect. >=20 > . > @Allan, what is the link technology you use? > fiber 1g/10g/last hop cat5e Nice, that means you can certainly skip using pppoe-vcmux, as = that is ATM/AAl5 specific, I would assume that using =E2=80=9Coverhead = NN=E2=80=9D should be more effective. Since you run the show you will = know exactly which overhead to account for (keep in mind that Linux will = occasionally add 14 bytes for parts of the ethernet header). It might = make sense to include preamble and inter-frame gap into the per packet = overhead as effectively you are shaping on ethernet IIUC. >=20 > > As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB here = and use dual egress shaping instead (once on the pppoe device and once = on the interface connected to the switch, which effectively should shape = both directions)? >=20 > i may be wrong here, but i think jonathan is advising the use of = IMQ/IFB to provide two different shaping scenarios on egress itself. not = ingress. as i need cache traffic to have higher bandwidth on the egress = towards customer but non- cache traffic [ pure internet ] to remain = within the bandwidth limits purchased by the customer. Ah, you are right, I have not fully thought through your = requirements then. I am quite curios to learn how this will work out ;) = Especially since you will need to run (100 to 2000) * 2 cake instances = on the router if you go for a =E2=80=9Ctwo shaper per customer=E2=80=9D = approach.=20 Best Regards Sebastian >=20 >=20 >=20 > On Mon, Mar 28, 2016 at 5:39 PM, moeller0 wrote: > Hi Jonathan, >=20 > > On Mar 28, 2016, at 12:31 , Jonathan Morton = wrote: > > > > > >> On 27 Mar, 2016, at 11:20, moeller0 wrote: > >> > >> it might be more future-proof to just use IFBs from the get-go > > > > For this particular use-case, it seems to be more complicated to use = IFB than IMQ, largely because there is no iptables rule to divert = packets through an IFB device, and unlike iptables, the CBQ filter = mechanism doesn=E2=80=99t directly support negative matches of any kind. >=20 > As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB = here and use dual egress shaping instead (once on the pppoe device and = once on the interface connected to the switch, which effectively should = shape both directions)? >=20 > > > > However, I think this would work - though it=E2=80=99s completely = untested: > > > > ip link set ifb0 up > > > > tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth = $FULL_RATE triple-isolate >=20 > I wonder how you came up with pppoe-vcmux, I have not seen any = information about the link technology in Allan=E2=80=99s post. As far as = I know a number of (mislead) ISPs use PPPoE even on fiber links. @Allan, = what is the link technology you use? >=20 > > > > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth = $NONCACHE_RATE flows >=20 > I believe this might work as egress on the interface facing = the L2-switch=E2=80=A6 >=20 > > > > tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip = src $CACHE_IP/32 > > > > tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action = mirred egress redirect dev ifb0 > > > > The logic of the above is that a positive match is made on the cache = traffic, but no action is taken. This terminates filter processing for = that traffic. The remaining traffic is redirected unconditionally to = the IFB device by the second filter rule. > > > > One thing I=E2=80=99m not entirely certain of is whether traffic = that has been through an IFB device is then requeued in the normal way = on the original device. >=20 > It should, but only on egress=E2=80=A6 >=20 >=20 > > I=E2=80=99d appreciate feedback on whether this system does in fact = work. > > > >> I would respectfully recommend to avoid the symbolic overhead = parameters > > > > Even if I change their underlying behaviour in the future, it=E2=80=99= ll be in a way that retains backwards compatibility with all the = examples I=E2=80=99ve given for the current scheme. I mostly wanted to = raise awareness that the overhead compensation system exists for use on = encapsulated links. >=20 > All fair points! >=20 > > > > - Jonathan Morton > > >=20 >=20 > Best Regards > Sebastian >=20 >=20 >=20 > --=20 > Thanx and regd's. >=20 > Allan. >=20