From: Wesley Eddy <wes@mti-systems.com>
To: Matt Mathis <mattmathis@google.com>
Cc: bloat-announce@lists.bufferbloat.net,
cerowrt-devel@lists.bufferbloat.net,
bloat <bloat@lists.bufferbloat.net>
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
Date: Fri, 01 Mar 2013 13:29:42 -0500 [thread overview]
Message-ID: <5130F396.2010003@mti-systems.com> (raw)
In-Reply-To: <CAH56bmCkuqWzLY1ojJYY6xjmO9hUx11YKKGQD3K0VOnJSpgS+Q@mail.gmail.com>
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 prev parent reply other threads:[~2013-03-01 18:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 15:53 [Cerowrt-devel] " Dave Taht
2013-02-28 18:11 ` [Cerowrt-devel] [Bloat] " Wesley Eddy
2013-02-28 18:47 ` dpreed
2013-02-28 19:55 ` Matt Mathis
2013-03-01 18:29 ` Wesley Eddy [this message]
2013-03-01 18:40 ` dpreed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5130F396.2010003@mti-systems.com \
--to=wes@mti-systems.com \
--cc=bloat-announce@lists.bufferbloat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=mattmathis@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox