<div dir="ltr">Mohit Sir thanks for reply.<div>Your paper is very effective.</div><div>Good Job.</div><div>For sure, i am going to reproduce the results on this weekend.</div><div>And once it would be done,i will let you know.</div><div>Thanks again for giving ideas.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 1:33 PM, Mohit P. Tahiliani <span dir="ltr"><<a href="mailto:tahiliani.nitk@gmail.com" target="_blank">tahiliani.nitk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mandy,<div><br></div><div>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.</div><div><br></div><div>However, we did a few changes in the TCP Evaluation Suite to test the working of CoDel, as explained below:</div><div><br></div><div>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:</div><div><br></div><div><a href="http://mohittahiliani.blogspot.in/2013/05/codels-patch-for-ns-231-to-support-tcp.html" target="_blank">http://mohittahiliani.blogspot.in/2013/05/codels-patch-for-ns-231-to-support-tcp.html</a><br></div><div><br></div><div>You can apply that patch and set up your TCP Evaluation Suite for testing CoDel.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Hope this will help you to reproduce the results of that paper.</div><div><br></div><div>Let me know if you have any further doubts.</div><div><br></div><div>Best Regards,</div><div>Mohit P. Tahiliani</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 10:05 PM,  <span dir="ltr"><<a href="mailto:codel-request@lists.bufferbloat.net" target="_blank">codel-request@lists.bufferbloat.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send Codel mailing list submissions to<br>
        <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:codel-request@lists.bufferbloat.net" target="_blank">codel-request@lists.bufferbloat.net</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:codel-owner@lists.bufferbloat.net" target="_blank">codel-owner@lists.bufferbloat.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Codel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Request to Mohit P. Tahiliani for "On the effectiveness of<br>
      CoDel for active queue management" (mandy ahuja)<br>
   2. why RED is not considered as a solution to bufferbloat.<br>
      (sahil grover)<br>
   3. Re: why RED is not considered as a solution to bufferbloat.<br>
      (Jonathan Morton)<br>
   4. Re: why RED is not considered as a solution to bufferbloat.<br>
      (sahil grover)<br>
   5. Re: why RED is not considered as a solution to bufferbloat.<br>
      (Wesley Eddy)<br>
   6. Re: why RED is not considered as a solution to bufferbloat.<br>
      (Jonathan Morton)<br>
   7. Re: why RED is not considered as a solution to bufferbloat.<br>
      (Richard Scheffenegger)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 24 Feb 2015 14:18:50 +0530<br>
From: mandy ahuja <<a href="mailto:mandyahuja013@gmail.com" target="_blank">mandyahuja013@gmail.com</a>><br>
To: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: [Codel] Request to Mohit P. Tahiliani for "On the<br>
        effectiveness of CoDel for active queue management"<br>
Message-ID:<br>
        <CALbqCD5NcBGjzDu82v=117t6qKVRwgZhVjO8kC=<a href="mailto:SjkNFOJPKpA@mail.gmail.com" target="_blank">SjkNFOJPKpA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Mohit Sir,<br>
please send me the NS2  simulation scripts that you used in your paper<br>
"On the effectiveness of CoDel for active queue management<br>
<<a href="https://scholar.google.com/citations?view_op=view_citation&hl=ru&user=lBxu90cAAAAJ&citation_for_view=lBxu90cAAAAJ:zYLM7Y9cAGgC" target="_blank">https://scholar.google.com/citations?view_op=view_citation&hl=ru&user=lBxu90cAAAAJ&citation_for_view=lBxu90cAAAAJ:zYLM7Y9cAGgC</a>><br>
"<br>
it would be great favour.<br>
Hope u'll reply.<br>
<br>
Thanks<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/aa26d9de/attachment-0001.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/aa26d9de/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 24 Feb 2015 21:07:28 +0530<br>
From: sahil grover <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>><br>
To: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID:<br>
        <CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2BhhaiRC=<a href="mailto:A@mail.gmail.com" target="_blank">A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
