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 >> 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 > >