From: Wesley Eddy <wes@mti-systems.com>
To: sahil grover <sahilgrover013@gmail.com>, codel@lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat.
Date: Tue, 24 Feb 2015 11:27:19 -0500 [thread overview]
Message-ID: <54ECA667.8050807@mti-systems.com> (raw)
In-Reply-To: <CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2BhhaiRC=A@mail.gmail.com>
On 2/24/2015 10:37 AM, sahil grover wrote:
> (i) First of all,i want to know whether RED was implemented or not?
> if not then what were the reasons(major) ?
> anyone please tell me in simple words here only,because i don't want to
> read any paper like "RED in a different light".
>
> (ii)Second, as we all know RED controls the average queue size from
> growing.
> So it also controls delay in a way or we can say is a solution to
> bufferbloat problem. Then why it was not considered.
>
There is an IETF document from the AQM working group which contains
some discussion towards your first question, at least:
https://tools.ietf.org/html/draft-ietf-aqm-recommendation-10
(this should be published as an RFC "soon")
Specifically, the text says:
With an appropriate set of parameters, RED is an effective algorithm.
However, dynamically predicting this set of parameters was found to
be difficult. As a result, RED has not been enabled by default, and
its present use in the Internet is limited. Other AQM algorithms
have been developed since RC2309 was published, some of which are
self-tuning within a range of applicability. Hence, while this memo
continues to recommend the deployment of AQM, it no longer recommends
that RED or any other specific algorithm is used as a default;
instead it provides recommendations on how to select appropriate
algorithms and that a recommended algorithm is able to automate any
required tuning for common deployment scenarios.
--
Wes Eddy
MTI Systems
prev parent reply other threads:[~2015-02-24 16:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 15:37 sahil grover
2015-02-24 15:54 ` Jonathan Morton
2015-02-24 16:20 ` sahil grover
2015-02-24 16:32 ` Jonathan Morton
2015-02-24 18:00 ` Dave Taht
2015-02-24 18:15 ` Dave Taht
[not found] ` <CADnS-2jBfvSzgWmio3y_hyozPYnPzgUX+bLAh0j8VB90HspBNg@mail.gmail.com>
[not found] ` <CAA93jw70w1__gkE5ooqK3eJ12mJGWUnMKMg7MR=uN6+DEr9iPg@mail.gmail.com>
2015-02-26 12:58 ` sahil grover
2015-02-26 13:56 ` Jonathan Morton
2015-02-27 14:34 ` sahil grover
2015-02-27 15:25 ` Richard Scheffenegger
2015-03-04 6:51 ` Greg White
2015-03-04 7:15 ` Jonathan Morton
2015-02-24 22:40 ` Kathleen Nichols
2015-02-24 16:33 ` Richard Scheffenegger
2015-02-24 17:29 ` sahil grover
2015-02-24 17:35 ` Jonathan Morton
2015-02-24 16:27 ` Wesley Eddy [this message]
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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54ECA667.8050807@mti-systems.com \
--to=wes@mti-systems.com \
--cc=codel@lists.bufferbloat.net \
--cc=sahilgrover013@gmail.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