From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AC39721F2FA for ; Mon, 13 Apr 2015 07:23:08 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MAQMg-1YWA1735Xm-00Behe; Mon, 13 Apr 2015 16:23:03 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 13 Apr 2015 16:23:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <558D3A0C-75A0-4707-95DF-790F29F825AE@gmx.de> References: To: leetminiwheat X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:NgdCjsYTrq4UouISU15G4G7jbOko5lPXvnJH/6Oty45AfkdX72x kCJFBx4e0mEm1Yywa63bbEnkoLL02Phc2KL9aDntxSDbxKK/k0AC0HkjDWdiORi7p0Kzics QJbAebPx6yHBKwkBv3EDfipYhY48saq1urLRpUstaoC6RjWAXn1L84JA9HTPgnjyTPKfWec 8QMB2GsSGvVvq4akDZEvQ== X-UI-Out-Filterresults: notjunk:1; Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] squash/ignore DSCP and mangle table questions X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:23:40 -0000 Hi leetminiwheat, On Apr 13, 2015, at 16:16 , leetminiwheat = wrote: > Upon further inspection, the SQM log says:=20 >=20 > SQM: Keeping differentiated services code points (DSCP) from ingress. > SQM: Perform DSCP based filtering on ingress. (3-tier classification),=20= >=20 > so perhaps the shaper can use this information? but only on ingress? Well on egress simple.qos can and will use (some) DSCP values to = steer packets into one of the three tiers; on ingress this only works if = =93Ignore DSCP on ingress=94 is set to allow. =93Keeping differentiated = services code points (DSCP) from ingress.=94 just tells you that you did = not request that the TOS bits be zeroed (excluding the ECN bits). >=20 > I'm using the latest SQM scripts from git. Could this also be why my = interfaces are remaining at 1000 txqueuelen due to new scripts? (I'm on = 3.10.50-1) Could you post the output of calling the following commands on = your router please: /etc/init.d/sqm stop /etc/init.d/sqm start tc -d qdisc Best Regards Sebastian >=20 > Still confused about what the xset stuff is doing though. >=20 > On Mon, Apr 13, 2015 at 9:43 AM, leetminiwheat = wrote: > > > > > > > > On Mon, Apr 13, 2015 at 7:32 AM, Sebastian Moeller = wrote: > > > > > > > "Squash DSCP on inbound packets (ingress):=94 this = will replace all DSCP marks with 0x0 (I believe), but only after the = ingress qdisc. > > > > > In essence this means you can actually interpret ingress DSCP = marks from upstream ("Ignore DSCP on ingress=94 set to ALLOW) but wipe = them after the ingress shaping (with "Squash DSCP on inbound packets = (ingress);=94 active). So the default should be =93Ignore DSCP on = ingress=94 and Squash (the second can be argued, as long as no one bases = routing decisions on the marks they do not hurt). The rest of your = questions are beyond my expertise... > > > > > > > > Hmm, why would we want to remove all DSCP on output then? > > > > > > Because often we do not want to trust the internet to do = the right thing and not game our classification? At least this is a = common argument made... > > > > > > > I assume many ISPs and routers will squash them anyways, > > > > > > ISPs are free to set the DSCP values to whatever suits = them, and sometimes they do weird things, in essence per default we = should not trust them... > > > > > > > but wouldn't it serve *some* purpose to differentiate between = different traffic types? > > > > > > Sure, if you know what you do setting reasonable DSCP = values for VoIP sounds like a good thing (but due to fq_codel=92s inner = working might not be required). Alas iptables is only available to us = after the packets went through the IFB, so any resetting of DSCP values = would be for internal network nodes, our shaper unfortunately can not = use this information=85 > > > > Curious, if fq_codel runs after iptables and can't use DSCP = information, why does it mark packets in the mangle chain? I'm still = trying to wrap my head around the --set-xmark > > > > relevant snippet here with squash disabled and ignore ingress set to = allow. Can anyone answer why it's matching DSCP marks and what is it = doing with xset? I assumed it was marking packets for use in QOS, such = as the chain suggests "Chain QOS_MARK_ge00" but this is a jump target = from both PREROUTING and POSTROUTING so it should hit FORWARD too, > > > > = ##########################################################################= ########################### > > #iptables -nL -t mangle > > Chain PREROUTING (policy ACCEPT) > > target prot opt source destination > > MARK tcp -- 0.0.0.0/0 0.0.0.0/0 MARK = xset 0x2/0xff > > fwmark all -- 0.0.0.0/0 0.0.0.0/0 > > QOS_MARK_ge00 all -- 0.0.0.0/0 0.0.0.0/0 = [goto] mark match 0x0/0xff > > > > Chain INPUT (policy ACCEPT) > > target prot opt source destination > > > > Chain FORWARD (policy ACCEPT) > > target prot opt source destination > > mssfix all -- 0.0.0.0/0 0.0.0.0/0 > > > > Chain OUTPUT (policy ACCEPT) > > target prot opt source destination > > DSCP udp -- 0.0.0.0/0 0.0.0.0/0 = multiport ports 123,53 DSCP set 0x24 > > > > Chain POSTROUTING (policy ACCEPT) > > target prot opt source destination > > QOS_MARK_ge00 all -- 0.0.0.0/0 0.0.0.0/0 = [goto] mark match 0x0/0xff > > > > Chain QOS_MARK_ge00 (2 references) > > target prot opt source destination > > MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK = xset 0x2/0xff > > MARK all -- 0.0.0.0/0 0.0.0.0/0 DSCP = match 0x08 MARK xset 0x3/0xff > > MARK all -- 0.0.0.0/0 0.0.0.0/0 DSCP = match 0x30 MARK xset 0x1/0xff > > MARK all -- 0.0.0.0/0 0.0.0.0/0 DSCP = match 0x2e MARK xset 0x1/0xff > > MARK all -- 0.0.0.0/0 0.0.0.0/0 DSCP = match 0x24 MARK xset 0x1/0xff > > MARK all -- 0.0.0.0/0 0.0.0.0/0 tos = match0x10/0x3f MARK xset 0x1/0xff > > > > Chain fwmark (1 references) > > target prot opt source destination > > > > Chain mssfix (1 references) > > target prot opt source destination > > TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp = flags:0x06/0x02 /* wan (mtu_fix) */ TCPMSS clamp to PMTU > > = ##########################################################################= ########################### > > #iptables -S -t mangle > > -P PREROUTING ACCEPT > > -P INPUT ACCEPT > > -P FORWARD ACCEPT > > -P OUTPUT ACCEPT > > -P POSTROUTING ACCEPT > > -N fwmark > > -N mssfix > > -A PREROUTING -i vtun+ -p tcp -j MARK --set-xmark 0x2/0xff > > -A PREROUTING -j fwmark > > -A PREROUTING -i ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00 > > -A FORWARD -j mssfix > > -A OUTPUT -p udp -m multiport --ports 123,53 -j DSCP --set-dscp 0x24 > > -A POSTROUTING -o ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00 > > -A QOS_MARK_ge00 -j MARK --set-xmark 0x2/0xff > > -A QOS_MARK_ge00 -m dscp --dscp 0x08 -j MARK --set-xmark 0x3/0xff > > -A QOS_MARK_ge00 -m dscp --dscp 0x30 -j MARK --set-xmark 0x1/0xff > > -A QOS_MARK_ge00 -m dscp --dscp 0x2e -j MARK --set-xmark 0x1/0xff > > -A QOS_MARK_ge00 -m dscp --dscp 0x24 -j MARK --set-xmark 0x1/0xff > > -A QOS_MARK_ge00 -m tos --tos 0x10/0x3f -j MARK --set-xmark 0x1/0xff > > -A mssfix -o ge00 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment = --comment "wan (mtu_fix)" -j TCPMSS --clamp-mss-to-pmtu > > = ##########################################################################= ########################### > > > > I've inserted my custom --set-dscp user created chains into = PREROUTING and POSTROUTING, which I excluded from the above but I still = don't understand what exactly these marks are doing, even after reading = the documentation. It seems like it's still replacing DSCP from what I = can tell. > > > > ------ > > Also, another unrelated question regarding queue buffers; > > > > All my ifconfig interfaces show txqueuelen:1000 except for ifb4ge00 = and ifb4gw00, both of which I have SQM rate limiting on. wasn't this = supposed to be tweaked by debloat scripts? /etc/config/debloat says = obsoleted by /etc/hotplug.d/iface/02-debloat but that file is empty.=20 > > > > uci seems to show the txqueuelen options disabled. Did something = change, are these not needed anymore, or did I screw up a config = somewhere? > > # uci show | grep debloat > > debloat.@wireless[0]=3Dwireless > > debloat.@wireless[0].txqueuelen=3D4 > > debloat.@wirelessn[0]=3Dwirelessn > > debloat.@wirelessn[0].txqueuelen=3D16 > > debloat.@wired10[0]=3Dwired10 > > debloat.@wired10[0].txqueuelen=3D4 > > debloat.@wired100[0]=3Dwired100 > > debloat.@wired100[0].txqueuelen=3D16 > > debloat.@wired1000[0]=3Dwired1000 > > debloat.@wired1000[0].txqueuelen=3D32 > > uci: Entry not found > > > > > > Thanks for your time, and my apologies if these questions seem dumb = or regarded as unnecessary mailing list spam - I'm still learning and = tweaking things. I do my best to search the wikis and google before = asking here. > > > > > > > > > > > >