From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by huchra.bufferbloat.net (Postfix) with ESMTP id 7D13F202102 for ; Fri, 1 Mar 2013 10:29:52 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r21ITpSB001857 for ; Fri, 1 Mar 2013 13:29:51 -0500 Received: (qmail 21423 invoked by uid 0); 1 Mar 2013 18:29:47 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.121.62) by 0 with ESMTPA; 1 Mar 2013 18:29:47 -0000 Message-ID: <5130F396.2010003@mti-systems.com> Date: Fri, 01 Mar 2013 13:29:42 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Matt Mathis References: <512F9DB5.60909@mti-systems.com> <1362077224.256114355@apps.rackspace.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bloat-announce@lists.bufferbloat.net, 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:29:52 -0000 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 theory 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 future IPPM > standard on what a network must do in order to support modern > applications at specific performance levels. Although the draft > will not specify AQM algorithms at all, it will forbid some 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 our current AQM algorithms > are 100% correct. I like 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 long 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 too hard, and also to burn off any possible ambiguities in the descriptions of the algorithms, catch any corner cases, etc. > For this reason it is important to deploy your favorite algorithm(s) > ASAP, because they are all infinitely better than none, and future > improvements will be relatively minor by comparison. > Agreed, with the caveat that not *all* conceivable algorithms are good :). One of the things I think might be useful rather than (or in addition to) specifying algorithms, is specifying test setups or metrics that allow any algorithm to be checked for sanity, as a black box. -- Wes Eddy MTI Systems