(i) First of all,i want to know whether RED was implemented or not?<br>
if not then what were the reasons(major) ?<br>
anyone please tell me in simple words here only,because i don't want to<br>
read any paper like "RED in a different light".<br>
<br>
(ii)Second, as we all know RED controls the  average queue size from<br>
growing.<br>
So it also controls delay in a way or  we can say  is a solution to<br>
bufferbloat problem. Then why it was not considered.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/253281b9/attachment-0001.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/253281b9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 24 Feb 2015 17:54:13 +0200<br>
From: Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
To: sahil grover <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>><br>
Cc: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: Re: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID:<br>
        <<a href="mailto:CAJq5cE30Rv0U0xhD7ZTfDHkgs8z99F3KoOEKxh3Z9o2ERDY-Wg@mail.gmail.com" target="_blank">CAJq5cE30Rv0U0xhD7ZTfDHkgs8z99F3KoOEKxh3Z9o2ERDY-Wg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Simply put, RED is a very old algorithm, one of the first viable AQM<br>
algorithms. However, it proved to be so difficult to configure properly<br>
that almost nobody uses it, even though many carrier grade routers<br>
implement it.<br>
<br>
Codel not only performs better than an ideally configured RED, but is far<br>
easier to configure. This makes it much more deployable.<br>
<br>
- Jonathan Morton<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/a94e1ffb/attachment-0001.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/a94e1ffb/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 24 Feb 2015 21:50:19 +0530<br>
From: sahil grover <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>><br>
To: Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
Cc: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: Re: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID:<br>
        <CADnS-2hSsThT5gSXuFb=<a href="mailto:MM8DDTrya5ZzYYYWgsXv2Omj_RbxAg@mail.gmail.com" target="_blank">MM8DDTrya5ZzYYYWgsXv2Omj_RbxAg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
So we can say Codel is better than other AQM???<br>
<br>
On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
wrote:<br>
<br>
> Simply put, RED is a very old algorithm, one of the first viable AQM<br>
> algorithms. However, it proved to be so difficult to configure properly<br>
> that almost nobody uses it, even though many carrier grade routers<br>
> implement it.<br>
><br>
> Codel not only performs better than an ideally configured RED, but is far<br>
> easier to configure. This makes it much more deployable.<br>
><br>
> - Jonathan Morton<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/dcc3c1b9/attachment-0001.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/dcc3c1b9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 24 Feb 2015 11:27:19 -0500<br>
From: Wesley Eddy <<a href="mailto:wes@mti-systems.com" target="_blank">wes@mti-systems.com</a>><br>
To: sahil grover <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>>,<br>
        <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: Re: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID: <<a href="mailto:54ECA667.8050807@mti-systems.com" target="_blank">54ECA667.8050807@mti-systems.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
On 2/24/2015 10:37 AM, sahil grover wrote:<br>
> (i) First of all,i want to know whether RED was implemented or not?<br>
> if not then what were the reasons(major) ?<br>
> anyone please tell me in simple words here only,because i don't want to<br>
> read any paper like "RED in a different light".<br>
><br>
> (ii)Second, as we all know RED controls the  average queue size from<br>
> growing.<br>
> So it also controls delay in a way or  we can say  is a solution to<br>
> bufferbloat problem. Then why it was not considered.<br>
><br>
<br>
<br>
There is an IETF document from the AQM working group which contains<br>
some discussion towards your first question, at least:<br>
<a href="https://tools.ietf.org/html/draft-ietf-aqm-recommendation-10" target="_blank">https://tools.ietf.org/html/draft-ietf-aqm-recommendation-10</a><br>
(this should be published as an RFC "soon")<br>
<br>
Specifically, the text says:<br>
<br>
   With an appropriate set of parameters, RED is an effective algorithm.<br>
   However, dynamically predicting this set of parameters was found to<br>
   be difficult.  As a result, RED has not been enabled by default, and<br>
   its present use in the Internet is limited.  Other AQM algorithms<br>
   have been developed since RC2309 was published, some of which are<br>
   self-tuning within a range of applicability.  Hence, while this memo<br>
   continues to recommend the deployment of AQM, it no longer recommends<br>
   that RED or any other specific algorithm is used as a default;<br>
   instead it provides recommendations on how to select appropriate<br>
   algorithms and that a recommended algorithm is able to automate any<br>
   required tuning for common deployment scenarios.<br>
