From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1F12421F4FF for ; Fri, 14 Nov 2014 11:48:51 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAEJmghe029749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 14:48:43 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sAEJmghe029749 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1415994524; bh=A1Ng8hGNMGMhEtIWlLoG7F6r0hw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=aoXBSbpl+2mmctdUwaCN2tP1lSlRKtubkK93YHPPs0H7wv+c+zR2XkwycCIHjv/kN c2NxZlv9/WO4Pz+itNSW5XFCFmX/gX98Qn1IJem/QUxUiCMuiN5JvrPU6sv9PsKiJk VFaIATbesP/D3MKfXd2EJ2GFPgn+0YjI7pjT146A= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sAEJmghe029749 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd05.lss.emc.com (RSA Interceptor); Fri, 14 Nov 2014 14:48:07 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAEJmKPA016627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 14:48:20 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 14 Nov 2014 14:48:20 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 14:48:20 -0500 From: "Black, David" To: Sebastian Moeller Thread-Topic: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better Thread-Index: AQHP/2cOjiFA8lEmz0O4osjNt6jcwpxfvhKAgADBmICAAAg/gA== Date: Fri, 14 Nov 2014 19:48:19 +0000 Message-ID: References: <1415932905.511130758@apps.rackspace.com> <377184B7-768D-477D-97FF-6813113E3C56@gmx.de> In-Reply-To: <377184B7-768D-477D-97FF-6813113E3C56@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.34.190] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: "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 19:49:20 -0000 Replying to Sebastian's shorter message first ;-). > Well for cerowrt's 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 t= he > wndrs are having a hard time routing current link speeds even without nee= ding > 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's = core > job as a home router. +1 - while that sort of DPI is done today (although I suspect that speciali= zed middleboxes are more common than router integration), the encryption backla= sh to use and abuse of DPI (and other technologies) is only just beginning ... ... and please keep cc:'ing me, as I'm not on the cerowrt-devel list ... Thanks, --David > -----Original Message----- > From: Sebastian Moeller [mailto:moeller0@gmx.de] > Sent: Friday, November 14, 2014 9:15 AM > To: dpreed@reed.com > Cc: Dave T=E4ht; Black, David; cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] SQM: tracking some diffserv related internet > drafts better >=20 > Hi David, >=20 > On Nov 14, 2014, at 03:41 , dpreed@reed.com wrote: >=20 > > The IETF used to require rough consensus and *working code*. The latte= r > seems to be out of fashion - especially with a zillion code points for wh= ich > no working code has been produced, and worse yet, no real world testing h= as > demonstrated any value whatsoever. > > > > 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 lo= t of > energy wasted on something that has little to do with inter-networking. > > > > "intserv" was a plausible idea, because within a vertically integrated > system, one can enforce regularity and consistency. > > > > So my view, for what it is worth, is that there are a zillion better th= ings > to put effort into than incorporating diffserv into CeroWRT! >=20 > Well for cerowrt's 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 t= he > wndrs are having a hard time routing current link speeds even without nee= ding > 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's = 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 ques= tion, > 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 fi= lters > already and then the only additional work will be mapping 64 codes to 3 q= ueues > instead of just 8 or so ;) ) >=20 > > > > Cui bono? > > > > > > > > On Thursday, November 13, 2014 12:26pm, "Dave Taht" > said: > > > > > This appears to be close to finalization, or finalized: > > > > > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > > > > > And this is complementary: > > > > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > > > > > > 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 syste= m > > > that I'd like to discuss. (feel free to pour a cup of coffee and read > > > the drafts) > > > > > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am = I > > > the last person that uses ssh or plays games? > > > > > > 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. > > > > > > 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 ma= p > > > 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. > > > > > > That said, I have not measured recently the impact of the extra tc > > > filters and iptables rules required. > > > > > > 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) > > > > > > The relevant lines are here: > > > > > > https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm- > scripts/files/usr/lib/sqm/functions.sh#L411 > > > > > > 1b) The cake code presently does it pretty wrong, which is eminately > fixable. > > > > > > 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 we= t > > > writing this sort of thing, and examples abound of how to do it. > > > > > > 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. > > > > > > > > > 3) Squashing inbound dscp should still be the default option... > > > > > > 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. > > > > > > 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 smar= t > > > things with this stuff yet. > > > > > > 6) I really wish there were more codepoints for background traffic th= an > cs1. > > > > > > -- > > > Dave T=E4ht > > > > > > 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