Codel, fq_codel in ns3

As discussed here;
http://mailman.isi.edu/pipermail/ns-developers/2012-August/010572.html

Andrew Mcgregor has developed some ns3 models of Kathie Nichols' and
Van Jacobson's new codel algorithm and also incorporated Eric
Dumazet's fq_codel derivative...

this is an early request for feedback, not yet a merge request

[Tom Henderson, 2012-08-17 21:19:31]

This looks really good in general.  Mainly missing tests and documentation (both
doxygen and also some writeup of what these queues are supposed to do).  I think
that the boost dependency and linux list in src/core/ may need additional
consideration by others (if the proposal is to eventually add this to the ns-3
main tree and maintain it there).

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc
File scratch/tcp-qfp.cc (right):

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode24
scratch/tcp-qfp.cc:24: // I had to install the package "libboost-dev" to get
them
this could eventually be folded into the waf build system; if this code is
merged to ns-3-dev, we'll have to discuss about adding a build dependency on
boost (which we have avoided thus far)

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode248
scratch/tcp-qfp.cc:248: // Could set something other than Cubic here, but
setting Cubic explicitly exits the sim
did not understand this comment

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode345
scratch/tcp-qfp.cc:345: UniformVariable longrtt (160,166);
for ns-3.15, we're moving away from this random variable implementation to one
based on the ns-3 object system; the above would be instead:
Ptr<UniformRandomVariable> shortrtt = CreateObject<UniformRandomVariable> ();
...

just FYI

http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h
File src/core/model/linux-list.h (right):

