[Codel] [Reply] Request to Mohit P. Tahiliani for "On the effectiveness of CoDel for active queue management" (mandy ahuja)
Mohit P. Tahiliani
tahiliani.nitk at gmail.com
Wed Feb 25 03:03:38 EST 2015
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
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20150225/0e8566f9/attachment-0002.html>
More information about the Codel
mailing list