From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3AD7C21F2D4 for ; Thu, 13 Nov 2014 18:41:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B9E6A3801ED; Thu, 13 Nov 2014 21:41:45 -0500 (EST) X-Virus-Scanned: OK Received: from app24.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 92D9C3801E2; Thu, 13 Nov 2014 21:41:45 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app24.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Fri, 14 Nov 2014 02:41:45 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app24.wa-webapps.iad3a (Postfix) with ESMTP id 7D44780012; Thu, 13 Nov 2014 21:41:45 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 13 Nov 2014 21:41:45 -0500 (EST) Date: Thu, 13 Nov 2014 21:41:45 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20141113214145000000_38836" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Auth-ID: dpreed@reed.com Message-ID: <1415932905.511130758@apps.rackspace.com> X-Mailer: webmail7.0 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 02:42:15 -0000 ------=_20141113214145000000_38836 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe IETF used to require rough consensus and *working code*. The latter= seems to be out of fashion - especially with a zillion code points for whi= ch no working code has been produced, and worse yet, no real world testing = has demonstrated any value whatsoever.=0A =0AIt'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 tha= t has little to do with inter-networking.=0A =0A"intserv" was a plausible i= dea, because within a vertically integrated system, one can enforce regular= ity and consistency.=0A =0ASo my view, for what it is worth, is that there = are a zillion better things to put effort into than incorporating diffserv = into CeroWRT!=0A =0ACui bono?=0A =0A=0A=0AOn Thursday, November 13, 2014 12= :26pm, "Dave Taht" said:=0A=0A=0A=0A> This appears to= be close to finalization, or finalized:=0A> =0A> http://tools.ietf.org/htm= l/draft-ietf-dart-dscp-rtp-10=0A> =0A> And this is complementary:=0A> =0A> = http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03=0A> =0A> While wa= ding through all this is tedious, and much of the advice contradictory,=0A>= there are a few things that could be done more right in the sqm system=0A>= that I'd like to discuss. (feel free to pour a cup of coffee and read=0A> = the drafts)=0A> =0A> -1) They still think the old style tos imm bit is obso= lete. Sigh. Am I=0A> the last person that uses ssh or plays games?=0A> =0A>= 0) Key to this draft is expecting that the AF code points on a single=0A> = 5-tuple not be re-ordered, which means dumping AF41 into a priority=0A> que= ue and AF42 into the BE queue is incorrect.=0A> =0A> 1) SQM only prioritize= s a few diffserv codepoints (just the ones for=0A> which I had tools doing = classification, like ssh). Doing so with tc=0A> rules is very inefficient p= resently. I had basically planned on=0A> rolling a new tc and/or iptables f= ilter to "do the right thing" to map=0A> into all 64 codepoints via a simpl= e lookup table (as what is in the=0A> wifi code already), rather than use t= he existing mechanism... and=0A> hesitated=0A> as nobody had nailed down th= e definitions of each one.=0A> =0A> That said, I have not measured recently= the impact of the extra tc=0A> filters and iptables rules required.=0A> = =0A> 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left=0A= > over from my test patches against mosh - mosh ran with AF42 for a=0A> whi= le until they crashed a couple routers with it)=0A> =0A> The relevant lines= are here:=0A> =0A> https://github.com/dtaht/ceropackages-3.10/blob/master/= net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411=0A> =0A> 1b) The cake c= ode presently does it pretty wrong, which is eminately fixable.=0A> =0A> 1c= ) And given that the standards are settling, it might be time to=0A> start = baking them into a new tc or iptables filter. This would be a=0A> small, in= teresting project for someone who wants to get their feet wet=0A> writing t= his sort of thing, and examples abound of how to do it.=0A> =0A> 2) A lot o= f these diffserv specs - notably all the AFxx codepoints -=0A> are all abou= t variable drop probability. (Not that this concept has=0A> been proven to = work in the real world) We don't do variable drop=0A> probability... and I = haven't the slightest clue as to how to do it in=0A> fq_codel. But keeping = variable diffserv codepoints in order on the=0A> same 5 tuple seems to be t= he way things are going. Still I have=0A> trouble folding these ideas into = the 3 basic queue system fq_codel=0A> uses, it looks to me as most of the A= F codepoints end up in the=0A> current best effort queue, as the priority q= ueue is limited to 30% of=0A> the bandwidth by default.=0A> =0A> =0A> 3) Sq= uashing inbound dscp should still be the default option...=0A> =0A> 4) My p= atch set to the wifi code for diffserv support disables the VO=0A> queue al= most entirely in favor of punting things to the VI queue=0A> (which can agg= regate), but I'm not sure if I handled AFxx=0A> appropriately.=0A> =0A> 5) = So far as I know, no browser implements any of this stuff yet. So=0A> far a= s I know nobody actually deployed a router that tries to do smart=0A> thing= s with this stuff yet.=0A> =0A> 6) I really wish there were more codepoints= for background traffic than cs1.=0A> =0A> --=0A> Dave T=C3=A4ht=0A> =0A> t= http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks=0A> _________= ______________________________________=0A> Cerowrt-devel mailing list=0A> C= erowrt-devel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listin= fo/cerowrt-devel=0A> ------=_20141113214145000000_38836 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The IETF used to require= rough consensus and *working code*.  The latter seems to be out of fa= shion - especially with a zillion code points for which no working code has= been produced, and worse yet, no real world testing has demonstrated any v= alue whatsoever.

=0A

 

=0A

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 o= f energy wasted on something that has little to do with inter-networking.=0A

 

=0A

"intserv" was a plaus= ible idea, because within a vertically integrated system, one can enforce r= egularity and consistency.

=0A

 

=0A

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!

=0A=

 

=0A

Cui bono?

=0A

 

=0A=0A



On Thursday, November 13, 2014= 12:26pm, "Dave Taht" <dave.taht@gmail.com> said:

=0A<= div id=3D"SafeStyles1415932624">=0A

> This appears to b= e close to finalization, or finalized:
>
> http://tools.ie= tf.org/html/draft-ietf-dart-dscp-rtp-10
>
> And this is co= mplementary:
>
> http://tools.ietf.org/html/draft-ietf-tsv= wg-rtcweb-qos-03
>
> While wading through all this is tedi= ous, 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)=
>
> -1) They still think the old style tos imm bit is obs= olete. Sigh. Am I
> the last person that uses ssh or plays games?>
> 0) Key to this draft is expecting that the AF code poin= ts on a single
> 5-tuple not be re-ordered, which means dumping AF4= 1 into a priority
> queue and AF42 into the BE queue is incorrect.<= br />>
> 1) SQM only prioritizes a few diffserv codepoints (jus= t the ones for
> which I had tools doing classification, like ssh).= Doing so with tc
> rules is very inefficient presently. I had basi= cally planned on
> rolling a new tc and/or iptables filter to "do t= he 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 nail= ed down the definitions of each one.
>
> That said, I have= not measured recently the impact of the extra tc
> filters and ipt= ables rules required.
>
> 1a) Certainly only doing AF42 in= sqm is pretty wrong (that was left
> over from my test patches aga= inst mosh - mosh ran with AF42 for a
> while until they crashed a c= ouple routers with it)
>
> The relevant lines are here:>
> https://github.com/dtaht/ceropackages-3.10/blob/master/n= et/sqm-scripts/files/usr/lib/sqm/functions.sh#L411
>
> 1b)= The cake code presently does it pretty wrong, which is eminately fixable.<= br />>
> 1c) And given that the standards are settling, it migh= t 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 ab= ound 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 th= e real world) We don't do variable drop
> probability... and I have= n't the slightest clue as to how to do it in
> fq_codel. But keepin= g variable diffserv codepoints in order on the
> same 5 tuple seems= to be the way things are going. Still I have
> trouble folding the= se 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 effor= t queue, as the priority queue is limited to 30% of
> the bandwidth= by default.
>
>
> 3) Squashing inbound dscp shou= ld still be the default option...
>
> 4) My patch set to t= he wifi code for diffserv support disables the VO
> queue almost en= tirely in favor of punting things to the VI queue
> (which can aggr= egate), but I'm not sure if I handled AFxx
> appropriately.
&g= t;
> 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 trie= s to do smart
> things with this stuff yet.
>
> 6)= I really wish there were more codepoints for background traffic than cs1.<= br />>
> --
> Dave T=C3=A4ht
>
> thttp= ://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______= ________________________________________
> Cerowrt-devel mailing li= st
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bu= fferbloat.net/listinfo/cerowrt-devel
>

=0A ------=_20141113214145000000_38836--