Re: [Codel] [Reply] Request to Mohit P. Tahiliani for "On the effectiveness of CoDel for active queue management" (mandy ahuja)

[mandy ahuja <mandyahuja013@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 14283 bytes --]

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, <codel-request@lists.bufferbloat.net>
> 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 <mandyahuja013@gmail.com>
>> To: codel@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@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@gmail.com>
>> To: codel@lists.bufferbloat.net
>> Subject: [Codel] why RED is not considered as a solution to
>>         bufferbloat.
>> Message-ID:
>>         <CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2BhhaiRC=
>> 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 <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
>>         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 <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
>>         bufferbloat.
>> Message-ID:
>>         <CADnS-2hSsThT5gSXuFb=
>> 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 <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
>> >
>> -------------- 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@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.
>> 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 <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
>>         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" <rscheff@gmx.at>
>> To: "sahil grover" <sahilgrover013@gmail.com>,  "Jonathan Morton"
>>         <chromatix99@gmail.com>
>> Cc: codel@lists.bufferbloat.net
>> Subject: Re: [Codel] why RED is not considered as a solution to
>>         bufferbloat.
>> Message-ID: <C2F5B1FF91F24E6097BD0D3570972867@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@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
>
>

[-- Attachment #2: Type: text/html, Size: 20100 bytes --]