[Codel] [Reply] Request to Mohit P. Tahiliani for "On the effectiveness of CoDel for active queue management" (mandy ahuja)
mandy ahuja
mandyahuja013 at gmail.com
Thu Feb 26 12:24:47 EST 2015
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 at 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, <codel-request at lists.bufferbloat.net>
> wrote:
>
>> Send Codel mailing list submissions to
>> codel at 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 at lists.bufferbloat.net
>>
>> You can reach the person managing the list at
>> codel-owner at 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 <mandyahuja013 at gmail.com>
>> To: codel at lists.bufferbloat.net
>> Subject: [Codel] Request to Mohit P. Tahiliani for "On the
>> effectiveness of CoDel for active queue management"
>> Message-ID:
>> <CALbqCD5NcBGjzDu82v=117t6qKVRwgZhVjO8kC=
>> SjkNFOJPKpA at 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 <sahilgrover013 at gmail.com>
>> To: codel at lists.bufferbloat.net
>> Subject: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID:
>> <CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2BhhaiRC=
>> A at 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 <chromatix99 at gmail.com>
>> To: sahil grover <sahilgrover013 at gmail.com>
>> Cc: codel at lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID:
>> <
>> CAJq5cE30Rv0U0xhD7ZTfDHkgs8z99F3KoOEKxh3Z9o2ERDY-Wg at 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 <sahilgrover013 at gmail.com>
>> To: Jonathan Morton <chromatix99 at gmail.com>
>> Cc: codel at lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID:
>> <CADnS-2hSsThT5gSXuFb=
>> MM8DDTrya5ZzYYYWgsXv2Omj_RbxAg at 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 <chromatix99 at 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
>> >
>> -------------- 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 <wes at mti-systems.com>
>> To: sahil grover <sahilgrover013 at gmail.com>,
>> codel at lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID: <54ECA667.8050807 at 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 <chromatix99 at gmail.com>
>> To: sahil grover <sahilgrover013 at gmail.com>
>> Cc: codel at lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID:
>> <
>> CAJq5cE3dqpLW76HtJgreB-qmQ+1Fe4wAqwM0jYHU022ESn8r_A at 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" <rscheff at gmx.at>
>> To: "sahil grover" <sahilgrover013 at gmail.com>, "Jonathan Morton"
>> <chromatix99 at gmail.com>
>> Cc: codel at lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>> bufferbloat.
>> Message-ID: <C2F5B1FF91F24E6097BD0D3570972867 at srichardlxp2>
>> 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 at 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 at 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 at 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel
>>
>>
>> End of Codel Digest, Vol 29, Issue 8
>> ************************************
>>
>
>
> _______________________________________________
> Codel mailing list
> Codel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20150226/38f41f84/attachment-0002.html>
More information about the Codel
mailing list