[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
dpreed at reed.com
dpreed at reed.com
Fri Mar 1 13:40:26 EST 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel