[Ns-developers] ns-3.5 planning

[Mathieu Lacage]

hi all,

[lengthy email]

On Thu, 2009-04-02 at 07:23 -0700, Tom Henderson wrote:

> Where are things headed for ns-3.5?  First, Mathieu volunteered to be
> release manager for the next release, so I'd like to accept Mathieu's

I have been very quiet recently because I was busy with a few other
things, but, I spent some time thinking about our next release, and what
we could realistically put in it. I have also spent some time to
convince a co-worker, faker to help me with all the release management
aspects of this release: he agreed to help manage the bug tracker, fix
bugs, do some code reviews, install buildbot, and, more generally, take
a share of the boring painful stuff which needs to get done (and,
hopefully, the less boring stuff too). Hopefully, this will help us all
to make this release another great release.

Tom mentionned a couple of important items he would like to see done for
this release: 
1) ipv4 rework
2) code contributions
3) validation improvements

2) is a kind of meta item because it covers lots of other projects so, I
have tried to detail it below. 

1) ipv4 rework
2) 802.11n work
3) 802.11s work
4) virtual devices
5) wifi PHY work
6) validation improvements
7) various small patches present in the bug tracker
8) ipv6
9) underwater models
10) tag rework

If there is something I forgot, please, let me know.

Here is my understanding of the status of each separate item:

1) ipv4 rework: tom and I agreed to try to split it, and specifically,
try to split the API changes from the implementation changes. Right now,
the proposal is to merge the following trees:
  - mathieu/ns-3-olsr
  - tomh/ns-3-ip-interfaces: my main comment for this tree is that I am
still unsure I understand what the peer field is supposed to represent
and how it is expected to be used.
  - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
from src/node/ref-count-based.h instead of implementing Ref+Unref.

Needed followup patches:
  - new src/helper/ipv4-routing-helper.h 
  - move src/internet-stack/static-routing-protocol.h to src/node,
modify it to implement a linux-like routing table API
  - introduce a loopback device, remove Ipv4LoopbackInterface
  - remove virtual methods from Ipv4Interface
  - add src/node/arp.h, implement it in ArpL3Protocol
  - remove ::SetNode in src/internet-stack/*.h|cc: all these objects are
aggregated to a node, so, they can call GetObject.
  - remove src/internet-stack/internet-stack.cc:
      a) make UdpL4Protocol aggregate UdpSocketFactory to self from
constructor. Same for TcpL4Protocol/TcpSocketFactory.
      b) add src/core/object.h: call NotifyNewAggregate from
AggregateObject
      c) Hook in NotifyNewAggregate from UdpL4Protocol, check for
Ipv4L3Protocol, register new l4 protocol when Ipv4L3Protocol is
aggregated or when they are created

If you are scared, you are right: it's a scary big work item.

2) The 802.11n work is progressing nicely: I expect it can be merged in
a couple of weeks after one or two more review iterations

3) The 802.11s work has progressed too: I will do a review of the wifi
part once the non-wifi part has been reviewed by others. I expect tom
and gustavo to provide reviews on the non-wifi part because I can see
some aspects of the non-wifi part being somewhat related to bridging.

4) virtual devices was sent here for review a long time ago:
http://code.nsnam.org/gjc/ns-3-virtual-netdevice/ I think that it could
be useful to more users so, I would support merging it and would be
happy to help gustavo port this to ns-3-dev.

5) various wifi PHY patches are left in bugzilla. These need to be
merged. 

6) validation improvements: the plan layed out in
http://www.nsnam.org/wiki/index.php/VerificationValidationAndTesting#What_Does_it_Look_Like looks great. I am worried that this is new development and that it might be hard to make sure it matures sufficiently for this release cycle.

7) small patches: I expect faker to help me get a better grasp of what
we can help merge soon, and what we should just drop.

8) so far, ipv6 is blocked on item 1) and item 1. is far from being
finished. If I put my realistic hat on, I predict that there is zero
chance to complete 1) sufficiently early to allow ipv6 to go in this
release cycle.

9) An initial review: we need to see how long it will take to get all
the already-identified items to get fixed before considering this
feature for this release cycle

10) This was posted a while ago: tom agreed on the basic idea with minor
comments, and there were no other comments. I think that it could go in
in a couple of days once we have fixed the identified issues.

pfew ! That was long, but it's quite likely that I forgot something so,
if there is an item you are working on and you believe should be
considered for this new release cycle which will end in mid-june with a
new release, please, let me/us know _now_.

Mathieu