From: Jim Gettys <jg@freedesktop.org>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] About Stochastic Fair Blue (SFB)
Date: Fri, 04 Feb 2011 08:56:51 -0500 [thread overview]
Message-ID: <4D4C05A3.3000901@freedesktop.org> (raw)
In-Reply-To: <87k4hgdte9.fsf@trurl.pps.jussieu.fr>
On 02/04/2011 04:46 AM, Juliusz Chroboczek wrote:
> Hi again,
>
> In his series of articles, Jim has concentrated on router-based
> solutions to delay issues. He mentioned AQM policies in routers, and
> notably the venerable RED.
Referred to hereafter as RED 93.
For those of you who have not waded through all the postings, RED is
often all that has been available in most Internet routers, and RED 93
won't handle the common case we face most commonly, which is 802.11.
(This is the opinion of Van Jacobson, who with Sally Floyd invented RED 93).
The reasons for this is that RED 93 can't handle the highly variable
"goodput" we see in wireless networks (and some other systems) due to
its static configuration, and Van says it's stability given the volatile
traffic mix we have in these networks also makes RED 93 hopeless.
I just want to make clear we face a problem here we can't solve with RED 93.
We have to explore our alternatives in detail.
>
> AQMs are designed to achieve two different (but not necessarily
> contradictory) goals: to improve the behaviour of the traffic (notably
> by reducing the amount of buffering, which is what we're concerned about
> here), and to improve fairness. For example, RED is mostly concerned
> with the former, while CHOKe is only concerned with the latter.
If we don't manage these insane buffers, we've lost.
>
> One AQM that attempts both is Stochastic Fair a stochastically-fair
> variant of BLUE [1]. In addition to reducing buffer size and enforcing
> rough inter-flow fairness, SFB will reliably detect unresponsive flows
> and rate-limit them.
>
> In order to experiment with SFB, I've implemented it for Linux a couple
> of years ago [2]. Unfortunately, I've given up for now on trying to get
> it into the mainline kernel, and I'm not sure I want to try again [3].
>
> --Juliusz
>
> [1] W. Feng, D. Kandlur, D. Saha, K. Shin. Blue: A New Class of Active
> Queue Management Algorithms. U. Michigan CSE-TR-387-99, April 1999.
> http://www.thefengs.com/wuchang/blue/CSE-TR-387-99.pdf
> [2] http://www.pps.jussieu.fr/~jch/software/sfb/
> [3] http://article.gmane.org/gmane.linux.network/183813
Juliusz, have you thought about the host case at all? One of the
places we're getting insane buffering is in the operating systems
themselves (e.g. the experiment I did with a 100Mbps switch). My
intuition is that we have to do AQM in hosts, not just routers.
- Jim
next prev parent reply other threads:[~2011-02-04 13:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 9:46 Juliusz Chroboczek
2011-02-04 13:56 ` Jim Gettys [this message]
2011-02-04 17:33 ` [Bloat] Buffer bloat at the sender [was: About Stochastic Fair Blue (SFB)] Juliusz Chroboczek
2011-02-04 18:24 ` Jim Gettys
2011-02-04 18:58 ` [Bloat] Buffer bloat at the sender Juliusz Chroboczek
2011-02-04 19:26 ` Dave Täht
2011-02-04 18:43 ` Dave Täht
2011-02-04 18:56 ` Juliusz Chroboczek
2011-02-04 19:58 ` Dave Täht
2011-02-04 20:14 ` Juliusz Chroboczek
2011-02-04 15:12 ` [Bloat] About Stochastic Fair Blue (SFB) Dave Täht
2011-02-04 17:41 ` Juliusz Chroboczek
2011-02-04 18:54 ` Dave Täht
2011-02-04 19:02 ` Juliusz Chroboczek
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D4C05A3.3000901@freedesktop.org \
--to=jg@freedesktop.org \
--cc=bloat@lists.bufferbloat.net \
/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