From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp107.iad3a.emailsrvr.com (smtp107.iad3a.emailsrvr.com [173.203.187.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 88EF23B29E for ; Sun, 3 Feb 2019 17:42:09 -0500 (EST) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5774A2391F; Sun, 3 Feb 2019 17:42:09 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 52E4823ACA; Sun, 3 Feb 2019 17:42:09 -0500 (EST) Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3D8622391F; Sun, 3 Feb 2019 17:42:09 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 03 Feb 2019 17:42:09 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app39.wa-webapps.iad3a (Postfix) with ESMTP id 2B57220047; Sun, 3 Feb 2019 17:42:09 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 3 Feb 2019 17:42:09 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Sun, 3 Feb 2019 17:42:09 -0500 (EST) From: "David P. Reed" To: "Dave Taht" Cc: "cerowrt-devel" , "Cake List" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: Message-ID: <1549233729.17269312@apps.rackspace.com> X-Mailer: webmail/15.4.8-RC Subject: Re: [Cake] [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 22:42:09 -0000 Well, you all know that I think of diffserv as an abortion. It's based on t= hinking that assumes central, hierachical adminstrative agreements among wh= at should be autonomous systems.=0A=0AYeah, at layer 2 for packets that sta= y within an administratively uniform domain, diffserv can be useful.=0A=0AB= ut even "Paris Metro" scheduling (2 classes, priced dynamically) is highly = unstable.=0A=0AAnd the nature of networks is that they MUST operate almost = all the time well below their capacity. (This is true of packet nets, railr= oads, highways, ...). It's called the "Mother's Day problem". When Mother's= Day happens, you should have enough capacity to absorb vast demand. Theref= ore what you do all the other days doesn't matter. And on Mother's Day, if = you have congestion, there's no way in hell that anybody is happy.=0A=0AThi= s fairy story about traffic giving way to higher priority traffic being a n= ormal mode of operation is just that. A made up story, largely used by folk= s who want to do selective pricing based on what customers are willing to p= ay, not on value received. (that's a business story, thouhg - like the Xero= x machines that were supposed to charge more for billion dollar real estate= contract copies and less for notices to put up near coffee machines - Xero= x wanted a share of the real-estate business cash flow).=0A=0AWhich doesn't= mean that there might not be better ways to do large scale traffic enginee= ring balancing of flows - but that's not an end-to-end problem. It's a netw= ork management problem that involves changing routing tables.=0A=0A-----Ori= ginal Message-----=0AFrom: "Dave Taht" =0ASent: Sunday= , February 3, 2019 1:39pm=0ATo: "cerowrt-devel" , "Cake List" =0ASubject: [Cerowrt-de= vel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call= =0A=0AAnd seems likely to be adopted.=0A=0AThere seems to be an urge to mak= e this codepoint starvable, which=0Asince I ascribe to nagle's dictum "ever= y application has a right to=0Aone packet in the network" - doesn't work fo= r me - but the draft is=0Avaguely worded enough to just start dumping this = codepoint into the=0Abackground queue of both sqm and cake and worry about = it in a decade=0Aor three.=0A=0Ait's 000001 which I guess is:=0A=0Adiff --g= it a/sch_cake.c b/sch_cake.c=0Aindex 3a26db0..67263b3 100644=0A--- a/sch_ca= ke.c=0A+++ b/sch_cake.c=0A@@ -343,7 +343,7 @@ static const u8 diffserv4[] = =3D {=0A };=0A=0A static const u8 diffserv3[] =3D {=0A- 0, 0, 0, 0, 2= , 0, 0, 0,=0A+ 0, 1, 0, 0, 2, 0, 0, 0,=0A 1, 0, 0, 0, 0, 0, 0,= 0,=0A 0, 0, 0, 0, 0, 0, 0, 0,=0A 0, 0, 0, 0, 0, 0, 0, 0,=0A= =0A(or is that reversed? my big endian/little endian chops scuks, and=0Anob= ody modified the gen_cake_const tool to match what cake expects=0Anow)=0A= =0Aon my off days I kind of wish the diffserv lookup we do in cake had=0Ama= naged to make it into the linux mqprio/prio stuff by default.=0A=0A-- =0A= =0ADave T=C3=A4ht=0ACTO, TekLibre, LLC=0Ahttp://www.teklibre.com=0ATel: 1-8= 31-205-9740=0A_______________________________________________=0ACerowrt-dev= el mailing list=0ACerowrt-devel@lists.bufferbloat.net=0Ahttps://lists.buffe= rbloat.net/listinfo/cerowrt-devel=0A