From: sahil grover <sahilgrover013@gmail.com>
To: Richard Scheffenegger <rscheff@gmx.at>, wes@mti-systems.com
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat.
Date: Tue, 24 Feb 2015 09:29:41 -0800 [thread overview]
Message-ID: <CADnS-2iGMuvHSBuKRQc9JKVAznAtW6S7+-f6+xO2s2786jimzA@mail.gmail.com> (raw)
In-Reply-To: <C2F5B1FF91F24E6097BD0D3570972867@srichardlxp2>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
Thanks a lot Jonathan,Eddy and Richard.
With the help of you people i have cleared many concepts.
But still one point is not clear.
Richard Sir you said that Codel is better in notifying congestion to TCP
senders.
But Sir how,i know codel does it at dequeue stage while RED does at enqueue
stage.
The thing is congestion signal has to traverse the buffer.
Then how does it make difference that whether it is at enqueue or dequeue.i
mean how it is quicker with codel?
On Tue, Feb 24, 2015 at 8:33 AM, Richard Scheffenegger <rscheff@gmx.at>
wrote:
> Sahil.,
>
> Codel tries to address the problems that RED couldn't; First, the input
> signal into the algorithm (sojourn time vs. average queue depth) is of a
> different quality; Second, Codel (in it's plain form) does drop/mark on
> dequeue, while RED drops/marks on enqueue. This means, that [TCP]
> congestion control loop is much quicker with Codel over RED; thus the
> reaction by the sender will probably be timely and relevant for that
> congestion epoch. With RED; the congestion signal (that lost packet) has
> to traverse the filled-up buffer first, thus the control loop time is much
> larger (includes the instantaneous queue length of the buffer) - and is
> further delayed by the averaging going on.
>
> Codel, by design, doesn't need to be tuned specifically for one particular
> drain rate (bandwidht) of the queue - unlike RED; So it adjusts much better
> to variable bandwidth MACs (Wifi, DOCSIS).
>
> I've been told, that RED is easier to implement in HW due to that action
> being all done on enqueue. With PIE, there exists another AQM that tries to
> re-use the hw engines that exist for RED, but the control algorithms try to
> use a different input signal - making the best of that.
>
>
> If you follow the AQM work in IETF, there is strong consensus steer to
> these more modern AQMs.
>
> Best regards,
> Richard
>
>
>
> ----- Original Message -----
> *From:* sahil grover <sahilgrover013@gmail.com>
> *To:* Jonathan Morton <chromatix99@gmail.com>
> *Cc:* codel@lists.bufferbloat.net
> *Sent:* Tuesday, February 24, 2015 5:20 PM
> *Subject:* Re: [Codel] why RED is not considered as a solution to
> bufferbloat.
>
> So we can say Codel is better than other AQM???
>
> On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>> Simply put, RED is a very old algorithm, one of the first viable AQM
>> algorithms. However, it proved to be so difficult to configure properly
>> that almost nobody uses it, even though many carrier grade routers
>> implement it.
>>
>> Codel not only performs better than an ideally configured RED, but is far
>> easier to configure. This makes it much more deployable.
>>
>> - Jonathan Morton
>>
>
> ------------------------------
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
>
[-- Attachment #2: Type: text/html, Size: 5220 bytes --]
next prev parent reply other threads:[~2015-02-24 17:29 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 [this message]
2015-02-24 17:35 ` Jonathan Morton
2015-02-24 16:27 ` Wesley Eddy
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=CADnS-2iGMuvHSBuKRQc9JKVAznAtW6S7+-f6+xO2s2786jimzA@mail.gmail.com \
--to=sahilgrover013@gmail.com \
--cc=codel@lists.bufferbloat.net \
--cc=rscheff@gmx.at \
--cc=wes@mti-systems.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