Ns-3.8: Difference between revisions
Line 92: | Line 92: | ||
* ''background'': http://www.nsnam.org/wiki/index.php/GSOC2009NetworkAddressTranslation | * ''background'': http://www.nsnam.org/wiki/index.php/GSOC2009NetworkAddressTranslation | ||
=== Two ray ground radio propagation model === | === Two ray ground radio propagation model === |
Revision as of 21:05, 3 February 2010
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.8. The release manager is Josh Pelkey <jpelkey@gatech.edu>.
Tentative ns-3.8 Release Schedule
- January 27 -- ns-3.7 posted
- January 27 -- ns-3.8 Open phase begins
- March 8 -- Deadline for new feature merge
- March 8 -- Begin the phase of small feature development and bug fixing
- March 27 -- Small feature development and bug fixing ends
- March 27 -- Open phase ends
- March 27 -- Maintenance phase begins
- April 13 -- Maintenance phase ends
- April 13 -- Code freeze phase begins
- April 13 -- ns-3.8-RC1
- April 15 -- ns-3.8-RC2
- April 19 -- ns-3.8-RC3
- April 22 -- ns-3.8-RC4
- April 27 -- ns-3.8 posted
- April 27 -- Code freeze phase ends
- April 27 -- ns-3.9 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.8 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 March 8th, 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 27th) 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 April 13th, 2010, 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.8.
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.8
Underwater Acoustic Network Device
- review location: http://codereview.appspot.com/87043
- reviewer(s): Craig Dowell, Faker Moatamri
- status: postponed to NS-3.8
- Developer: Leonard Tracy
- background: http://mailman.isi.edu/pipermail/ns-developers/2009-June/006148.html
WiMAX
- code location: http://code.nsnam.org/iamine/ns-3-wimax-release/
- reviewers: Faker Moatamri, Mathieu Lacage, Tom Henderson
- Developer: Amine Ismail
- status: will be merged at the starting of ns-3.8
- background: http://mailman.isi.edu/pipermail/ns-developers/2009-August/006329.html
NHDP
- Code: No available code for the moment
- Developer: Tom Wambold
- Status: waiting to the code to be ready to review
MPI-based parallelization
- review location: http://codereview.appspot.com/109068
- code location: http://code.nsnam.org/jpelkey3/ns-3-distributed
- reviewers: Faker Moatamri, Craig Dowell, Tom Henderson, Mathieu Lacage
- Developer: Josh Pelkey
- Status: will be merged at the starting of ns-3.8
- background: http://mailman.isi.edu/pipermail/ns-developers/2009-November/006927.html
Internet stack roadmap
- Work on various parts of the TCP/IP stack is tracked on this wiki page
NAT traversal
Two ray ground radio propagation model
- Review location: http://www.nsnam.org/bugzilla/show_bug.cgi?id=787
- Reviewers: Pavel Boyko, Mathieu Lacage
- Developer: Tom Hewer
- Status: waiting for some more +1
- Background: http://en.wikipedia.org/wiki/2-Ray_Ground_Reflection_Model
Steady state random waypoint mobility model
- Review location: http://codereview.appspot.com/193105/show
- Reviewers: Mathieu Lacage
- Developer: Denis Fakhriev
- Status: +1 from Mathieu, ready for merge?
- Background: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.7557
Redo ASCII and pcap Traces
- review location: http://codereview.appspot.com/196058
- reviewer(s): Mathieu Lacage
- status: Under review
- Developer: Craig Dowell
- background: http://mailman.isi.edu/pipermail/ns-developers/2010-January/007352.html
ns-3.8 Features Merged
The ns-3.8 Bug List
High Priority Blockers
High Priority Non-Blockers
P2 Bugs with patches
Bug 341 - Get unexpected dropped packets when using SetSendCallback with heavy traffic
- Assigned to: Craig Dowell
- Patch available, but old and possibly untested (from 2008!)
- submitter isn't using ns-3 anymore
- Mathieu has suggested (back in 2008) that this could be tricky
Bug 794 - Ipv4Mask constructor for "/yy"-notation is wrong
- Assigned to: Craig Dowell
- +1 from Tom and Craig, looks ready to go
Bug 231 - SocketAddressTag needs to be removed from a packet before forwarding the packet to the user
- Assigned to: Faker Moatamri
- Possibly trivial now with RemovePacketTag API
Bug 778 - OLSR ignores specified outgoing interface in RouteOutput()
Assigned to: Gustavo J. A. M. CarneiroPatch from Tom, Gustavo pretty much +1looks ready to go
Bug 788 - OLSR_NEIGH_HOLD_TIME should be 3 times OLSR_REFRESH_INTERVAL
Assigned to: Gustavo J. A. M. Carneirolooks ready to go
Bug 747 - Listening TCP socket closes on RST
Assigned to: Josh Pelkey+1 from me, looks ready to go
Bug 748 - Cloned TCP socket uses wrong source address
- Assigned to: Josh Pelkey
- Patch proposal from Fabian Mauchle
- need to look at this
Bug 555 - DCF immediate access bug (CRIT)
- Assigned to: Mathieu Lacage
- patch needs review
Bug 602 - WifiRemoteStation lacks information about the access class of outgoing packets
- Assigned to: Mathieu Lacage
- patch needs review
Bug 521 - Ipv4 global routing inefficient
- Assigned to: Tom Henderson
- I think this one was re-opened, and not sure if the patch is still valid
- I know that Tom has mentioned he is working on this one
Bug 385 - Add a generic "sequence number" class
- Assigned to: Mathieu Lacage
- patch exists, but there is still some issues about implementation
- tracing is important for this one
P2 Bugs without patches
Bug 419 - *Helper::SetAttribute* methods sometimes painful to use
- Assigned to: Craig Dowell
- old and consistently deferred
Bug 796 - TCP bug in ns-3-dev branch : Crash detected during retesting of Chord on ns-3-dev branch (CRIT)
- Assigned to: Craig Dowell
- logs attached to this one
- worked in ns-3.6 but not ns-3.7
Bug 184 - GtkConfigStore do not support ConfigureDefault
- Assigned to: Faker Moatamri
- another oldie
- Mathieu says, "This bug is now really about making GtkConfigStore do what ConfigStore already does and provide a GUI for the 'default' + 'global' values."
Bug 190 - Reminder: NS_LOG_APPEND_CONTEXT
- Assigned to: Faker Moatamri
- On 2009-11-24, Gustavo says, "I think it may be pointless to keep this bug open. It's not a bug, it's more of a development goal..."
Bug 409 - Routing messages can exceed MTU, and fragmentation not supported
- Assigned to: Mathieu Lacage
- Quick fix available
- IP fragmentation support for UDP is needed
Bug 492 - It would be useful to have a pre-simulate state (and post)
- Assigned to: Mathieu Lacage
- some ideas are posted, nothing concrete
Bug 631 - RealtimeSimulatorImpl not compatible with python bindings
- Assigned to: Mathieu Lacage
- lots of discussion here, no consensus it seems
Bug 791 - We need to get rid of waf --regression
- Assigned to: No One
- seems important to me
Bug 702 - Make global routing robust to link/device events
- Assigned to: Tom Henderson