From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 2263A3B2A2 for ; Mon, 28 Mar 2016 08:25:48 -0400 (EDT) Received: by mail-oi0-x22c.google.com with SMTP id o62so54673693oig.1 for ; Mon, 28 Mar 2016 05:25:48 -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=AhBzX965t99ZTvKZvKmBP+iJNEG6gfIgs57IzwXJQ0g=; b=kffeCLVmQC21RbLVpKyzFBz20U1IIXnMMPxbW1/2HHbJUsuRX1lwsrdJhGZDV5YH+s YjONqbpl98gyW8ThUQLUnboG2T2RP9D7xQg1e/zklxOESeqEA2fOArbZkR/2i010XNol ACKQTI9ZRcdUgINJdxgHxDGf1lIENYKCwdxTgfkMrCIwgXn56V+IsWSaISa+ofVygCk2 DlljX5vkVJG79brN0WCgztPi09zj7fXOtwthSivo8iqH8V9+2VH2YwgGdNeTg5xk6n31 6c7KKzwfG2hyCcHriPeQ0YoNnpgJyNXe4c8mZpjy1s2Bz1YcpzClxXx2N+o8lcRNNMqe PqZw== 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=AhBzX965t99ZTvKZvKmBP+iJNEG6gfIgs57IzwXJQ0g=; b=GVbSf/rfs+Qn9XYNTy2DXx/HgI2q986xIL6YqdfYmU1YeI9SBsohLiEFR+8JawRo3X vBBTtCrvcFWxGmGo27qrr23yijK+H24XXzmlrSJWctm++rr4o1n1fa5bFJlRmpfhX/3d 5pw6p6FhRKEjT3GmcrxOP6/5wTszIAs3w7cDTFB/miN2u0arYlkEjwgxdzYyLOeVxRiz ZbnUezdpLorGdGFi9iPQaa8auk+IDaPk9QN/AjCQKVZZiUl0tbKTsNmB6sc8j+LgEmsn SnGrjNtfYnc5E51WhrJ2J1ymo60FINfFlF/IodtUl9yqD645Gs24DFUaLhea9jDiFf25 PdYw== X-Gm-Message-State: AD7BkJJOD2UY39NQ1nHZLzWm0MJzhw/DcSPFphuKisNqYp+xHgBRigbxUDHhpornhTWCnHmJp+NxgPoP8vKMAA== MIME-Version: 1.0 X-Received: by 10.202.77.79 with SMTP id a76mr2562840oib.37.1459167947529; Mon, 28 Mar 2016 05:25:47 -0700 (PDT) Received: by 10.202.89.130 with HTTP; Mon, 28 Mar 2016 05:25:47 -0700 (PDT) In-Reply-To: References: <34953EAA-4C76-456E-9B9E-3A73D0DACCDE@gmail.com> <855E3354-30E6-4658-AF38-A0C1E92085CE@gmail.com> <66A00804-E571-4A44-BE3E-422F78C1F1F7@gmail.com> Date: Mon, 28 Mar 2016 17:55:47 +0530 Message-ID: From: Allan Pinto To: moeller0 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113531e82e2674052f1b037c 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 12:25:48 -0000 --001a113531e82e2674052f1b037c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 from 100 to 2000, so shaping on the switch is not really a option. 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 , 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 ] 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 > As I just wrote, can=E2=80=99t we completely avoid the IMQ/IFB here and u= se 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/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. 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 IF= B > 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 he= re 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 untes= ted: > > > > 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 sr= c > $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 h= as 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 wor= k. > > > >> I would respectfully recommend to avoid the symbolic overhead paramete= rs > > > > Even if I change their underlying behaviour in the future, it=E2=80=99l= l be in a > way that retains backwards compatibility with all the examples I=E2=80=99= ve 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 --=20 Thanx and regd's. Allan. --001a113531e82e2674052f1b037c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sebastian,=C2=A0
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 switc= h is not really a option. I am right now testing on a i3 machine, but for a= ctual 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 Cache-Server [ connected to inter= net gateway , traffic can be sent to it via wccp or policy based routing ]<= br>=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 internet---->internet Gateway =E2=80=94> L2 switch [ MEN network = on fiber ] =C2=A0 --> LInux router with cake[ includes a pppoe server wh= ich authenticates with radius ] - - [ pppoe connection over a fiber men net= work ]=C2=A0 --> customer [ customers can be 100 to 2000 ]

basically the customer will create a broadband connec= tion on his pc to connect.

. > @Allan, wha= t is the link technology you use?
fiber 1g/10g/last hop = cat5e

>=C2=A0As I just wrote, can=E2= =80=99t we completely avoid the IMQ/IFB here and use dual egress shaping in= stead (once on the pppoe device and once on the interface connected to the = switch, which effectively should shape both directions)?
<= span style=3D"font-size:12.8px">
i may be wrong here, but i think jonathan is advising the use o= f 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 tow= ards customer but non- cache traffic [ pure internet ] to remain within the= bandwidth limits purchased by the customer.



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-go
>
> For this particular use-case, it seems to be more complicated to use I= FB than IMQ, largely because there is no iptables rule to divert packets th= rough an IFB device, and unlike iptables, the CBQ filter mechanism doesn=E2= =80=99t directly support negative matches of any kind.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As I just wrote, can=E2=80=99t we comple= tely avoid the IMQ/IFB here and use dual egress shaping instead (once on th= e pppoe device and once on the interface connected to the switch, which eff= ectively should shape both directions)?

>
> However, I think this would work - though it=E2=80=99s completely unte= sted:
>
> ip link set ifb0 up
>
> tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth $F= ULL_RATE triple-isolate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I wonder how you came up with pppoe-vcmu= x, 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 fi= ber links. @Allan, what is the link technology you use?

>
> tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_= RATE flows

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I believe this might work as egress on t= he interface facing the L2-switch=E2=80=A6

>
> tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip s= rc $CACHE_IP/32
>
> tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mir= red egress redirect dev ifb0
>
> The logic of the above is that a positive match is made on the cache t= raffic, but no action is taken.=C2=A0 This terminates filter processing for= that traffic.=C2=A0 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 or= iginal device.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It should, but only on egress=E2=80=A6

> I=E2=80=99d appreciate feedback on whether this system does in fact wo= rk.
>
>> I would respectfully recommend to avoid the symbolic overhead para= meters
>
> 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.=C2=A0 I mostly wanted to raise aw= areness that the overhead compensation system exists for use on encapsulate= d links.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 All fair points!

>
> - Jonathan Morton
>


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



--
Th= anx and regd's.

Allan.

--001a113531e82e2674052f1b037c--