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 3243A21F430 for ; Fri, 14 Nov 2014 06:14:44 -0800 (PST) Received: from hms-beagle.am28.uni-tuebingen.de ([134.2.92.69]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lkzph-1YNn7M2DMD-00amcD; Fri, 14 Nov 2014 15:14:41 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1415932905.511130758@apps.rackspace.com> Date: Fri, 14 Nov 2014 15:14:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <377184B7-768D-477D-97FF-6813113E3C56@gmx.de> References: <1415932905.511130758@apps.rackspace.com> To: dpreed@reed.com X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:1NTwhLH3EJGec1TW8hEQyC9umR2Ixb2hlKywyAsMdpR1lw/v9jn efVuE/DzmJbGavTuBe+NibgB6C8EJyeewct5xe0aRYHn3fi5WmrrCooY7fjmT7WO9rD9OPK Yg5kpVhe9olbhcD2imJZQ6NiM02DK2otMz59X0Pf0Qs9zPP6KwFcwluEfioddbFEL8Tmvxw baV8jP58e5lcBqdrZejBQ== X-UI-Out-Filterresults: notjunk:1; Cc: david.black@emc.com, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better 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: Fri, 14 Nov 2014 14:15:13 -0000 Hi David, On Nov 14, 2014, at 03:41 , dpreed@reed.com wrote: > The IETF used to require rough consensus and *working code*. The = latter seems to be out of fashion - especially with a zillion code = points for which no working code has been produced, and worse yet, no = real world testing has demonstrated any value whatsoever. > =20 > It's also true that almost no actual agreements exist at peering = points about what to do at those points. That's why diffserv appears to = be a lot of energy wasted on something that has little to do with = inter-networking. > =20 > "intserv" was a plausible idea, because within a vertically integrated = system, one can enforce regularity and consistency. > =20 > So my view, for what it is worth, is that there are a zillion better = things to put effort into than incorporating diffserv into CeroWRT! Well for cerowrt=92s egress queue it is nice to be able to = select the priority by modifying the DS bits of the packet as some = applications can do this directly; the alternative (bear with me here I = am a layman) would be deep packet inspection at the router with the = problem that even without that the wndrs are having a hard time routing = current link speeds even without needing to perform DPI plus I have no = idea how to DPI an encrypted connection. So I think that the use of the = DS bits inside cerowrt is justified for cero=92s core job as a home = router. Whether implementing the full DS set is needed of whether the 15 = DS bits per browser will help anything is a different question, but = sincere we want to handle the bits already it should not be too much = work. (For the current SQM system we need to switch DS to queue mapping = from independent tc filter invocations to a hashed filter as we run to = many filters already and then the only additional work will be mapping = 64 codes to 3 queues instead of just 8 or so ;) ) > =20 > Cui bono? > =20 >=20 >=20 > On Thursday, November 13, 2014 12:26pm, "Dave Taht" = said: >=20 > > This appears to be close to finalization, or finalized: > >=20 > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > >=20 > > And this is complementary: > >=20 > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > >=20 > > While wading through all this is tedious, and much of the advice = contradictory, > > there are a few things that could be done more right in the sqm = system > > that I'd like to discuss. (feel free to pour a cup of coffee and = read > > the drafts) > >=20 > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am = I > > the last person that uses ssh or plays games? > >=20 > > 0) Key to this draft is expecting that the AF code points on a = single > > 5-tuple not be re-ordered, which means dumping AF41 into a priority > > queue and AF42 into the BE queue is incorrect. > >=20 > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > > which I had tools doing classification, like ssh). Doing so with tc > > rules is very inefficient presently. I had basically planned on > > rolling a new tc and/or iptables filter to "do the right thing" to = map > > into all 64 codepoints via a simple lookup table (as what is in the > > wifi code already), rather than use the existing mechanism... and > > hesitated > > as nobody had nailed down the definitions of each one. > >=20 > > That said, I have not measured recently the impact of the extra tc > > filters and iptables rules required. > >=20 > > 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left > > over from my test patches against mosh - mosh ran with AF42 for a > > while until they crashed a couple routers with it) > >=20 > > The relevant lines are here: > >=20 > > = https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/fil= es/usr/lib/sqm/functions.sh#L411 > >=20 > > 1b) The cake code presently does it pretty wrong, which is eminately = fixable. > >=20 > > 1c) And given that the standards are settling, it might be time to > > start baking them into a new tc or iptables filter. This would be a > > small, interesting project for someone who wants to get their feet = wet > > writing this sort of thing, and examples abound of how to do it. > >=20 > > 2) A lot of these diffserv specs - notably all the AFxx codepoints - > > are all about variable drop probability. (Not that this concept has > > been proven to work in the real world) We don't do variable drop > > probability... and I haven't the slightest clue as to how to do it = in > > fq_codel. But keeping variable diffserv codepoints in order on the > > same 5 tuple seems to be the way things are going. Still I have > > trouble folding these ideas into the 3 basic queue system fq_codel > > uses, it looks to me as most of the AF codepoints end up in the > > current best effort queue, as the priority queue is limited to 30% = of > > the bandwidth by default. > >=20 > >=20 > > 3) Squashing inbound dscp should still be the default option... > >=20 > > 4) My patch set to the wifi code for diffserv support disables the = VO > > queue almost entirely in favor of punting things to the VI queue > > (which can aggregate), but I'm not sure if I handled AFxx > > appropriately. > >=20 > > 5) So far as I know, no browser implements any of this stuff yet. So > > far as I know nobody actually deployed a router that tries to do = smart > > things with this stuff yet. > >=20 > > 6) I really wish there were more codepoints for background traffic = than cs1. > >=20 > > -- > > Dave T=E4ht > >=20 > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel