<font face="times new roman" size="2"><p style="margin:0;padding:0;">+1</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Wesley Eddy" <wes@mti-systems.com><br />Sent: Friday, March 1, 2013 1:29pm<br />To: "Matt Mathis" <mattmathis@google.com><br />Cc: dpreed@reed.com, bloat-announce@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net<br />Subject: Re: [Bloat] [Cerowrt-devel] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6<br /><br /></p>
<div id="SafeStyles1362163222">
<p style="margin:0;padding:0;">On 2/28/2013 2:55 PM, Matt Mathis wrote:<br />> Two of the tests in my model based metrics draft (for IPPM) are for<br />> AQM (like) tests.   One we have pretty good theory for (preventing<br />> standing queues in congestion avoidance) and the other we don't<br />> (exiting from slowstart at a reasonable window).<br />> <br />> See: draft-mathis-ippm-model-based-metrics-01.txt<br />> <br />> My intent is that these tests will become part of a future IPPM<br />> standard on what a network must do in order to support modern<br />> applications at specific performance levels.     Although the draft<br />> will not specify AQM algorithms at all, it will forbid some non-AQM<br />> behaviors such as unreasonable standing queues.   To the extent that<br />> it gets traction as a standard, it will strongly encourage deployment,<br />> even if we are not totally convinced that our current AQM algorithms<br />> are 100% correct.<br /><br /><br />I like the idea.<br /><br /><br />> However, It is not clear that we need to standardize AQM - It strikes<br />> me as one area where we can permit pretty much unfettered diversity in<br />> the operational Internet as long as it meets a pretty low  "it seems<br />> to work" bar.<br /><br /><br />Fully agreed!  Publishing specs is only useful to get some<br />known-good algorithm(s) that folks can safely implement<br />without thinking too hard, and also to burn off any possible<br />ambiguities in the descriptions of the algorithms, catch any<br />corner cases, etc.<br /><br /><br />> For this reason it is important to deploy your favorite algorithm(s)<br />> ASAP, because they are all infinitely better than none, and future<br />> improvements will be relatively minor by comparison.<br />> <br /><br /><br />Agreed, with the caveat that not *all* conceivable algorithms<br />are good :).  One of the things I think might be useful rather<br />than (or in addition to) specifying algorithms, is specifying<br />test setups or metrics that allow any algorithm to be checked<br />for sanity, as a black box.<br /><br />-- <br />Wes Eddy<br />MTI Systems</p>
</div></font>