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