From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 17DD93B2A2 for ; Mon, 28 Mar 2016 11:04:44 -0400 (EDT) Received: by mail-oi0-x22d.google.com with SMTP id d205so173501444oia.0 for ; Mon, 28 Mar 2016 08:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9B3IsmAikXiC+FWAqESLKHF8yBTanUKbHDu5hyuiGa8=; b=fQzelO89dWdft/oeduHrFT2D4pTVxc/b9IB51c6zCWIGTxUiUs0JkTuY/RgPBYukF3 /HwLREQWM0rqWpScVHtJj+FRLGpPd5pC6/seUBD61Qnvjb/GEKiU8ZMPEvIbYk+RsF2l I234OjaPLyfFWnfGMmPgx4ZtJlU+8vuK5qvQQv77v1DeH79V1XV9BGjLt0j6yfo2Sewe EnvPuXVTOWMqNtJ/6oNewBDWaT86PCK7pCwGfPuiNf30iEKy5OEy7JqjeQBBHtkRR9JI 9/Ht8DH9haW7NpSsdj1ISmtoT6uQmVEzJmTFYmw8IOaNE8crJggzb+BLmAcXyVLuionr 9EGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9B3IsmAikXiC+FWAqESLKHF8yBTanUKbHDu5hyuiGa8=; b=G9NQjZ49Ct11Q/rEChSnx7UbOIvqKp8KDX2WIK1h98sCm/y8TAuTGn8Bf8cGHRmyor /Yy+P/L9L/Cn1Ea/SR7SMHj5tlb4Q/2jEg5CsF/kW7AFpkI9LFHu1hCGsz8tCBzFEzzQ m9WRpo7Yy9nTIBt+vQNpJFeyynZpAV0/R4DIkgPf3mFxonND/OXkQOaczsa+vIFZVcWh E1FFRRKIYo6gz+FMhkc5m8Fwgj8TUoECidvQQn4glBj7QqdrO8omOTasumnF4iygooFS LqlzAVRLpokDf3zICt6g0Y2AasHYwmiRvrByrj+Q2CDhJJdTSCHESqDTL4zqH+vfUQwD ANUA== X-Gm-Message-State: AD7BkJLgCDdP+8Vdzo8nfUhnMWzwZdboYSPTgimelM5YB9s+nKMZK1iVI7u4ZzCWAVlYTQl1Mh0qDaKyV3dd3g== MIME-Version: 1.0 X-Received: by 10.202.173.146 with SMTP id w140mr11756577oie.118.1459177448968; Mon, 28 Mar 2016 08:04:08 -0700 (PDT) Received: by 10.202.89.130 with HTTP; Mon, 28 Mar 2016 08:04:08 -0700 (PDT) In-Reply-To: <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> <4EE1F9D3-3DC2-4EE4-B3E3-577206C82BB0@gmx.de> Date: Mon, 28 Mar 2016 20:34:08 +0530 Message-ID: From: Allan Pinto To: moeller0 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113ce6cc82a2d5052f1d392f 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 15:04:45 -0000 --001a113ce6cc82a2d5052f1d392f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable getting a illegal filter id for these two commands, >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 will check further and reply. On Mon, Mar 28, 2016 at 6:36 PM, moeller0 wrote: > Hi Allen, > > > On Mar 28, 2016, at 14:25 , Allan Pinto wrote: > > > > Hi Sebastian, > > 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 fr= om > 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. > > > I am right now testing on a i3 machine, but for actual live testing am > planning to test with i7 or a xeon. > > > > Cache-Server [ connected to internet gateway , traffi= c > can be sent to it via wccp or policy based routing ] > > | > > internet---->internet Gateway =E2=80=94> L2 switch [ MEN network on f= iber ] > --> 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 ] > > > > basically the customer will create a broadband connection on his pc to > connect. > > > > . > @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 tha= t > 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 overhe= ad > to account for (keep in mind that Linux will occasionally add 14 bytes fo= r > parts of the ethernet header). It might make sense to include preamble an= d > inter-frame gap into the per packet overhead as effectively you are shapi= ng > on ethernet IIUC. > > > > > > As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB here a= nd 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)? > > > > i may be wrong here, but i think jonathan is advising the use of IMQ/IF= B > 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 appr= oach. > > Best Regards > Sebastian > > > > > > > > > On Mon, Mar 28, 2016 at 5:39 PM, moeller0 wrote: > > Hi Jonathan, > > > > > 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. > > > > 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)? > > > > > > > > However, I think this would work - though it=E2=80=99s completely unt= ested: > > > > > > ip link set ifb0 up > > > > > > tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth > $FULL_RATE triple-isolate > > > > 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 t= he > link technology you use? > > > > > > > > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth > $NONCACHE_RATE flows > > > > I believe this might work as egress on the interface facing the > L2-switch=E2=80=A6 > > > > > > > > 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. > > > > It should, but only on egress=E2=80=A6 > > > > > > > I=E2=80=99d appreciate feedback on whether this system does in fact w= ork. > > > > > >> I would respectfully recommend to avoid the symbolic overhead > parameters > > > > > > Even if I change their underlying behaviour in the future, it=E2=80= =99ll 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. > > > > All fair points! > > > > > > > > - Jonathan Morton > > > > > > > > > Best Regards > > Sebastian > > > > > > > > -- > > Thanx and regd's. > > > > Allan. > > > > --=20 Thanx and regd's. Allan. --001a113ce6cc82a2d5052f1d392f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
getting a illegal filter id for these two commands,=C2=A0<= div>
>tc filter replace dev ppp0 protocol ip prio 1 handle 1= 1 u32 match ip src $CACHE_IP/32
> tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 act= ion mirred egress redirect dev ifb0

