From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 ABC5D21F5CE for ; Mon, 16 Nov 2015 07:33:13 -0800 (PST) Received: from hms-beagle.am28.uni-tuebingen.de ([134.2.92.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MSq5p-1ZqGdq0ZaX-00RthB; Mon, 16 Nov 2015 16:33:07 +0100 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, 16 Nov 2015 16:33:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56420697.9080606@darbyshire-bryant.me.uk> <5649EF39.3060300@darbyshire-bryant.me.uk> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:wVN9FZ0JCyeXG7ysS+b//329PWJX83l5wOaVQQefnPGriJx+nwD Z5AK3gTZ3+EagpKYSLq0jaya09jQ1I0uDGAe6pNESFmNdVNDRMzmLzaSofLz/VlACs7Ktt8 yroI2/7DSYc4eEAxEHnkRwAsWP4EEtmZ9a2gwl6Cym4cbC4wdziaUu4TZeCBCzp3Lg8MzjH wDqRlrSPbk1NuFyenZg/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:znYTKVIDDKU=:WvK5jKmDZEjPG9g3FvQnBP C2bY/qcsXRzwg4cyyiEa7jnUeOBvB0CZkqySQ7kRlH0i9Z6yapEVhM++b5Kp5SF063ZhI64jQ 8Nb8mwMNvhTM+9em/9HOEElYDyVRluGgXI2ve+as+zKoaJdRB2OIT1bVIQYlbXMDjxYAUpSGh d/XztdmHM9YbZCKtWh3giHzwDdvx1JiXS5+UI/gIIOtHb2jNwLbHsumhb/EA6crdz1V05eFAZ uAJIG/bPOfyW6YFTNZyoGjLrU3cPDYih0D0t40NSdtvzbb64RqTtrG2sa/bzwykbcslxlFM7+ 07ll5pL/00i0L0VIfUpRpbnCtCBFYG71Vi8uF8JHBUiRQONAta1W6/s/EuHx4nAhH4nlknYgF jErOi7LvRpBN06hWKvVxmyxU0FN1b/c5cWv5ljJ7BEsMSFlKW693iJxSPWyWjSJvYpCV//ijK 1VWPPsm1rkYTjiC+3QaYJ1aSdP5IGr22tY3OibTCJGddIJM2ATMgcFCNz0ahtG/1rRPP/S7jk hsXjowcJiqsXu+7qwfnpwN5C73V3mkF5NckMkmLX+NJKSbTySPn4XpDGpD34ZDTn7XmYip+Fe pIOpQjQD/hKxjmSMLRL3P/jXmtNDWd8akOFW3tkMbxdAzsrfgqORlUlwW4fN+6slpOPZlonRv ZlZ9Oxg55FZzx8YW1lmDyxgwuGy4cojxQovJIP7nnoxNLr6U8jr8+gbxadwTNBiQxrpcbo/PB mKYaAZxzZc6oUI27jydCbPO+O0dM2wEA/spYydMwbLLpg4WChLvSFZR882I5ayNAyTMXPowpj OAcEMFt Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Announce - possible new feature - DSCP cleaning X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 16 Nov 2015 15:33:36 -0000 Hi Dave, On Nov 16, 2015, at 16:03 , Dave Taht wrote: > I have not been doing any active development until... tomorrow. >=20 > A goal I have for today is to actually build a version of openwrt + > all this stuff for the linksys ac1200. >=20 > I was not particularly huge on using another field (q->squash) to > trigger squashing, and I cannot come up with a use case that makes > sense to me. >=20 > Under what circumstances do you think separating these two functions > to be useful? Well, if I want to use DSCP values internally on my egress = interface, but do not want to leak them out to my ISP. Totally contrived = example, I might want to keep bit torrent at CS1/BK internally but do = not want to make it easier for the ISP to differentially restrict my bit = torrent traffic (I neither use bit torrent enough nor do know whether = ISPs actually still throttle). More realistically it would be nice to = separate the 6 DSCP bits into two groups of 3, one for sender intent and = one for current network usage, and then copy the intent bits to the = local bits on egress or remap local bits to zero, but I digress. And similarly on ingress I might want to use DSCP markings but = remap them to zero on ingress so that no internal AP does the = VO/VI/BE/BK qos thing on air (there are certainly better ways to assure = such behavior). Best Regards Sebastian >=20 > Dave T=E4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi >=20 >=20 > On Mon, Nov 16, 2015 at 3:59 PM, Kevin Darbyshire-Bryant > wrote: >> Does anyone have any feedback on this? Good idea/bad idea? Good/bad >> implementation? >>=20 >> Any reason why 'squash' branches of both sch-cake & tc-adv shouldn't = be >> merged? >>=20 >> On 10/11/15 15:00, Kevin Darbyshire-Bryant wrote: >>> Greetings :-) >>>=20 >>> A bit of a blast from the past this one, but one Sebastian Moeller = of >>> this list fame wrote a while ago " >>>=20 >>> Just played a bit with the shiny new squash option. For my limited = testing it seems to work. I do wonder whether the automatic default to = besteffort is the ideal behavior though. For example on egress it would = be nice to be able to use the internal set DSCP markings but clean them = from the outgoing packets as not to leak =93information=94 to the ISP, = similarly but more contrived the same could be agued for ingress " >>>=20 >>> Well Mr Moeller, today is your lucky day because I've just pushed = 'squash' branches to both cake & tc-adv that separate the 'DSCP = squashing' behaviour from diffserv behaviour. Specifying 'squash' sets = diffserv mode to 'besteffort' (ie 1 tin only) and squashes DSCP as = before, however if you specify something like 'diffserv4 squash' then = DSCP codings are noted at qdisc enqueue so tins/bandwidths are used as = marked, then the DSCP marking is squashed so on dequeue DSCP has been = removed. >>>=20 >>> The active bit of the change is (diff): >>>=20 >>> /* extract the Diffserv Precedence field, if it exists */ >>> - if (q->tin_mode !=3D CAKE_MODE_SQUASH) { >>> + if (q->tin_mode !=3D CAKE_MODE_BESTEFFORT) { >>> tin =3D q->tin_index[cake_get_diffserv(skb)]; >>> if (unlikely(tin >=3D q->tin_cnt)) >>> tin =3D 0; >>> } else { >>> - cake_squash_diffserv(skb); >>> tin =3D 0; >>> } >>>=20 >>> + /* now clear DSCP bits if squashing */ >>> + if (q->squash) >>> + cake_squash_diffserv(skb); >>>=20 >>>=20 >>> https://github.com/dtaht/sch_cake/tree/squash & = https://github.com/dtaht/tc-adv/tree/squash >>>=20 >>> Needs testing (I've not managed to break it yet) and *thought before = merging* >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Cake mailing list >>> Cake@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cake >>=20 >>=20 >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >>=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake