[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
Fri Feb 27 03:25:56 EST 2015
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 <mandyahuja013 at gmail.com>
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 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/20150227/3d263aa0/attachment-0002.html>
More information about the Codel
mailing list