Ns-3.11

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

This page summarizes the ongoing release planning for ns-3.11. Josh Pelkey <jpelkey@gatech.edu> will manage the release.

Proposed Release Schedule

1. January 5 -- ns-3.10 posted
2. January 5 -- ns-3.11 Open phase begins
3. March 18 -- Deadline for new feature merge
4. March 18 -- Begin the phase of small feature development and bug fixing
5. April 6 -- Small feature development and bug fixing ends
6. April 6 -- Open phase ends
7. April 6 -- Maintenance phase begins
8. April 30 -- Maintenance phase ends
9. April 30 -- Code freeze phase begins
10. April 30 -- ns-3.11-RC1
11. May 3 -- ns-3.11-RC2
12. May 6 -- ns-3.11-RC3
13. May 8 -- ns-3.11 posted
14. May 8 -- Code freeze phase ends
15. May 8 -- ns-3.12 Open phase begins

As described in the Roadmap there are three broad sections in the release schedule. During the open phase, people wanting to include a new feature in ns-3.11 should contact Josh and arrange to have their features merged into ns-3-dev. You will be expected to provide the following:

• A mercurial patch, bundle or repo against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that we can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests successfully on all of our target machines
• A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to generate release notes and will be provided to maintainers if a code review is indicated)
• Some kind of unit or system test that can be used to determine if your feature is actually working at each stage of the integration

One of us will take a quick look at your proposed addition and determine if a code review is required. According to the book of instructions a code review requiring positive acknowledgment by maintainers is indicated if:

• Your proposed feature does not work with all models or on all platforms
• Your feature changes pre-existing APIs
• Your feature crosses maintainer boundaries

Just to be safe, we will probably run a feature submission by at least one maintainer according to the general area of applicability of the feature. For example, if you submit an entirely new device driver model, as a courtesy we will run this submission by the maintainers of the current devices. The maintainers won't have any responsibility to positively ack the submission, but we will take some time to allow a reasonable review.

The open phase is divided into two parts: new feature merge period and small feature development and bug fixing.

During the new feature merge period we can:

• Review the code that might be merged
• Clean up the bug tracker: solve as much bugs as possible
• Merge the new features that has +1 and from maintainers

After February 14th, the new feature merge period ends and small feature development and bug fixes begins. During the latter, no more merges are accepted and we can:

• Accept limited, small, self contained changes/features to ns-3-dev and to merged new features. As specified before, no more merges are accepted
• Review the code to be merged for next releases
• Cleanup the ns-3-dev bug tracker, solve as much bugs as possible

The end of the small feature development and bug fixes coincides (March 5th) with the beginning of the maintenance phase. No new features may be added, but the maintainers may check in fixes to bugs; and people with new features that have been accepted and previously merged may fix bugs in existing features. Please don't try to sneak in more new features or you may have your whole feature set removed at the release manager's discretion. You can ask if you want to add small, self-contained features, but there are no guarantees that we will okay them.

On March 30th, 2011, we are going to enter the code freeze phase. This indicates that we are in the final stages of the release and our primary goal is stability. During the code freeze phase, only P1 bugfixes will be allowed to be checked in. Our goal will be to reduce the number of P1 bugs to zero before the release of ns-3.11.

We will reserve the right to veto (and remove) any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process.

Candidate Contributions for Inclusion in ns-3.11

• Virtual Access Point (VAP) for WiFi
  • insufficient reviews
• GetRelativeVelocity() for MobilityModel
  • insufficient reviews
• PhySimWifi
  • insufficient reviews
• thread-safe implementation of ScheduleWithContext
• simple wireless models
• Jamming model
• MPLS
• TCP Vegas (blocked by lack of progress on TCP congestion control architecture)
• NetAnim trace hooks for wireless

ns-3.11 Features Merged

• ns-3 click
• ns-3 openflow

The ns-3.11 Bug List

Highest Priority

• bug 1038 -- Time::Get*Seconds () return signed integer while actually returning unsigned.
• bug 1044 -- Seconds (1e-9) creates Time that is not IsPositive ()
• bug 445 -- Class name rename Scalar->Dimensionless
• bug 976 -- wifi-wired-bridging regression test fails because of rounding errors in mobility model
• bug 1042 -- AODV RERR implosion (missing RERR_RATELIMIT)
• bug 1079 -- MPI code doesn't compile
• bug 1095 -- MPI enable configuration failed in Fedroa 14
• bug 1099 -- AODV performance problems

High Priority

• bug 1033 -- airtime-metric
• bug 409 -- Routing messages can exceed MTU, and fragmentation not supported
• bug 631 -- RealtimeSimulatorImpl not compatible with python bindings
• bug 555 -- DCF immediate access bug
  • patch existing / needs further testing and verification
• bug 521 -- Ipv4 global routing inefficient
• bug 938 -- missing Doxygen
• bug 1018 -- mobility --> helper --> mobility circular dependency
• bug 1017 -- node --> internet-stack --> node
• bug 756 -- Build should be configurable to avoid using optional components
• bug 912 -- modeling processing delays

Possibly easy fixes

• bug 976 -- udp tx buffer is not fixed size
  • possibly WONTFIX
• bug 1006 -- UDP socket tx buffer back pressure needed
  • somewhat related to bug 141
• bug 996 -- TCP FIN-WAIT-2 bug
  • pinged Adrian about this one, likely fixed
• bug 272 --InternetStackHelper::Install does not mention the fact that it aggregates PacketSocketFactory
• bug 1038 -- Time::Get*Seconds () return signed integer while actually returning unsigned
• bug 798 -- In test.py: CRASH: TestSuite ns3-tcp-cwnd CRASH: TestSuite ns3-tcp-interoperability.
  • is this still valid?
• bug 957 -- Issue with test.py
  • patch exists
• bug 190 -- Reminder: NS_LOG_APPEND_CONTEXT
  • remove from tracker?

For Josh Pelkey -- me

• bug 582 -- tags are not serialized and deserialized from Packet::Serialize and Packet::Deserialize
• bug 1039 -- TCP Nagle algorithm and RTO calculation
• bug 730 -- Enabling fragmentation at run-time breaks simulation

Feature requests

• make spectrum model compatible with ns-3 WiFi
• ns-2 packet UID feature
• API for TOS bytes (issue 897) may wait for netfilter support
• Chord/DHT (authors are planning to revise code based on comments)
• app store and build system refactoring
• fragmentation for IPv4: being worked by Vedran Miletic
• TDMA wireless model
  • being worked on by Hemanth Narra

To Do List

Mitch Watrous is working on the following modular build-related items:

1. Update documentation: fix module paths.
2. Update documentation: how to use the configuration (.ns3rc) file

Documentation updates are planned:

1. Update project documentation for modular build changes (Mitch Watrous)
2. Split existing manual to a "developers manual" and a "model library" manual
3. Remove "testing" document; move pieces to developers manual and model library manual
4. Add python page to manual
5. Remove duplicate doxygen documentation
6. Create module template that can be easily cloned
7. Create datasheet for ns-3
8. Create cheatsheet(s) for ns-3
9. Write down duties of release manager somewhere

Coding style update is being considered.