<br>
<br>
--<br>
Wes Eddy<br>
MTI Systems<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 24 Feb 2015 18:32:06 +0200<br>
From: Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
To: sahil grover <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>><br>
Cc: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: Re: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID:<br>
        <<a href="mailto:CAJq5cE3dqpLW76HtJgreB-qmQ%2B1Fe4wAqwM0jYHU022ESn8r_A@mail.gmail.com" target="_blank">CAJq5cE3dqpLW76HtJgreB-qmQ+1Fe4wAqwM0jYHU022ESn8r_A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Most of us on this list believe that to be true, in many cases after<br>
performing experiments ourselves, or at least looking through data<br>
generated by others' experiments.<br>
<br>
However, if as I suspect you are investigating various AQM algorithms as<br>
part of your education, you should probably examine the data yourselves and<br>
come to your own conclusions. You may even get extra credit for being able<br>
to describe the difference between AQM and Fair Queuing, and how they can<br>
be combined (as in fq_codel) to give the benefits of both types in one go.<br>
But for that, you ARE going to need to read some boring papers like "RED in<br>
a different light".<br>
<br>
- Jonathan Morton<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/f8f06c29/attachment-0001.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/f8f06c29/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 24 Feb 2015 17:33:25 +0100<br>
From: "Richard Scheffenegger" <<a href="mailto:rscheff@gmx.at" target="_blank">rscheff@gmx.at</a>><br>
To: "sahil grover" <<a href="mailto:sahilgrover013@gmail.com" target="_blank">sahilgrover013@gmail.com</a>>,  "Jonathan Morton"<br>
        <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>
Cc: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
Subject: Re: [Codel] why RED is not considered as a solution to<br>
        bufferbloat.<br>
Message-ID: <C2F5B1FF91F24E6097BD0D3570972867@srichardlxp2><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Sahil.,<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
If you follow the AQM work in IETF, there is strong consensus steer to these more modern AQMs.<br>
<br>
Best regards,<br>
  Richard<br>
<br>
<br>
  ----- Original Message -----<br>
  From: sahil grover<br>
  To: Jonathan Morton<br>
  Cc: <a href="mailto:codel@lists.bufferbloat.net" target="_blank">codel@lists.bufferbloat.net</a><br>
  Sent: Tuesday, February 24, 2015 5:20 PM<br>
  Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat.<br>
<br>
<br>
  So we can say Codel is better than other AQM???<br>
<br>
<br>
  On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br>
<br>
    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.<br>
<br>
    Codel not only performs better than an ideally configured RED, but is far easier to configure. This makes it much more deployable.<br>
<br>
    - Jonathan Morton<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------------<br>
<br>
<br>
  _______________________________________________<br>
  Codel mailing list<br>
  <a href="mailto:Codel@lists.bufferbloat.net" target="_blank">Codel@lists.bufferbloat.net</a><br>
  <a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/3926ef08/attachment.html" target="_blank">https://lists.bufferbloat.net/pipermail/codel/attachments/20150224/3926ef08/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Codel mailing list<br>
<a href="mailto:Codel@lists.bufferbloat.net" target="_blank">Codel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
<br>
<br>
End of Codel Digest, Vol 29, Issue 8<br>
************************************<br>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Codel mailing list<br>
<a href="mailto:Codel@lists.bufferbloat.net">Codel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
<br></blockquote></div><br></div>