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 7088F21F3C6 for ; Fri, 14 Nov 2014 14:01:39 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAEM1SEE020416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 17:01:30 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAEM1SEE020416 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1416002490; bh=CG5QPhuLU8mNuMPetyzVlj8/JQk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YWQffR2dEyAlQTnMyLHufP6wrrq4Zbku0mTR/vnVqedsDzTkvPtBAFM5z8Qtfo0CE 0cEzEci9mC9uqVU5dhowhah0JYBOOK+xzd/ng7qwBMa9hpZ5RPDUZhULHtSeZCKNGq xT6ein39UXYFtvPg/KXp1NHbGk7JimduPUQ5HfAk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sAEM1SEE020416 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 17:01:00 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAEM1CCZ021188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 17:01:13 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub16.corp.emc.com (128.222.70.237) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 14 Nov 2014 17:01:12 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 17:01:12 -0500 From: "Black, David" To: Sebastian Moeller Thread-Topic: [Cerowrt-devel] tracking some diffserv related internet drafts better Thread-Index: AQHP/2cOjiFA8lEmz0O4osjNt6jcwpxe2mvwgAIP5ID//65hEIAAY1aA//+uTlA= Date: Fri, 14 Nov 2014 22:01:11 +0000 Message-ID: References: <274D66B7-C98A-456E-855B-6C40D372007B@gmx.de> In-Reply-To: <274D66B7-C98A-456E-855B-6C40D372007B@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.39.200] 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: DLM_1, public Cc: "Black, David" , "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 22:02:08 -0000 Hi Sebastian, > 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 o= nly > 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? That is one of the open issues on the tsvwg-rtcweb-qos draft ;-). The situation in network cores varies: - MPLS-based: About 2 bits is all that's really widely possible. The MPLS = TC field that supports this is 3 bits, but has other uses. - IP-based carrier: Harder to say, but 3 bits is a good guesstimate. There was a lot of 3-bit IP Precedence support prior to RFC 2474 - that corresponds to the 8 class selector codepoints, and every additional DSCP used has network config and management cost. - IP-based Enterprise: Ditto on pre-RFC-2474 IP Precedence, but there seems to be more flexibility here. Even so, if I take all the traffic classes in RFC 4594, plus add an admission-controlled telephony/voice class (RFC 5865) I still wind up somewhere around 4 bits, and most networks will implement a subset of those classes, not all of them. > I think I start to realize that there is basically one chance to change b= rowser > marking behaviour and it is much easier to map down to fewer priority que= ues > than it is to introduce new "standard" marking later (heck it will probab= ly > tricky enough to get the proposed scheme implemented in all popular dowse= rs in > a timely fashion). Yes - WebRTC is expected to provide significant encouragement for browser a= doption. > But the "do what they want part" is what makes using DSCPs across > network boundaries so taxing/frustrating as even my EF marked packets mig= ht > end up in my ISPs scavenger class. (First allowed "map to zero" followed = by a > DPI based new marking, I think that would be RFC conform)... Indeed it would be, and draft-geib-tsvwg-diffserv-intercon is intended as a first step towards encouraging something better at network boundaries. Thanks, --David > -----Original Message----- > From: Sebastian Moeller [mailto:moeller0@gmx.de] > Sent: Friday, November 14, 2014 4:40 PM > To: Black, David > Cc: Dave T=E4ht; cerowrt-devel@lists.bufferbloat.net; draft-ietf-tsvwg-rt= cweb- > qos@tools.ietf.org; draft-ietf-dart-dscp-rtp@tools.ietf.org > Subject: Re: [Cerowrt-devel] tracking some diffserv related internet draf= ts > better >=20 > Hi David, >=20 > On Nov 14, 2014, at 21:49 , Black, David wrote: >=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 ingres > > > > "so far empty" ... not exactly ... AFxx and EF use those bits: > > > > http://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp- > registry-1 >=20 > 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 o= nly > 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 he= lps > 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 ye= t). > in that light the 15 proposed code points for browsers spann half the sta= ndard > pool (actually rather 68%) using the diffserv "dynamic range" quite well.= I > think I start to realize that there is basically one chance to change bro= wser > marking behaviour and it is much easier to map down to fewer priority que= ues > than it is to introduce new "standard" marking later (heck it will probab= ly > tricky enough to get the proposed scheme implemented in all popular dowse= rs in > a timely fashion). >=20 > > > >> and back > >> to 0-2 on egress and each can do their own thing. On the other hand, i= f 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. > > > > The core should be mapping edge markings to core markings and then to s= ome > > 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... >=20 > > I'd prefer to view terms like "squash" > > and "shift" as implementation-specific decisions about how to do those > mappings. >=20 > I happily agree, mapping is a more general term, so no more squashing > just "map to zero" ;) >=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, so= me of > > which are already in this discussion). >=20 > But the "do what they want part" is what makes using DSCPs across > network boundaries so taxing/frustrating as even my EF marked packets mig= ht > end up in my ISPs scavenger class. (First allowed "map to zero" followed = by a > DPI based new marking, I think that would be RFC conform)... >=20 > Best Regards > Sebastian >=20 > > > > Thanks, > > --David > > > > > >> -----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 d= rafts > >> better > >> > >> Hi Dave(s), > >> > >> On Nov 13, 2014, at 19:45 , Black, David wrote: > >> > >>> Dave (T), > >>> > >>>> 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 > >>> > >>> The dart-dscp-rtp draft is now done and in the RFC Editor's Queue. > >>> > >>> 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 so= on: > >>> > >>> 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 an= d > back > >> to 0-2 on egress and each can do their own thing. On the other hand, i= f 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 > >> > >> > >>> > >>> > >>>> -1) They still think the old style tos imm bit is obsolete. Sigh. Am= I > >>>> the last person that uses ssh or plays games? > >>> > >>> See RFC 2474, published in 1998 ... > >>> > >>>> 0) Key to this draft is expecting that the AF code points on a singl= e > >>>> 5-tuple not be re-ordered, which means dumping AF41 into a priority > >>>> queue and AF42 into the BE queue is incorrect. > >>> > >>> Yes. That's supposed to be the case for any AF PHB group that's > >>> supported., e.g., AF3x [AF31, AF32 and AF33]. > >>> > >>> https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > >>> > >>>> 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 w= et > >>>> writing this sort of thing, and examples abound of how to do it. > >>> > >>> 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. > >>> > >>>> 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 i= n > >>>> fq_codel. But keeping variable diffserv codepoints in order on the > >>>> same 5 tuple seems to be the way things are going. > >>> > >>> That's UDP-only at the moment if that helps. Variable drop probabili= ty > >>> doesn't do anything useful for TCP, and there's no good experience > >>> with other congestion controlled transports - see the dart-dscp-rtp > >>> draft. > >>> > >>>> 3) Squashing inbound dscp should still be the default option... > >>> > >>> 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 ... > >>> > >>>> 6) I really wish there were more codepoints for background traffic t= han > >> cs1. > >>> > >>> It's worse than that - CS1 may or may not be a background codepoint, > >>> see the dart-dscp-rtp draft. > >>> > >>> Thanks, > >>> --David > >>> > >>>> -----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 > >>>> > >>>> 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 syst= em > >>>> that I'd like to discuss. (feel free to pour a cup of coffee and rea= d > >>>> 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 singl= e > >>>> 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 m= ap > >>>> 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 w= et > >>>> 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 i= n > >>>> 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% o= f > >>>> 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 V= O > >>>> 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 sma= rt > >>>> things with this stuff yet. > >>>> > >>>> 6) I really wish there were more codepoints for background traffic t= han > >> 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 > >