From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 392E321F3B3 for ; Fri, 27 Feb 2015 00:25:58 -0800 (PST) Received: by wesw62 with SMTP id w62so18248244wes.9 for ; Fri, 27 Feb 2015 00:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EWdATbtXrkynvI7ZcYvnCu73nR8y+RAk0Aqh2oloVpE=; b=Yi9NZm7EJOLL6bGWoVlkQgB3Gk9yGwZgaH+6RtQOBBOo/EKExhrckHGRslJcW44Cbs ZQvDfH/0H6uIoL/9klUr8dnvv2NfcrLMNlp4Mg5PBnXmGpKuGQooe6PSsX16kGiStJXa VxAtMDsJF7uySK/2xscwgT5Xa2jVOp1xAGnvSk6xcCCTQJJNL2I6iZ8a4kCV2YvZQfAD ZNM8cDVu6Cc27CMlL9owe0xIa9b/nAvIOi1h9xM5UaOZZJyuq+iTJQ78+ciEhGfTuwg6 itMJgXf9P7rw5xyHPpZouS/YyT7adT+58TPNvBr07ecXRnzuZP+LibvAsiRCCvfkvrxz 7qMA== MIME-Version: 1.0 X-Received: by 10.180.108.199 with SMTP id hm7mr4015824wib.5.1425025556795; Fri, 27 Feb 2015 00:25:56 -0800 (PST) Received: by 10.180.207.9 with HTTP; Fri, 27 Feb 2015 00:25:56 -0800 (PST) In-Reply-To: References: Date: Fri, 27 Feb 2015 13:55:56 +0530 Message-ID: From: mandy ahuja To: "Mohit P. Tahiliani" Content-Type: multipart/alternative; boundary=e89a8f3bae5d1bd5b705100d9e53 Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] [Reply] Request to Mohit P. Tahiliani for "On the effectiveness of CoDel for active queue management" (mandy ahuja) X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 08:26:27 -0000 --e89a8f3bae5d1bd5b705100d9e53 Content-Type: text/plain; charset=UTF-8 Hi Sir, i want to know why we need to modify the codel patch for TCP Evaluation suite? or for your 2nd paper "Analysis of sfqCoDel for Active Queue Management" from where can i get the patch of sfqCoDel (supporting the TCP Evaluation suite). Can you please provide me that patch. It would be great favour Thanks On Thu, Feb 26, 2015 at 10:54 PM, mandy ahuja wrote: > Mohit Sir thanks for reply. > Your paper is very effective. > Good Job. > For sure, i am going to reproduce the results on this weekend. > And once it would be done,i will let you know. > Thanks again for giving ideas. > > > On Wed, Feb 25, 2015 at 1:33 PM, Mohit P. Tahiliani < > tahiliani.nitk@gmail.com> wrote: > >> Hi Mandy, >> >> For that paper, we used the scenarios provided in the "TCP Evaluation >> Suite" which works on ns-2.31. It is available online and installation >> should not be a problem as there is a nice tutorial that explains the steps >> clearly. >> >> However, we did a few changes in the TCP Evaluation Suite to test the >> working of CoDel, as explained below: >> >> 1. We had to merge the CoDel's source code to ns-2.31. The patch for same >> can be downloaded from the following link: >> >> >> http://mohittahiliani.blogspot.in/2013/05/codels-patch-for-ns-231-to-support-tcp.html >> >> You can apply that patch and set up your TCP Evaluation Suite for testing >> CoDel. >> >> 2. By default, the bottleneck queue size in TCP Evaluation Suite has a >> size of BDP. We changed it to 8xBDP to simulate the Bufferbloat scenario >> (Ref. Kathleen and Van's paper on CoDel). >> >> 3. All three topolgies in TCP Evaluation Suite simulate cross traffic >> (which is a mix of forward and reverse FTP flows, streaming data and HTTP >> traffic). But for the paper we just used "Dumbbell" topology provided in >> the suite. >> >> Hope this will help you to reproduce the results of that paper. >> >> Let me know if you have any further doubts. >> >> Best Regards, >> Mohit P. Tahiliani >> >> On Tue, Feb 24, 2015 at 10:05 PM, >> wrote: >> >>> Send Codel mailing list submissions to >>> codel@lists.bufferbloat.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.bufferbloat.net/listinfo/codel >>> or, via email, send a message with subject or body 'help' to >>> codel-request@lists.bufferbloat.net >>> >>> You can reach the person managing the list at >>> codel-owner@lists.bufferbloat.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Codel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Request to Mohit P. Tahiliani for "On the effectiveness of >>> CoDel for active queue management" (mandy ahuja) >>> 2. why RED is not considered as a solution to bufferbloat. >>> (sahil grover) >>> 3. Re: why RED is not considered as a solution to bufferbloat. >>> (Jonathan Morton) >>> 4. Re: why RED is not considered as a solution to bufferbloat. >>> (sahil grover) >>> 5. Re: why RED is not considered as a solution to bufferbloat. >>> (Wesley Eddy) >>> 6. Re: why RED is not considered as a solution to bufferbloat. >>> (Jonathan Morton) >>> 7. Re: why RED is not considered as a solution to bufferbloat. >>> (Richard Scheffenegger) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 24 Feb 2015 14:18:50 +0530 >>> From: mandy ahuja >>> To: codel@lists.bufferbloat.net >>> Subject: [Codel] Request to Mohit P. Tahiliani for "On the >>> effectiveness of CoDel for active queue management" >>> Message-ID: >>> >> SjkNFOJPKpA@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Mohit Sir, >>> please send me the NS2 simulation scripts that you used in your paper >>> "On the effectiveness of CoDel for active queue management >>> < >>> https://scholar.google.com/citations?view_op=view_citation&hl=ru&user=lBxu90cAAAAJ&citation_for_view=lBxu90cAAAAJ:zYLM7Y9cAGgC >>> > >>> " >>> it would be great favour. >>> Hope u'll reply. >>> >>> Thanks >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/aa26d9de/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Tue, 24 Feb 2015 21:07:28 +0530 >>> From: sahil grover >>> To: codel@lists.bufferbloat.net >>> Subject: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: >>> >> A@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> (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. >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/253281b9/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Tue, 24 Feb 2015 17:54:13 +0200 >>> From: Jonathan Morton >>> To: sahil grover >>> Cc: codel@lists.bufferbloat.net >>> Subject: Re: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: >>> < >>> CAJq5cE30Rv0U0xhD7ZTfDHkgs8z99F3KoOEKxh3Z9o2ERDY-Wg@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> 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 >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/a94e1ffb/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Tue, 24 Feb 2015 21:50:19 +0530 >>> From: sahil grover >>> To: Jonathan Morton >>> Cc: codel@lists.bufferbloat.net >>> Subject: Re: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: >>> >> MM8DDTrya5ZzYYYWgsXv2Omj_RbxAg@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> So we can say Codel is better than other AQM??? >>> >>> On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton >>> 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 >>> > >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/dcc3c1b9/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Tue, 24 Feb 2015 11:27:19 -0500 >>> From: Wesley Eddy >>> To: sahil grover , >>> codel@lists.bufferbloat.net >>> Subject: Re: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: <54ECA667.8050807@mti-systems.com> >>> Content-Type: text/plain; charset=windows-1252 >>> >>> 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 >>> >>> >>> ------------------------------ >>> >>> Message: 6 >>> Date: Tue, 24 Feb 2015 18:32:06 +0200 >>> From: Jonathan Morton >>> To: sahil grover >>> Cc: codel@lists.bufferbloat.net >>> Subject: Re: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: >>> < >>> CAJq5cE3dqpLW76HtJgreB-qmQ+1Fe4wAqwM0jYHU022ESn8r_A@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Most of us on this list believe that to be true, in many cases after >>> performing experiments ourselves, or at least looking through data >>> generated by others' experiments. >>> >>> However, if as I suspect you are investigating various AQM algorithms as >>> part of your education, you should probably examine the data yourselves >>> and >>> come to your own conclusions. You may even get extra credit for being >>> able >>> to describe the difference between AQM and Fair Queuing, and how they can >>> be combined (as in fq_codel) to give the benefits of both types in one >>> go. >>> But for that, you ARE going to need to read some boring papers like "RED >>> in >>> a different light". >>> >>> - Jonathan Morton >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/f8f06c29/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 7 >>> Date: Tue, 24 Feb 2015 17:33:25 +0100 >>> From: "Richard Scheffenegger" >>> To: "sahil grover" , "Jonathan Morton" >>> >>> Cc: codel@lists.bufferbloat.net >>> Subject: Re: [Codel] why RED is not considered as a solution to >>> bufferbloat. >>> Message-ID: >>> Content-Type: text/plain; charset="utf-8" >>> >>> 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 >>> To: Jonathan Morton >>> 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 >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/3926ef08/attachment.html >>> > >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> Codel mailing list >>> Codel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/codel >>> >>> >>> End of Codel Digest, Vol 29, Issue 8 >>> ************************************ >>> >> >> >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel >> >> > --e89a8f3bae5d1bd5b705100d9e53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sir,
i want to know why we need to modify the codel= patch for TCP Evaluation suite?
or for your 2nd paper =C2=A0&quo= t;Analysis of sfqCoDel for Active Queue Management" =C2=A0from where c= an i get the patch of sfqCoDel (supporting the=C2=A0TCP Evaluation suite).<= /div>
Can you please provide me that patch.
It would be great= favour

