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: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. TahilianiOn Tue, Feb 24, 2015 at 10:05 PM, <codel-request@lists.bufferbloat.net> 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 <mandyahuja013@gmail.com>
To: codel@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@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@gmail.com>
To: codel@lists.bufferbloat.net
Subject: [Codel] why RED is not considered as a solution to
bufferbloat.
Message-ID:
<CADnS-2jfWc7-+fCDRm_pNhisVVdwQNRCGHiKcBPA2BhhaiRC=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 <chromatix99@gmail.com>
To: sahil grover <sahilgrover013@gmail.com>
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 <sahilgrover013@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
bufferbloat.
Message-ID:
<CADnS-2hSsThT5gSXuFb=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 <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
>
-------------- 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@mti-systems.com>
To: sahil grover <sahilgrover013@gmail.com>,
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 <chromatix99@gmail.com>
To: sahil grover <sahilgrover013@gmail.com>
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" <rscheff@gmx.at>
To: "sahil grover" <sahilgrover013@gmail.com>, "Jonathan Morton"
<chromatix99@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] why RED is not considered as a solution to
bufferbloat.
Message-ID: <C2F5B1FF91F24E6097BD0D3570972867@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@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