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 5417B21F30D for ; Fri, 14 Nov 2014 12:36:51 -0800 (PST) Received: from hms-beagle.home.lan ([91.50.109.48]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LoKHN-1YVc6y1xub-00gFYl; Fri, 14 Nov 2014 21:36:25 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 14 Nov 2014 21:36:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:jqG4wc5xgDDxaCkBFO5MfBK3NNhTYKoRDHhi2Fob+0wAPd/FSAG AoNd1XVizQn3TqnEP4lzFMnsU/VIklw3R0U4kGPpsY3ssqsF/vSR9tKb6s4YPhh6Zx5ZtfW fv2Wlct878xYtifwnIdL73EES0OzuN1hFiaI8oeqhMetThzjDTYbTxhK4ir5dPR55ga2tJ5 +Xw+3rNgEGZvmrJ94PrBQ== X-UI-Out-Filterresults: notjunk:1; Cc: "draft-ietf-tsvwg-rtcweb-qos@tools.ietf.org" , "draft-ietf-dart-dscp-rtp@tools.ietf.org" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] 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 20:37:21 -0000 Hi Dave(s), On Nov 13, 2014, at 19:45 , Black, David wrote: > Dave (T), >=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 > The dart-dscp-rtp draft is now done and in the RFC Editor's Queue. >=20 > The tsvwg-rtcweb-qos draft is still a work in progress, and its > aggressive use of almost every PHB and DSCP is a concern. Here's > another related draft that is likely to be adopted by the tsvwg WG = soon: >=20 > https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ I could be completely off my rocker, but that scheme would work = perfectly if the edge and the core would use 3 bits each max then the = core can just move the edge bits 0-2 to the so far empty bits 3-5 on = ingress and back to 0-2 on egress and each can do their own thing. On = the other hand, if the core does not actually use the edge markings then = it could also jus ts quash them nd the edge would not be any wiser. Best Regards Sebastian >=20 >=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 > See RFC 2474, published in 1998 ... >=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 > Yes. That's supposed to be the case for any AF PHB group that's > supported., e.g., AF3x [AF31, AF32 and AF33]. >=20 > https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ >=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 > I'm happy to help w/insight, advice etc. - please ask. In turn, > experience w/what's more vs. less likely to work where and why would > be quite useful, e.g., for the tsvwg-rtcweb-qos draft. >=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. >=20 > That's UDP-only at the moment if that helps. Variable drop = probability > doesn't do anything useful for TCP, and there's no good experience > with other congestion controlled transports - see the dart-dscp-rtp > draft. >=20 >> 3) Squashing inbound dscp should still be the default option... >=20 > Yes, very common out there. See the tsvwg-diffserv-intercon draft > which is trying to specify a few small holes to punch into that > "squash to zero" default ingress DSCP behavior. Yes, I'm an > optimist ... >=20 >> 6) I really wish there were more codepoints for background traffic = than cs1. >=20 > It's worse than that - CS1 may or may not be a background codepoint, > see the dart-dscp-rtp draft. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Dave Taht [mailto:dave.taht@gmail.com] >> Sent: Thursday, November 13, 2014 12:27 PM >> To: cerowrt-devel@lists.bufferbloat.net; Black, David >> Subject: SQM: tracking some diffserv related internet drafts better >>=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/files/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