Ns-3.8

From Nsnam
Revision as of 21:29, 3 May 2010 by Jpelkey (Talk | contribs)

Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - 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

  1. January 27 -- ns-3.7 posted
  2. January 27 -- ns-3.8 Open phase begins
  3. March 8 -- Deadline for new feature merge
  4. March 8 -- Begin the phase of small feature development and bug fixing
  5. March 27 -- Small feature development and bug fixing ends
  6. March 27 -- Open phase ends
  7. March 27 -- Maintenance phase begins
  8. April 21 -- Maintenance phase ends
  9. April 21 -- Code freeze phase begins
  10. April 21 -- ns-3.8-RC1
  11. April 25 -- ns-3.8-RC2
  12. April 28 -- ns-3.8-RC3
  13. May 1 -- ns-3.8-RC4
  14. May 3 -- ns-3.8 posted
  15. May 3 -- Code freeze phase ends
  16. May 3 -- 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 19th, 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.

ns-3.8 Features Merged

Topology read system (Inet/Orbis)

Matrix propagation loss model

MPI-based parallelization

WiMAX

Redo ASCII and pcap Traces

Gauss-Markov Mobility Model

Steady state random waypoint mobility model

802.11n block ack

Enhancements to src/core/random-variable.cc/h

Two ray ground radio propagation model

Move propagation models to src/common

Pareto rng constructors using scale and shape instead of mean and shape

Bugs Fixed

  • bug 155 - std::ostream & os" parameters not Python friendly
  • bug 184 - GtkConfigStore do not support ConfigureDefault
  • bug 407 - OLSR is missing HNA support
  • bug 414 - No ReceiveErrorModel in SimpleNetDevice
  • bug 602 - WifiRemoteStation lacks information about the access class of outgoing packets
  • bug 622 - [PATCH] Friendly names for pcap traces
  • bug 683 - Helper methods for pcap tracing with explicit filenames
  • bug 706 - Backoff counting when starting NS.
  • bug 720 - TapBridge creation fails from a script outside the ns3 tree
  • bug 731 - Send function in point-to-point-net-device fails to check the return value of the Dequeue function
  • bug 747 - Listening TCP socket closes on RST
  • bug 748 - Cloned TCP socket uses wrong source address
  • bug 772 - AODV is unable to correctly buffer packets waiting for route reply
  • bug 777 - AODV ignores specified outgoing interface in RouteOutput()
  • bug 778 - OLSR ignores specified outgoing interface in RouteOutput()
  • bug 787 - Addition of Two Ray Ground model to propagation loss model and tests
  • bug 788 - OLSR_NEIGH_HOLD_TIME should be 3 times OLSR_REFRESH_INTERVAL
  • bug 789 - [PATCH] Globalrouting externalroutes to use the new GetRootExitDirections()
  • bug 794 - Ipv4Mask constructor for "/yy"-notation is wrong
  • bug 796 - TCP bug in ns-3-dev branch : Crash detected during retesting of Chord on ns-3-dev branch
  • bug 797 - Enhancements to src/core/random-variable.cc/h
  • bug 801 - ns-3.7 and SVN not coexisting nicely
  • bug 802 - Minstrel algorithm causes segmentation fault
  • bug 804 - null-pointer references in 3.7 internet stack
  • bug 806 - TCP doesn't work over a CSMA link
  • bug 807 - ns2-mobility-helper.cc: node id parsed wrong
  • bug 809 - Missing Python binding for Ipv4GlobalRouting::GetRoute
  • bug 810 - In TCP, Socket::GetSockName() does not return the local socket address
  • bug 812 - Assert when getting socket in RecvReply for AODV
  • bug 813 - Nqos AP sends packet to non associated STA
  • bug 814 - Function logging causing assert in wireless examples
  • bug 815 - waf shell file descriptor leak
  • bug 816 - tap-creator deadlock when python bindings enabled
  • bug 817 - Pareto rng constructors using scale and shape instead of mean and shape
  • bug 818 - TCP Socket implementation does not set ACK flag on retransmits
  • bug 819 - Build break when gtk not installed
  • bug 820 - Bad things happen in test.py when logging is enabled
  • bug 821 - AODV asserts with function logging enabled
  • bug 822 - Move Mtu attribute from NetDevice base class to subclasses
  • bug 825 - UDP-Client-server's packet loss counter not properly reset
  • bug 828 - PacketSocket::Close does not unregister protocol handler
  • bug 829 - TCP unbound memory problem (pending data)
  • bug 833 - OnOffApplication with PacketSocket: sniffs all traffic
  • bug 834 - Incorrect signature of Ipv4FlowProbe::DropLogger
  • bug 835 - Unlimited receive queues in sockets == evil
  • bug 836 - Delay is incremented over time with BsUplinkSchedulerSimple and BsUplinkSchedulerRtps
  • bug 838 - ns-3 can't compile on MacOS with 32bit processor
  • bug 839 - TestSuite wimax-ss-mac-layer crashes on Darwin 9.8.0 Power Macintosh
  • bug 840 - BS scheduler does not support fragmentation for UGS flows
  • bug 841 - Multicast transmission breaks with QoS Wifi
  • bug 844 - YansWifiPhy::GetPowerDbm off-by-one problem when calculating Tx power
  • bug 847 - Segfaults on BaseStationNetDevice with OnOffApplication and rtPS sched
  • bug 849 - stray patch files in lwip directory
  • bug 850 - Ipv4GlobalRouting::LookupGlobal bug
  • bug 855 - waf dies badly when switching from debug to optimized build or vice versa
  • bug 856 - initialize vbl
  • bug 857 - Link-Local Multicast handle in Ipv4 Output processing
  • bug 859 - Output interface estimation for the source address bound socket in IPv4 Raw socket
  • bug 860 - waf sometimes dies while executing ns3header or gen_ns3_module_header tasks in case of parallel jobs
  • bug 862 - NotifyInterfaceUp() Adds network route even when netmask is /32
  • bug 863 - Wrong Scalar arithmetics
  • bug 864 - Invalid return value in UdpSocketImpl::Send and Ipv4RawSocketImpl::Send
  • bug 865 - Ipv4RawSocketImpl::RecvFrom does not return from address all the time.
  • bug 866 - WiMAX mobility models not aggregated to Node
  • bug 867 - Minor bug in Ipv4L3Protocol::Send()
  • bug 868 - invalid packet size after Ipv4L3Protocol::Send
  • bug 872 - ns3::PcapFileWrapper::Write explodes stack
  • bug 873 - Queue occupancy counter not decremented in WifiMacQueue::Remove()
  • bug 876 - Tcp socket does not handle ShutdownRecv correctly
  • bug 877 - python bindings broken with multiple inheritance ?
  • bug 880 - Node sending a packet to itself via 127.0.0.1 aborts
  • bug 885 - Error in Ascii tracing in Python examples
  • bug 888 - Writing ascii trace to addtional tests fails
  • bug 891 - WiMAX device helper does not include propagation loss model by default
  • bug 894 - ./waf --run error message upon segfault
  • bug 895 - SimpleOfdmWimaxPhy SNR computation
  • bug 899 - EmuNetDevice::SetPromiscReceiveCallback not implemented