[Ns-developers] status update: ns-3.5 planning

[Mathieu Lacage]

On Thu, 2009-04-23 at 11:15 +0200, Mathieu Lacage wrote:

> >   - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
> > from src/node/ref-count-based.h instead of implementing Ref+Unref.
> 
> Tom is working on the above

same as before.

> 
> > 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
> 
> I have done both below at http://code.nsnam.org/mathieu/ns-3-ip-loopback
> This patchset changes most regression tests because it introduces a new
> 'loopback' device which thus changes the index of all other devices, and
> thus, changing the output of all traces and the names of all pcap files.
> (note: I also did fix a couple of XXX from the multi-address merge)

tom reviewed it and said he would look into merging this into ns-3-dev
himself.

> I am going to work on these below next:
> 
> >   - add src/node/arp.h, implement it in ArpL3Protocol

above not done.

Below in progress by faker. See bug 557

> >   - 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
> 
> Final review is underway for the above

merged now.

> 
> > 
> > 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.

tom did a review. I did not see any reply to that review so, I don't
know the status.

> > 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.
> > 

initial patch for merging reviewed. More work seems needed.


> > 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.
> 
> 
> The above did not make progress: ipv4 work is getting higher priority.

same status.

> 
> > 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_.
> 
> other items were raised:
> 
> 1) multicast-related issues by Fabian Mauchle: some of these look like
> bugs we can fix for this release. Others need API discussion on list.

I believe that all of these issues were resolved. A patch has been
merged.

> 2) multi-device radio interference modelization by Nicola Baldo: It is
> not ready to be really reviewed yet and I doubt it will be ready for
> this cycle. Hopefully, we can aim for the next cycle for this feature.

No new information about this.

Mathieu