From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) (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 55B0F200203; Sat, 2 Mar 2013 11:33:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 27057E8552; Sat, 2 Mar 2013 14:33:20 -0500 (EST) X-Virus-Scanned: OK Received: from legacy11.wa-web.iad1a (legacy11.wa-web.iad1a.rsapps.net [192.168.4.97]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F3937E8550; Sat, 2 Mar 2013 14:33:19 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy11.wa-web.iad1a (Postfix) with ESMTP id DF2DA27B8001; Sat, 2 Mar 2013 14:33:19 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 2 Mar 2013 14:33:19 -0500 (EST) Date: Sat, 2 Mar 2013 14:33:19 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130302143319000000_37050" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1362252799.912230623@apps.rackspace.com> X-Mailer: webmail7.0 Cc: bloat-announce@lists.bufferbloat.net, codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] revised Codel RFC is up 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: Sat, 02 Mar 2013 19:33:21 -0000 ------=_20130302143319000000_37050 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThis is an excellent RFC. It should be issued immediately. It should a= lso be (along with fq_codel) cited as one alternative for managing queues p= roperly in a new version of a "best practices" RFC. There may be alternati= ves of similar quality, but those alternatives should have quantitative exp= erimental evidence that shows similar benefits.=0A =0AMy own personal view = of the effectiveness of IETF as an organization would be positively affecte= d by how quickly a solution goes from this to widespread deployment (includ= ing upgrades of existing defective gear) - since I have occasionally asked = to testify on the value of IETF in coordinating the Internet's evolution in= policy circles, it should be noted that much of my opinion depends on such= observations of organizational effectiveness in dealing with important pro= blems, to the extent that matters.=0A =0AIn general, my observation of the = IETF has been that it is largely dysfunctional as a vehicle for achieving i= mportant consensus that leads to problem solutions. I'm not expecting bett= er than that, but I could be surprised.=0A =0AOrganizations such as BITAG s= eem to have been invented because IETF fails. I don't think BITAG is an ap= propriate forum, as it shows no competence whatever to discuss such things = as congestion management with "clue" and experimental evidence.=0A =0AWe'll= see.=0A =0A-----Original Message-----=0AFrom: "Dave Taht" =0ASent: Saturday, March 2, 2013 1:27pm=0ATo: "bloat" , bloat-announce@lists.bufferbloat.net, cerowrt-devel@lists.bu= fferbloat.net, codel@lists.bufferbloat.net=0ASubject: [Cerowrt-devel] revis= ed Codel RFC is up=0A=0A=0A[http://tools.ietf.org/html/draft-nichols-tsvwg-= codel-01] http://tools.ietf.org/html/draft-nichols-tsvwg-codel-01=0A=0A-- = =0ADave T=C3=A4ht=0A=0AFixing bufferbloat with cerowrt: [http://www.teklibr= e.com/cerowrt/subscribe.html] http://www.teklibre.com/cerowrt/subscribe.htm= l ------=_20130302143319000000_37050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= This is an excellent RFC.  It should be issued immediately.  It s= hould also be (along with fq_codel) cited as one alternative for managing q= ueues properly in a new version of a "best practices" RFC.  There may = be alternatives of similar quality, but those alternatives should have quan= titative experimental evidence that shows similar benefits.

=0A

 

=0A

My o= wn personal view of the effectiveness of IETF as an organization would be p= ositively affected by how quickly a solution goes from this to widespread d= eployment (including upgrades of existing defective gear) - since I have oc= casionally asked to testify on the value of IETF in coordinating the Intern= et's evolution in policy circles, it should be noted that much of my opinio= n depends on such observations of organizational effectiveness in dealing w= ith important problems, to the extent that matters.

=0A

 

=0A

In general, m= y observation of the IETF has been that it is largely dysfunctional as a ve= hicle for achieving important consensus that leads to problem solutions.&nb= sp; I'm not expecting better than that, but I could be surprised.

=0A

 

=0A

Organizations such as BITAG seem to have been invented because IETF fails.=   I don't think BITAG is an appropriate forum, as it shows no competen= ce whatever to discuss such things as congestion management with "clue" and= experimental evidence.

=0A

 

= =0A

We'll see.

=0A

 

=0A

-----Original Mess= age-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Satu= rday, March 2, 2013 1:27pm
To: "bloat" <bloat@lists.bufferbloat.net= >, bloat-announce@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat= .net, codel@lists.bufferbloat.net
Subject: [Cerowrt-devel] revised Cod= el RFC is up

=0A ------=_20130302143319000000_37050--