Thanks


On Thu, Feb 26,= 2015 at 10:54 PM, mandy ahuja <mandyahuja013@gmail.com> wrote:
Mohit Sir than= ks for reply.
Your paper is very effective.
Good Job.
For sure, i am going to reproduce the results on this weekend.
And once it would be done,i will let you know.
Thanks again for = giving ideas.


On Wed, Feb = 25, 2015 at 1:33 PM, Mohit P. Tahiliani <tahiliani.nitk@gmail.com> wrote:
Hi = Mandy,

For that paper, we used the scenarios provided in= the "TCP Evaluation Suite" which works on ns-2.31. It is availab= le online and installation should not be a problem as there is a nice tutor= ial that explains the steps clearly.

However, we d= id a few changes in the TCP Evaluation Suite to test the working of CoDel, = as explained below:

1. We had to merge the CoDel&#= 39;s source code to ns-2.31. The patch for same can be downloaded from the = following link:


You can apply that patch= and set up your TCP Evaluation Suite for testing CoDel.

2. By default, the bottleneck queue size in TCP Evaluation Suite has= a size of BDP. We changed it to 8xBDP to simulate the Bufferbloat scenario= (Ref. Kathleen and Van's paper on CoDel).

3. = All three topolgies in TCP Evaluation Suite simulate cross traffic (which i= s a mix of forward and reverse FTP flows, streaming data and HTTP traffic).= But for the paper we just used "Dumbbell" topology provided in t= he suite.

Hope this will help you to reproduce the= results of that paper.

Let me know if you have an= y further doubts.

Best Regards,
Mohit P.= Tahiliani

On Tue, Feb 24, 2015 at 10:05 PM, <codel-request@li= sts.bufferbloat.net> wrote:
Send Codel ma= iling list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 codel@lists.bufferbloat.net

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.bufferbloat.net/listinfo/codel
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 codel-request@lists.bufferbloat.net

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 codel-owner@lists.bufferbloat.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Codel digest..."


Today's Topics:

=C2=A0 =C2=A01. Request to Mohit P. Tahiliani for "On the effectivenes= s of
=C2=A0 =C2=A0 =C2=A0 CoDel for active queue management" (mandy ahuja)<= br> =C2=A0 =C2=A02. why RED is not considered as a solution to bufferbloat.
=C2=A0 =C2=A0 =C2=A0 (sahil grover)
=C2=A0 =C2=A03. Re: why RED is not considered as a solution to bufferbloat.=
=C2=A0 =C2=A0 =C2=A0 (Jonathan Morton)
=C2=A0 =C2=A04. Re: why RED is not considered as a solution to bufferbloat.=
=C2=A0 =C2=A0 =C2=A0 (sahil grover)
=C2=A0 =C2=A05. Re: why RED is not considered as a solution to bufferbloat.=
=C2=A0 =C2=A0 =C2=A0 (Wesley Eddy)
=C2=A0 =C2=A06. Re: why RED is not considered as a solution to bufferbloat.=
=C2=A0 =C2=A0 =C2=A0 (Jonathan Morton)
=C2=A0 =C2=A07. Re: why RED is not considered as a solution to bufferbloat.=
=C2=A0 =C2=A0 =C2=A0 (Richard Scheffenegger)


----------------------------------------------------------------------

Message: 1
Date: Tue, 24 Feb 2015 14:18:50 +0530
From: mandy ahuja <mandyahuja013@gmail.com>
To: codel@= lists.bufferbloat.net
Subject: [Codel] Request to Mohit P. Tahiliani for "On the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 effectiveness of CoDel for active queue managem= ent"
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CALbqCD5NcBGjzDu82v=3D117t6qKVRwgZhVjO8kC= =3DSjkNFOJP= KpA@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi Mohit Sir,
please send me the NS2=C2=A0 simulation scripts that you used in your paper=
"On the effectiveness of CoDel for active queue management
<https://scholar.google.com/citations?view_op= =3Dview_citation&hl=3Dru&user=3DlBxu90cAAAAJ&citation_for_view= =3DlBxu90cAAAAJ:zYLM7Y9cAGgC>
"
it would be great favour.
Hope u'll reply.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.= bufferbloat.net/pipermail/codel/attachments/20150224/aa26d9de/attachment-00= 01.html>

------------------------------

Message: 2
Date: Tue, 24 Feb 2015 21:07:28 +0530
From: sahil grover <sahilgrover013@gmail.com>
To: codel@= lists.bufferbloat.net
Subject: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2B= hhaiRC=3DA@mail.gmail= .com>
Content-Type: text/plain; charset=3D"utf-8"

(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=C2=A0 average queue size from growing.
So it also controls delay in a way or=C2=A0 we can say=C2=A0 is a solution = to
bufferbloat problem. Then why it was not considered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.= bufferbloat.net/pipermail/codel/attachments/20150224/253281b9/attachment-00= 01.html>

------------------------------

Message: 3
Date: Tue, 24 Feb 2015 17:54:13 +0200
From: Jonathan Morton <chromatix99@gmail.com>
To: sahil grover <sahilgrover013@gmail.com>
Cc: codel@= lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAJq5cE30Rv0U0= xhD7ZTfDHkgs8z99F3KoOEKxh3Z9o2ERDY-Wg@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.= bufferbloat.net/pipermail/codel/attachments/20150224/a94e1ffb/attachment-00= 01.html>

------------------------------

Message: 4
Date: Tue, 24 Feb 2015 21:50:19 +0530
From: sahil grover <sahilgrover013@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: codel@= lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CADnS-2hSsThT5gSXuFb=3DMM8DDTrya5Zz= YYYWgsXv2Omj_RbxAg@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

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 properl= y
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.= bufferbloat.net/pipermail/codel/attachments/20150224/dcc3c1b9/attachment-00= 01.html>

------------------------------

Message: 5
Date: Tue, 24 Feb 2015 11:27:19 -0500
From: Wesley Eddy <wes@mti-systems.com>
To: sahil grover <sahilgrover013@gmail.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 codel@lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID: <54ECA667.8050807@mti-systems.com>
Content-Type: text/plain; charset=3Dwindows-1252

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 wa= nt to
> read any paper like "RED in a different light".
>
> (ii)Second, as we all know RED controls the=C2=A0 average queue size f= rom
> growing.
> So it also controls delay in a way or=C2=A0 we can say=C2=A0 is a solu= tion 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-1= 0
(this should be published as an RFC "soon")

Specifically, the text says:

=C2=A0 =C2=A0With an appropriate set of parameters, RED is an effective alg= orithm.
=C2=A0 =C2=A0However, dynamically predicting this set of parameters was fou= nd to
=C2=A0 =C2=A0be difficult.=C2=A0 As a result, RED has not been enabled by d= efault, and
=C2=A0 =C2=A0its present use in the Internet is limited.=C2=A0 Other AQM al= gorithms
=C2=A0 =C2=A0have been developed since RC2309 was published, some of which = are
=C2=A0 =C2=A0self-tuning within a range of applicability.=C2=A0 Hence, whil= e this memo
=C2=A0 =C2=A0continues to recommend the deployment of AQM, it no longer rec= ommends
=C2=A0 =C2=A0that RED or any other specific algorithm is used as a default;=
=C2=A0 =C2=A0instead it provides recommendations on how to select appropria= te
=C2=A0 =C2=A0algorithms and that a recommended algorithm is able to automat= e any
=C2=A0 =C2=A0required tuning for common deployment scenarios.


--
Wes Eddy
MTI Systems


------------------------------

Message: 6
Date: Tue, 24 Feb 2015 18:32:06 +0200
From: Jonathan Morton <chromatix99@gmail.com>
To: sahil grover <sahilgrover013@gmail.com>
Cc: codel@= lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAJq5cE3dqpL= W76HtJgreB-qmQ+1Fe4wAqwM0jYHU022ESn8r_A@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Most of us on this list believe that to be true, in many cases after
performing experiments ourselves, or at least looking through data
generated by others' experiments.

However, if as I suspect you are investigating various AQM algorithms as part of your education, you should probably examine the data yourselves and=
come to your own conclusions. You may even get extra credit for being able<= br> to describe the difference between AQM and Fair Queuing, and how they can be combined (as in fq_codel) to give the benefits of both types in one go.<= br> But for that, you ARE going to need to read some boring papers like "R= ED in
a different light".

- Jonathan Morton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.= bufferbloat.net/pipermail/codel/attachments/20150224/f8f06c29/attachment-00= 01.html>

------------------------------

Message: 7
Date: Tue, 24 Feb 2015 17:33:25 +0100
From: "Richard Scheffenegger" <rscheff@gmx.at>
To: "sahil grover" <sahilgrover013@gmail.com>,=C2=A0 "Jonathan = Morton"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <chromatix99@gmail.com>
Cc: codel@= lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bufferbloat.
Message-ID: <C2F5B1FF91F24E6097BD0D3570972867@srichardlxp2>
Content-Type: text/plain; charset=3D"utf-8"

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 d= ifferent quality; Second, Codel (in it's plain form) does drop/mark on = dequeue, while RED drops/marks on enqueue. This means, that [TCP] congestio= n control loop is much quicker with Codel over RED; thus the reaction by th= e sender will probably be timely and relevant for that congestion epoch.=C2= =A0 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 particu= lar drain rate (bandwidht) of the queue - unlike RED; So it adjusts much be= tter to variable bandwidth MACs (Wifi, DOCSIS).

I've been told, that RED is easier to implement in HW due to that actio= n 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 thes= e more modern AQMs.

Best regards,
=C2=A0 Richard


=C2=A0 ----- Original Message -----
=C2=A0 From: sahil grover
=C2=A0 To: Jonathan Morton
=C2=A0 Cc: codel@lists.bufferbloat.net
=C2=A0 Sent: Tuesday, February 24, 2015 5:20 PM
=C2=A0 Subject: Re: [Codel] why RED is not considered as a solution to buff= erbloat.


=C2=A0 So we can say Codel is better than other AQM???


=C2=A0 On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton <chromatix99@gmail.com> w= rote:

=C2=A0 =C2=A0 Simply put, RED is a very old algorithm, one of the first via= ble AQM algorithms. However, it proved to be so difficult to configure prop= erly that almost nobody uses it, even though many carrier grade routers imp= lement it.

=C2=A0 =C2=A0 Codel not only performs better than an ideally configured RED= , but is far easier to configure. This makes it much more deployable.

=C2=A0 =C2=A0 - Jonathan Morton






---------------------------------------------------------------------------= ---


=C2=A0 _______________________________________________
=C2=A0 Codel mailing list
=C2=A0 Cod= el@lists.bufferbloat.net
=C2=A0 https://lists.bufferbloat.net/listinfo/codel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.buffe= rbloat.net/pipermail/codel/attachments/20150224/3926ef08/attachment.html>

------------------------------

_______________________________________________
Codel mailing list
Codel@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/codel


End of Codel Digest, Vol 29, Issue 8
************************************


_______________________________________________
Codel mailing list
Codel@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/codel



--e89a8f3bae5d1bd5b705100d9e53--