[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

[dpreed at reed.com]

+1
 
-----Original Message-----
From: "Wesley Eddy" <wes at mti-systems.com>
Sent: Friday, March 1, 2013 1:29pm
To: "Matt Mathis" <mattmathis at google.com>
Cc: dpreed at reed.com, bloat-announce at lists.bufferbloat.net, "bloat" <bloat at lists.bufferbloat.net>, cerowrt-devel at lists.bufferbloat.net
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



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130301/4da9070f/attachment-0003.html>