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

[Mathieu Lacage]

On Tue, 2009-04-14 at 15:32 +0200, Mathieu Lacage wrote:

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

Both of the above have been merged.

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

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

>   - introduce a loopback device, remove Ipv4LoopbackInterface
>   - remove virtual methods from Ipv4Interface

I am going to work on these below next:

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

Final review is underway for the above

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

The below is being aggressively pursued by craig.

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

Bugzilla is getting under control: a lot of small bugs are getting
fixed.

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


The above did not make progress: ipv4 work is getting higher priority.

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

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.

If you feel I forgot something, please, let me know.

regards,
Mathieu