From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 7B24221F520 for ; Fri, 14 Nov 2014 13:40:14 -0800 (PST) Received: from hms-beagle.home.lan ([91.50.109.48]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MNZ9u-1XvR0h3VZy-007C9M; Fri, 14 Nov 2014 22:39:49 +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: Fri, 14 Nov 2014 22:39:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <274D66B7-C98A-456E-855B-6C40D372007B@gmx.de> References: To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:1dmdlF++17lwN6GVzADacqsW0Ndv2Wz0auqLHvWp7Ro9N0q/x11 DL4F93CVyMKtwA+0Pg1hToFdfPAnZ04MnGejkrFQsGuv128Tl6+10h6cn2mnVHH/f8H12wc yc0MqoWBAkUatm+qZz62IDN8ZwNa9HPuT5RZZEiO4wmmNjLZT1oiv9WcCUGZH3/bI6wL5S9 0zVL+KGazvFdDGW1AYYVQ== 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 21:40:43 -0000 Hi David, On Nov 14, 2014, at 21:49 , Black, David wrote: >> 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 ingres >=20 > "so far empty" ... not exactly ... AFxx and EF use those bits: >=20 > = http://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-reg= istry-1 Well, I guess I forgot the smiley face there. But looking at = information I just learned from the intercom RFC you referenced: if the = core really only has room for 3bits of DS marking can the edge actually = expect to use more than three bits of DS marking in a meaningful way? = Thanks for the link that helps me bait to understand the beauty of DSCP, = including that none intended to use of 64 concurrent code points ;) = (only 32 of which 10 seem not assigned yet). in that light the 15 = proposed code points for browsers spann half the standard pool (actually = rather 68%) using the diffserv =93dynamic range=94 quite well. I think I = start to realize that there is basically one chance to change browser = marking behaviour and it is much easier to map down to fewer priority = queues than it is to introduce new =93standard=94 marking later (heck it = will probably tricky enough to get the proposed scheme implemented in = all popular dowsers in a timely fashion). >=20 >> 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. >=20 > The core should be mapping edge markings to core markings and then to = some > sort of edge marking at the far edge. =20 Sure, but with only 3 bits worth of core marking space, the = egress marking will also just contain 8 combinations (unless a side = channel to transfer the original marking or DPI is used in addition to = the existing core markings). But this is really not my area of expertise = as I have amply shown... > I'd prefer to view terms like "squash" > and "shift" as implementation-specific decisions about how to do those = mappings. I happily agree, mapping is a more general term, so no more = squashing just "map to zero=94 ;) >=20 > DiffServ allows implementers and network operators to do what they = want with > DSCPs, with the exception of the CSx DSCPs (details are in RFC 2474, = some of > which are already in this discussion). But the =93do what they want part=94 is what makes using DSCPs = across network boundaries so taxing/frustrating as even my EF marked = packets might end up in my ISPs scavenger class=85 (First allowed "map = to zero=94 followed by a DPI based new marking, I think that would be = RFC conform)... Best Regards Sebastian >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Sebastian Moeller [mailto:moeller0@gmx.de] >> Sent: Friday, November 14, 2014 3:36 PM >> To: Black, David >> Cc: Dave T=E4ht; cerowrt-devel@lists.bufferbloat.net; = draft-ietf-tsvwg-rtcweb- >> qos@tools.ietf.org; draft-ietf-dart-dscp-rtp@tools.ietf.org >> Subject: Re: [Cerowrt-devel] tracking some diffserv related internet = drafts >> better >>=20 >> Hi Dave(s), >>=20 >> On Nov 13, 2014, at 19:45 , Black, David wrote: >>=20 >>> 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/ >>=20 >> 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. >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=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 >=20