http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h#newc...
src/core/model/linux-list.h:4: /* This file is from Linux Kernel
(include/linux/list.h)
this is missing a GPL

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
File src/internet/model/fq_codel-queue.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
src/internet/model/fq_codel-queue.cc:3: * Copyright (c) 2007 University of
Washington
copyright

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queue.h
File src/internet/model/fq_codel-queue.h (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
src/internet/model/fq_codel-queue.h:3: * Copyright (c) 2007 University of
Washington
this copyright is not correct

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
src/internet/model/fq_codel-queue.h:76: uint32_t m_peturbInterval;
perturbInterval?

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
src/internet/model/fq_codel-queue.h:80: mutable uint32_t peturbation;
perturbation?

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.cc
File src/internet/model/sfq-queue.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.cc#...
src/internet/model/sfq-queue.cc:3: * Copyright (c) 2007 University of Washington
copyright

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.cc#...
src/internet/model/sfq-queue.cc:47: NS_LOG_FUNCTION_NOARGS ();
just a small nit; use NS_LOG_FUNCTION_NOARGS() only on static functions;
instead, here use NS_LOG_FUNCTION (this);

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.cc#...
src/internet/model/sfq-queue.cc:68: "Peterbation interval in packets",
Perturbation?

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.h
File src/internet/model/sfq-queue.h (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/sfq-queue.h#n...
src/internet/model/sfq-queue.h:3: * Copyright (c) 2007 University of Washington
copyright

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
File src/internet/model/tcp-socket-base.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
src/internet/model/tcp-socket-base.cc:109: m_nextTxSequence (std::rand ()),
We would rather use the ns-3 random numbers here.
Ptr<UniformRandomVariable> m_rand;
m_rand->GetInteger (min, max);

http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h
File src/network/utils/codel-queue.h (right):

http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h#...
src/network/utils/codel-queue.h:117: codel_time_t m_first_above_time;
you're probably aware of this, but to be aligned with naming style, we use
camelCase and not underscores.

http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h#...
src/network/utils/codel-queue.h:117: codel_time_t m_first_above_time;
you're probably aware of this, but for naming conventions in ns-3, we use
camelCase instead of underscores.

http://codereview.appspot.com/6463048/diff/1/src/point-to-point/model/point-t...
File src/point-to-point/model/point-to-point-net-device.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/point-to-point/model/point-t...
src/point-to-point/model/point-to-point-net-device.cc:507: return false;
this should probably be separated out of this patch and entered as a bug.  I
would also add an NS_LOG_DEBUG() statement in the body of the if.

[john.abraham.in, 2012-08-17 21:57:03]

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc
File scratch/tcp-qfp.cc (right):

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode20
scratch/tcp-qfp.cc:20: // uses boost::format
Please note that using third-party libraries such as boost will require user to
install these software. Most users will not take the effort to install these
software, unless install instructions are crystal clear. Further note, this
software module might depend on the version of boost (maybe two years down the
road, they decide to change the function signature)

If the need for "format" is very minimalistic and can be avoided by using
generic c++ libs, that would be nice. Not sure if it is possible.

[Mathieu Lacage, 2012-08-21 16:02:18]

It's nice to see this feature coming in !

Hopefully, you were looking for great suffering. Here it is :)

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc
File scratch/tcp-qfp.cc (right):

http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode20
scratch/tcp-qfp.cc:20: // uses boost::format

Why not if:
  - it is optional. i.e., building the file is disabled if boost is not found
  - I see that this is a simulation script as opposed to simulation objects so,
yes, we encourage the use of "using namespace ns3" but in general, it is
considered better to not use "using namespace alibrary": use prefixing instead.
i.e., boost:: is your friend

http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h
File src/core/model/linux-list.h (right):

http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h#newc...
src/core/model/linux-list.h:25: struct list_head {
In general, if you want to use this kind of C/macro-based API in a module of
your own that is not merged, it is fine, but:
  - we certainly do not want to encourage people to use it so, there is no way
it will land in src/core/model as shared code.
  - if the code is merged in ns-3 you should work hard to use std::list instead
of this. i.e., the burden is on you to prove that you cannot live without this.
  - if you wanted to use this as a kind of glue layer to reuse other code from
the kernel, it would be fine but the code that is using this does not look like
actual kernel code so, it is hard for me to see the point in actually using this
instead of std::list

http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h
File src/network/utils/codel-queue.h (right):

http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h#...
src/network/utils/codel-queue.h:58: friend class Fq_CoDelQueue;
I see that it is because of the sole backlog field. There are better ways to do
this and avoid this friend keyword.

[andrewmcgr, 2012-08-21 22:27:54]

On 2012/08/21 16:02:18, Mathieu Lacage wrote:
> It's nice to see this feature coming in !
> 
> Hopefully, you were looking for great suffering. Here it is :)
> 
> http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc
> File scratch/tcp-qfp.cc (right):
> 
> http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode20
> scratch/tcp-qfp.cc:20: // uses boost::format
> 
> Why not if:
>   - it is optional. i.e., building the file is disabled if boost is not found
>   - I see that this is a simulation script as opposed to simulation objects
so,
> yes, we encourage the use of "using namespace ns3" but in general, it is
> considered better to not use "using namespace alibrary": use prefixing
instead.
> i.e., boost:: is your friend

The use of boost::format could easily go away, it was just expedient at the
time.  Results will be different, but not incorrect as this is just the input to
a hash function anyway.

> http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h
> File src/core/model/linux-list.h (right):
> 
>
http://codereview.appspot.com/6463048/diff/1/src/core/model/linux-list.h#newc...
> src/core/model/linux-list.h:25: struct list_head {
> In general, if you want to use this kind of C/macro-based API in a module of
> your own that is not merged, it is fine, but:
>   - we certainly do not want to encourage people to use it so, there is no way
> it will land in src/core/model as shared code.
>   - if the code is merged in ns-3 you should work hard to use std::list
instead
> of this. i.e., the burden is on you to prove that you cannot live without
this.
>   - if you wanted to use this as a kind of glue layer to reuse other code from
> the kernel, it would be fine but the code that is using this does not look
like
> actual kernel code so, it is hard for me to see the point in actually using
this
> instead of std::list

This is a hard one.  The linux kernel 'list' structure is an intrusive list,
rather than a container, and is frequently used as a more complicated container
than just a list.  Boost::intrusive doesn't help here, and is a far heavier
dependency anyway.  I know it's not idiomatic C++ or ns-3 style.

The real problem is, the fq_codel algorithm is totally dependent on the
iteration behaviour of the kernel list, which is not being used as a simple list
here.  I struggled for several weeks to reproduce the algorithm correctly with
std::list or boost::intrusive, and eventually gave up in favour of porting the
actual data structure into ns-3.  In terms of what fq_codel does, that ordering
behaviour is absolutely critical to the algorithm's functioning, it's probably
the main contribution of this code.

The problem is that we have one list with several heads here, and there are
operations that move list entries from one head to another, along with a
complicated iteration pattern.  However, all STL containers, including
boost:intrusive, invalidate all their iterators when deleting or moving
elements, which makes it very awkward to get the same behaviour. 

So, while it is undoubtedly possible to produce the desired behaviour using
idiomatic C++, I really doubt it can be done with STL containers.  I'd really
appreciate some help with this, because I couldn't see how to do it.  Perhaps
refactoring the macros into something more C++-like would be the way to go.

> http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h
> File src/network/utils/codel-queue.h (right):
> 
>
http://codereview.appspot.com/6463048/diff/1/src/network/utils/codel-queue.h#...
> src/network/utils/codel-queue.h:58: friend class Fq_CoDelQueue;
> I see that it is because of the sole backlog field. There are better ways to
do
> this and avoid this friend keyword.

I'm sure there are. Suggestions?

[andrewmcgr, 2012-08-21 22:29:33]

On 2012/08/17 21:57:03, john.abraham.in wrote:
> http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc
> File scratch/tcp-qfp.cc (right):
> 
> http://codereview.appspot.com/6463048/diff/1/scratch/tcp-qfp.cc#newcode20
> scratch/tcp-qfp.cc:20: // uses boost::format
> Please note that using third-party libraries such as boost will require user
to
> install these software. Most users will not take the effort to install these
> software, unless install instructions are crystal clear. Further note, this
> software module might depend on the version of boost (maybe two years down the
> road, they decide to change the function signature)
> 
> If the need for "format" is very minimalistic and can be avoided by using
> generic c++ libs, that would be nice. Not sure if it is possible.

Certainly possible, not particularly difficult even.  That was just expediency. 
Results will change slightly, but won't be wrong since this is only constructing
input to a hash anyway.

[Tommaso Pecorella, 2012-11-10 22:56:39]

This is a very welcome set of functionalities to be added to ns-3.

Beside other reviewer's comments, which I totally agree with, I just aded a
couple more. I'll check deeper the code as soon as I can, however.

In the meantime, I'd like to ask something, tho.
The code does present two different and orthogonal adds:
1) SFQ, and
2) CoDel.
At merge time, I'd propose to add them as two separate commits.

The second thing is a bit stranger. I see CoDel class name as CoDel "queue". I
don't totally agree with this, as CoDel in my opinion is an AQM, like RED. The
two things are tightly related, but the dumb user *will* get confused.
The confusion is even bigger in the example program, where you can set the
"queue" as fc_codel or CoDel.
I'll check again as soon as possible this topic (even checking the actual RED),
however maybe it's the right time to push for some clarification about the
different parts of the system.

Other than that, I hope this code will be converted in a real patch as soon as
possible.

Cheers,

Tommaso

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queue.h
File src/internet/model/fq_codel-queue.h (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
src/internet/model/fq_codel-queue.h:54: class Fq_CoDelQueue : public Queue {
Avoid underscores, due to ns-3 naming conventions.

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
File src/internet/model/tcp-socket-base.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
src/internet/model/tcp-socket-base.cc:109: m_nextTxSequence (std::rand ()),
beside Tom's comment, this change is not strictly related to CoDel. My
suggestion is to open a bug and propose a change in main ns-3 code.

[dave.taht, 2012-11-11 00:31:55]

I am certain I won't have time this year to get this into ns3. Help?

On Sat, Nov 10, 2012 at 11:56 PM,  <tommypec@gmail.com> wrote:
> This is a very welcome set of functionalities to be added to ns-3.
>
> Beside other reviewer's comments, which I totally agree with, I just
> aded a couple more. I'll check deeper the code as soon as I can,
> however.

While andrew and I agreed with the majority of the comments, we have
totally lacked time to address the change requests. Andrew is starting
a new gig at google soon, and I'm buried with other matters like
starting to deal with the bletcherous state of wifi and getting more
ethernet drivers BQL enabled.

http://www.teklibre.com/~d/bloat/Not_every_packet_is_sacred-Battling_Bufferbl...


There was also a sticking point in that we felt that preserving the
linux list behavior was much saner than ns3-and C++itizing the code,
in the first review cycle.

> In the meantime, I'd like to ask something, tho.
> The code does present two different and orthogonal adds:
> 1) SFQ, and

FQ_codel is different from conventional SFQ in multiple ways. Most
importantly, it does head drop, always, and has an optimization for
"new flows" that helps a lot on sparse streams, and in pushing forward
stuff with long RTTs.

This was some analysis of the predecessor to fq_codel, sfqred:

http://www.teklibre.com/~d/bloat/hoqvssfqred.ps

I note that fq_codel's use of the "hoq" idea has some flaws at lower
bandwidths....

I hope to work on a paper with Eric, andrew and Paul Mckenney about
"SFQ on steroids, introducing FQ_codel", sometime this year or the
next. Paul's1990 paper on SFQ techniques was very inspirational to us.
For a while last year, while working on sfqred, all we did was
implement ideas judged too hard to implement back then, on a 68020. :)

http://www.rdrop.com/users/paulmck/scalability/paper/sfq.2002.06.04.pdf

> 2) CoDel.
> At merge time, I'd propose to add them as two separate commits.
>
> The second thing is a bit stranger. I see CoDel class name as CoDel
> "queue". I don't totally agree with this, as CoDel in my opinion is an
> AQM, like RED. The two things are tightly related, but the dumb user
> *will* get confused.

I personally view codel as the first great drop strategy, and fq_codel
as a great aqm. I don't think codel will used by itself all that much.

To quote van from his presentation at ietf, with some digressions elided.

http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSV...

"fq_codel provides great isolation... if you've got low-rate
videoconferencing and low rate web traffic they never get dropped.
A lot of the issues with iw10 go away, because all that other traffic
sees is the front of the queue and you don't know how big its window
is and you don't care because you are not affected by it. And:
fq_codel increases utilization across your entire networking fabric
especially for bidirectional traffic..."

"If we're sticking code into boxes to deploy codel, don't do that.
Deploy fq_codel. It's just an across the board win." - Van Jacobson

I can see other things being built on top of codel, such as a more
pure packet oriented sfq (this is what is in ns2 presently), weighted
sfq (I'd like that) + codel, htb + weighted/diffserv aware fq_codel
(I'd really like that), or even qfq.... but codel alone, not so much.

> The confusion is even bigger in the example program, where you can set
> the "queue" as fc_codel or CoDel.

It's certainly useful to have it available as a separate qdisc.

> I'll check again as soon as possible this topic (even checking the
> actual RED), however maybe it's the right time to push for some
> clarification about the different parts of the system.
>
> Other than that, I hope this code will be converted in a real patch as
> soon as possible.

I have had the submitted patches in a tree on github for some time now.

git clone git://github.com/dtaht/ns-3-dev.git

I think andrew has a few updates and additional tools not included.

I really, really care about getting the ns3 sim out there, as (for
example) there is some interesting minstrel/wifi stuff in ns3 and I
was very interested in the LTE work...

but there is no more funding available presently. I shot my wad on
getting the bufferbloat project as far as it did before (nearly)
collapsing. We're on life support right now, only. Am spending more
time seeking funds than working.

I'm glad the fq_codel code is in the linux 3.5 and later kernels, I
have an update from the latest ns2 model available as patches to linux
3.6 here:

But haven't got it into ns3. So, if we can get a little help on
getting the patch set cleaned up and into ns3, that would be awesome.
Otherwise it's a certainty I won't be able to get to it until well
after the end of the year....

We certainly very much appreciated the initial review cycle. Sorry for
the prospective delays...

> Cheers,
>
> Tommaso
>
>
>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queue.h
> File src/internet/model/fq_codel-queue.h (right):
>
>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
> src/internet/model/fq_codel-queue.h:54: class Fq_CoDelQueue : public
> Queue {
> Avoid underscores, due to ns-3 naming conventions.
>
>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
> File src/internet/model/tcp-socket-base.cc (right):
>
>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
> src/internet/model/tcp-socket-base.cc:109: m_nextTxSequence (std::rand
> ()),
> beside Tom's comment, this change is not strictly related to CoDel. My
> suggestion is to open a bug and propose a change in main ns-3 code.
>
> http://codereview.appspot.com/6463048/



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

[andrewmcgr, 2012-11-11 22:43:11]

I have a few comments inline.

My time will be very short over the next few weeks, and undefinable past that,
because, as Dave says below, I start at Google in January.  However, I do hope
to be able to work some more on this eventually.

On 10/11/2012, at 7:31 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I am certain I won't have time this year to get this into ns3. Help?
> 
> On Sat, Nov 10, 2012 at 11:56 PM,  <tommypec@gmail.com> wrote:
>> This is a very welcome set of functionalities to be added to ns-3.
>> 
>> Beside other reviewer's comments, which I totally agree with, I just
>> aded a couple more. I'll check deeper the code as soon as I can,
>> however.
> 
> While andrew and I agreed with the majority of the comments, we have
> totally lacked time to address the change requests. Andrew is starting
> a new gig at google soon, and I'm buried with other matters like
> starting to deal with the bletcherous state of wifi and getting more
> ethernet drivers BQL enabled.
> 
>
http://www.teklibre.com/~d/bloat/Not_every_packet_is_sacred-Battling_Bufferbl...
> 
> 
> There was also a sticking point in that we felt that preserving the
> linux list behavior was much saner than ns3-and C++itizing the code,
> in the first review cycle.

Although, I now understand what all that list manipulation is actually doing...
I had a sudden 'aha!' while trying to explain it to someone else, and later
checked and the insight does correspond with the code.

>> In the meantime, I'd like to ask something, tho.
>> The code does present two different and orthogonal adds:
>> 1) SFQ, and
> 
> FQ_codel is different from conventional SFQ in multiple ways. Most
> importantly, it does head drop, always, and has an optimization for
> "new flows" that helps a lot on sparse streams, and in pushing forward
> stuff with long RTTs.

That's the bit I now grok.

> This was some analysis of the predecessor to fq_codel, sfqred:
> 
> http://www.teklibre.com/~d/bloat/hoqvssfqred.ps
> 
> I note that fq_codel's use of the "hoq" idea has some flaws at lower
> bandwidths....
> 
> I hope to work on a paper with Eric, andrew and Paul Mckenney about
> "SFQ on steroids, introducing FQ_codel", sometime this year or the
> next. Paul's1990 paper on SFQ techniques was very inspirational to us.
> For a while last year, while working on sfqred, all we did was
> implement ideas judged too hard to implement back then, on a 68020. :)
> 
> http://www.rdrop.com/users/paulmck/scalability/paper/sfq.2002.06.04.pdf
> 
>> 2) CoDel.
>> At merge time, I'd propose to add them as two separate commits.
>> 
>> The second thing is a bit stranger. I see CoDel class name as CoDel
>> "queue". I don't totally agree with this, as CoDel in my opinion is an
>> AQM, like RED. The two things are tightly related, but the dumb user
>> *will* get confused.

I was just following the existing convention of TailDropQueue and REDQueue... if
you want to refactor the naming, well, that's fine too.

> I personally view codel as the first great drop strategy, and fq_codel
> as a great aqm. I don't think codel will used by itself all that much.
> 
> To quote van from his presentation at ietf, with some digressions elided.
> 
>
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSV...
> 
> "fq_codel provides great isolation... if you've got low-rate
> videoconferencing and low rate web traffic they never get dropped.
> A lot of the issues with iw10 go away, because all that other traffic
> sees is the front of the queue and you don't know how big its window
> is and you don't care because you are not affected by it. And:
> fq_codel increases utilization across your entire networking fabric
> especially for bidirectional traffic..."
> 
> "If we're sticking code into boxes to deploy codel, don't do that.
> Deploy fq_codel. It's just an across the board win." - Van Jacobson
> 
> I can see other things being built on top of codel, such as a more
> pure packet oriented sfq (this is what is in ns2 presently), weighted
> sfq (I'd like that) + codel, htb + weighted/diffserv aware fq_codel
> (I'd really like that), or even qfq.... but codel alone, not so much.
> 
>> The confusion is even bigger in the example program, where you can set
>> the "queue" as fc_codel or CoDel.
> 
> It's certainly useful to have it available as a separate qdisc.
> 
>> I'll check again as soon as possible this topic (even checking the
>> actual RED), however maybe it's the right time to push for some
>> clarification about the different parts of the system.
>> 
>> Other than that, I hope this code will be converted in a real patch as
>> soon as possible.
> 
> I have had the submitted patches in a tree on github for some time now.
> 
> git clone git://github.com/dtaht/ns-3-dev.git
> 
> I think andrew has a few updates and additional tools not included.

Maybe, I'll check what's on my workstation when I get back in the office.

> I really, really care about getting the ns3 sim out there, as (for
> example) there is some interesting minstrel/wifi stuff in ns3 and I
> was very interested in the LTE work...
> 
> but there is no more funding available presently. I shot my wad on
> getting the bufferbloat project as far as it did before (nearly)
> collapsing. We're on life support right now, only. Am spending more
> time seeking funds than working.
> 
> I'm glad the fq_codel code is in the linux 3.5 and later kernels, I
> have an update from the latest ns2 model available as patches to linux
> 3.6 here:
> 
> But haven't got it into ns3. So, if we can get a little help on
> getting the patch set cleaned up and into ns3, that would be awesome.
> Otherwise it's a certainty I won't be able to get to it until well
> after the end of the year....
> 
> We certainly very much appreciated the initial review cycle. Sorry for
> the prospective delays...

+1

Andrew

> 
>> Cheers,
>> 
>> Tommaso
>> 
>> 
>>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queue.h
>> File src/internet/model/fq_codel-queue.h (right):
>> 
>>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/fq_codel-queu...
>> src/internet/model/fq_codel-queue.h:54: class Fq_CoDelQueue : public
>> Queue {
>> Avoid underscores, due to ns-3 naming conventions.
>> 
>>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
>> File src/internet/model/tcp-socket-base.cc (right):
>> 
>>
http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
>> src/internet/model/tcp-socket-base.cc:109: m_nextTxSequence (std::rand
>> ()),
>> beside Tom's comment, this change is not strictly related to CoDel. My
>> suggestion is to open a bug and propose a change in main ns-3 code.
>> 
>> http://codereview.appspot.com/6463048/
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[Tom Henderson, 2012-11-12 19:29:33]

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
File src/internet/model/tcp-socket-base.cc (right):

http://codereview.appspot.com/6463048/diff/1/src/internet/model/tcp-socket-ba...
src/internet/model/tcp-socket-base.cc:109: m_nextTxSequence (std::rand ()),
On 2012/11/10 22:56:39, Tommaso Pecorella wrote:
> beside Tom's comment, this change is not strictly related to CoDel. My
> suggestion is to open a bug and propose a change in main ns-3 code.

Here is the bug/feature request:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1529