will check further and reply.=C2=A0

On Mon, Mar 28, = 2016 at 6:36 PM, moeller0 <moeller0@gmx.de> wrote:
Hi Allen,

> On Mar 28, 2016, at 14:25 , Allan Pinto <allan316@gmail.com> wrote:
>
> Hi Sebastian,
> I should have made this more clear please see below topology with adde= d comments. the customers connecting to the linux router can be in range fr= om 100 to 2000, so shaping on the switch is not really a option.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Oh, I did not advocate shaping on the sw= itch, just on the Linux router=E2=80=99s interface connecting it to that sw= itch, but it seems i misunderstood your issue, I assumed you want to shape = both directions=E2=80=A6.

> I am right now testing on a i3 machine, but for actual live testing am= planning to test with i7 or a xeon.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ca= che-Server [ connected to internet gateway , traffic can be sent to it via = wccp or policy based routing ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0internet---->internet Gateway =E2=80=94> L2 switch [= MEN network on fiber ]=C2=A0 =C2=A0--> LInux router with cake[ includes= a pppoe server which authenticates with radius ] - - [ pppoe connection ov= er a fiber men network ]=C2=A0 --> customer [ customers can be 100 to 20= 00 ]
>
> basically the customer will create a broadband connection on his pc to= connect.
>
> . > @Allan, what is the link technology you use?
> fiber 1g/10g/last hop cat5e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 s= how 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 packe= t overhead as effectively you are shaping on ethernet IIUC.

>
> > As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB he= re and use dual egress shaping instead (once on the pppoe device and once o= n the interface connected to the switch, which effectively should shape bot= h directions)?
>
> i may be wrong here, but i think jonathan is advising the use of IMQ/I= FB to provide two different shaping scenarios on egress itself. not ingress= . as i need cache traffic to have higher bandwidth on the egress towards cu= stomer but non- cache traffic [ pure internet ] to remain within the bandwi= dth limits purchased by the customer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ah, you are right, I have not fully thou= ght through your requirements then. I am quite curios to learn how this wil= l 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.

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian

>
>
>
> On Mon, Mar 28, 2016 at 5:39 PM, moeller0 <moeller0@gmx.de> wrote:
> Hi Jonathan,
>
> > On Mar 28, 2016, at 12:31 , Jonathan Morton <chromatix99@gmail.com> wrote:
> >
> >
> >> On 27 Mar, 2016, at 11:20, moeller0 <moeller0@gmx.de> wrote:
> >>
> >> it might be more future-proof to just use IFBs from the get-g= o
> >
> > 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 packe= ts through an IFB device, and unlike iptables, the CBQ filter mechanism doe= sn=E2=80=99t directly support negative matches of any kind.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As I just wrote, can=E2=80=99t we com= pletely 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)?
>
> >
> > 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 bandwid= th $FULL_RATE triple-isolate
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I wonder how you came up with pppoe-v= cmux, 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?
>
> >
> > tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONC= ACHE_RATE flows
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I believe this might work as egress o= n the interface facing the L2-switch=E2=80=A6
>
> >
> > 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 actio= n mirred egress redirect dev ifb0
> >
> > The logic of the above is that a positive match is made on the ca= che traffic, but no action is taken.=C2=A0 This terminates filter processin= g for that traffic.=C2=A0 The remaining traffic is redirected unconditional= ly 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 t= he original device.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It should, but only on egress=E2=80= =A6
>
>
> > I=E2=80=99d appreciate feedback on whether this system does in fa= ct work.
> >
> >> I would respectfully recommend to avoid the symbolic overhead= parameters
> >
> > Even if I change their underlying behaviour in the future, it=E2= =80=99ll be in a way that retains backwards compatibility with all the exam= ples I=E2=80=99ve given for the current scheme.=C2=A0 I mostly wanted to ra= ise awareness that the overhead compensation system exists for use on encap= sulated links.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0All fair points!
>
> >
> > - Jonathan Morton
> >
>
>
> Best Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>
>
>
> --
> Thanx and regd's.
>
> Allan.
>




--
=
Thanx and regd's.
Allan.

--001a113ce6cc82a2d5052f1d392f--