From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp171.iad.emailsrvr.com (smtp171.iad.emailsrvr.com [207.97.245.171]) (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 4869D202102 for ; Fri, 1 Mar 2013 10:40:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2767CF87DA; Fri, 1 Mar 2013 13:40:27 -0500 (EST) X-Virus-Scanned: OK Received: from legacy9.wa-web.iad1a (legacy9.wa-web.iad1a.rsapps.net [192.168.4.111]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 051D0F87B6; Fri, 1 Mar 2013 13:40:26 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy9.wa-web.iad1a (Postfix) with ESMTP id DDABB1F8119; Fri, 1 Mar 2013 13:40:26 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 1 Mar 2013 13:40:26 -0500 (EST) Date: Fri, 1 Mar 2013 13:40:26 -0500 (EST) From: dpreed@reed.com To: "Wesley Eddy" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20130301134026000000_73173" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <5130F396.2010003@mti-systems.com> References: <512F9DB5.60909@mti-systems.com> <1362077224.256114355@apps.rackspace.com> <5130F396.2010003@mti-systems.com> Message-ID: <1362163226.906223387@apps.rackspace.com> X-Mailer: webmail7.0 Cc: bloat-announce@lists.bufferbloat.net, Matt Mathis , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6 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, 01 Mar 2013 18:40:28 -0000 ------=_20130301134026000000_73173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A+1=0A =0A-----Original Message-----=0AFrom: "Wesley Eddy" =0ASent: Friday, March 1, 2013 1:29pm=0ATo: "Matt Mathis" =0ACc: dpreed@reed.com, bloat-announce@lists.bufferbloat.net, = "bloat" , cerowrt-devel@lists.bufferbloat.net= =0ASubject: Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on th= e ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbea= n 6=0A=0A=0A=0AOn 2/28/2013 2:55 PM, Matt Mathis wrote:=0A> Two of the test= s in my model based metrics draft (for IPPM) are for=0A> AQM (like) tests. = One we have pretty good theory for (preventing=0A> standing queues in con= gestion avoidance) and the other we don't=0A> (exiting from slowstart at a = reasonable window).=0A> =0A> See: draft-mathis-ippm-model-based-metrics-01.= txt=0A> =0A> My intent is that these tests will become part of a future IPP= M=0A> standard on what a network must do in order to support modern=0A> app= lications at specific performance levels. Although the draft=0A> will n= ot specify AQM algorithms at all, it will forbid some non-AQM=0A> behaviors= such as unreasonable standing queues. To the extent that=0A> it gets tra= ction as a standard, it will strongly encourage deployment,=0A> even if we = are not totally convinced that our current AQM algorithms=0A> are 100% corr= ect.=0A=0A=0AI like the idea.=0A=0A=0A> However, It is not clear that we ne= ed to standardize AQM - It strikes=0A> me as one area where we can permit p= retty much unfettered diversity in=0A> the operational Internet as long as = it meets a pretty low "it seems=0A> to work" bar.=0A=0A=0AFully agreed! P= ublishing specs is only useful to get some=0Aknown-good algorithm(s) that f= olks can safely implement=0Awithout thinking too hard, and also to burn off= any possible=0Aambiguities in the descriptions of the algorithms, catch an= y=0Acorner cases, etc.=0A=0A=0A> For this reason it is important to deploy = your favorite algorithm(s)=0A> ASAP, because they are all infinitely better= than none, and future=0A> improvements will be relatively minor by compari= son.=0A> =0A=0A=0AAgreed, with the caveat that not *all* conceivable algori= thms=0Aare good :). One of the things I think might be useful rather=0Atha= n (or in addition to) specifying algorithms, is specifying=0Atest setups or= metrics that allow any algorithm to be checked=0Afor sanity, as a black bo= x.=0A=0A-- =0AWes Eddy=0AMTI Systems ------=_20130301134026000000_73173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= +1

=0A

 

=0A

-----Original Message-----
From: "Wesley Eddy" <wes@mt= i-systems.com>
Sent: Friday, March 1, 2013 1:29pm
To: "Matt Ma= this" <mattmathis@google.com>
Cc: dpreed@reed.com, bloat-announc= e@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, cerow= rt-devel@lists.bufferbloat.net
Subject: Re: [Bloat] [Cerowrt-devel] so= me good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12= 2013, 13:00-15:00, room Caribbean 6

=0A
=0A

On 2/28/2013 2:55 PM, Matt= Mathis wrote:
> Two of the tests in my model based metrics draft (= for IPPM) are for
> AQM (like) tests. One we have pretty good the= ory for (preventing
> standing queues in congestion avoidance) and = the other we don't
> (exiting from slowstart at a reasonable window= ).
>
> See: draft-mathis-ippm-model-based-metrics-01.txt>
> My intent is that these tests will become part of a fut= ure IPPM
> standard on what a network must do in order to support m= odern
> applications at specific performance levels. Although t= he draft
> will not specify AQM algorithms at all, it will forbid s= ome non-AQM
> behaviors such as unreasonable standing queues. To = the extent that
> it gets traction as a standard, it will strongly = encourage deployment,
> even if we are not totally convinced that o= ur current AQM algorithms
> are 100% correct.


I li= ke the idea.


> However, It is not clear that we need to= standardize AQM - It strikes
> me as one area where we can permit = pretty much unfettered diversity in
> the operational Internet as l= ong as it meets a pretty low "it seems
> to work" bar.

=
Fully agreed! Publishing specs is only useful to get some
known= -good algorithm(s) that folks can safely implement
without thinking to= o hard, and also to burn off any possible
ambiguities in the descripti= ons of the algorithms, catch any
corner cases, etc.


&= gt; For this reason it is important to deploy your favorite algorithm(s)> ASAP, because they are all infinitely better than none, and future<= br />> improvements will be relatively minor by comparison.
>

Agreed, with the caveat that not *all* conceivable algorith= ms
are good :). One of the things I think might be useful rather
than (or in addition to) specifying algorithms, is specifying
test se= tups or metrics that allow any algorithm to be checked
for sanity, as = a black box.

--
Wes Eddy
MTI Systems

=0A
------=_20130301134026000000_73173--