One way to get involved with ns-3 is to work with a mentor on a suggested project. These are typically project suggestions that would be valued contributions but the proposer does not have enough time to do it himself or herself, but is willing to mentor someone else to do it.
Another possibility for students is to get involved in the Google Summer of Code program. This program is administered by Google and acceptance is competitive.
How does a mentored project work? You contact the mentor and describe your interests and availability to work on the module. You and the mentor will work out a plan to regularly review and discuss the development of your module, following the guidelines for developing new models for ns-3. You will set up a public repository somewhere such as a site listed here or your own mercurial server.
Not all projects are mentored, nor do they all need to be. Please suggest new project ideas on this page and whether you would mentor them.
- 1 Introductory projects
- 2 Projects needing completion
- 3 Mentored projects
- 4 Feature requests
This project category is for smaller, simpler projects for new developers to get started. If you would like to work on one of these, please coordinate with the named mentor.
Sockets should support the setting of QoS
Mentor: Tommaso Pecorella
Reducing header dependencies
Mentor: Tom Henderson
Bug 1832 describes some software maintenance that could be performed on ns-3, to reduce unnecessary header dependencies. Patches are welcome for even a small part of the overall solution.
I would suggest to adapt deheader and place it in utils/deheader.py. Running utils/deheader.py should list all the unnecessary includes, and let the maintainers decide whether they want to go clean these up.
Daniel Camara performed this work already, but the work was not finished and merged. Bug 1832 has the details.
Fixing Doxygen errors and warnings
Bug 938 describes an overall effort to eliminate Doxygen warnings (primarily, for missing Doxygen) from our modules. Any patches that contribute to the overall goal would be welcome. Contact one of the mentors if interested.
Projects needing completion
Some projects were started in the past and never brought to completion.
Wifi rate control example
ns-3 supports many different wifi rate controls, but there isn't a good example program that allows users to clearly contrast the performance of different ones. The example program 'examples/wireless/multirate.cc' does this a little bit, but it focuses on sampling the throughput.
The suggested project is to work with improving multirate.cc so that users can clearly see the difference between selecting the different rate control algorithms, perhaps by running for longer amount of time and finding a way to plot the rate chosen by the control algorithm as a function of time.
Bug 187 has a patch that needs further review, updating to ns-3-dev, and finishing off. The enhancement is described as follows:
We need an implementation of ARP which avoids the generation of ARP request/reply packets and assumes a 'perfect' ARP table is always available and up-to-date.
There is little support for global (i.e. god) routing routing for IPv6. This was started in a 2011 ns-3 summer of code project. IPv6 can use Dynamic routing (RIPng is included in ns-3.20), but more protocols are welcome.
However, global routing is still needed. Moreover, all the ad-hoc routing protocols are currently IPv4-only.
Refactor AODV Hello
Bug 1188 describes a problem with the current AODV implementation that Hellos are sent even without any active routes.
We would like for someone to align our implementation with the AODV RFC (or with working implementations) in this regard.
Mentor: Daniel Lertpratchya
This section lists project ideas for which there is interest by an ns-3 developer or maintainer to serve as a mentor in the development of a new feature for ns-3.
Please do not apply for mentoring help on a class project unless you have approval from the instructor to receive mentoring.
Decouple traffic generation from sockets
Mentor: Tom Henderson
All ns-3 simulations are IP based but there is no template for how to do this for non-IP-based stacks. One issue that should be addressed in the long term is that applications that generate traffic are strongly coupled to the sockets interface. It would be nice to decouple the traffic generation aspects of these applications from the sockets-related code.
- summary: Proposed decoupling to generalize applications
- ns-developers post: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html
- code location: http://code.nsnam.org/laprisee/ns-3-mp/
- status: Was under discussion in the summer.
SCTP (Stream Control Transmission Protocol)
Mentor: Tommaso Pecorella
SCTP is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails. Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.
- Required Experience: C++
- Bonus Experience: L4 protocols understanding
- Interests: L4 protocols modeling and simulation
- Difficulty: medium
- Recommended reading:
The following projects have been suggested in the past. If you are working on them, please let us know on the developers or users list so that we can coordinate activities. If you want to add a project, please describe it below.
Path MTU discovery
When a L4 packet is passed to the IPv4 or IPv6 stacks, the MTU (i.e., the size of the outgoing IP packets) is usually set to the local interface MTU. Or so it is the popular belief. Using the local interface MTU might lead to IP-level fragmentation, more overhead, and poor network performance.+
As a consequence, multiple techniques to discover the end-to-end MTU (called Path MTU) are available. The current PMTU discovery ns-3 capability status is listed below.
Path MTU discovery for IPv4 stacks
Status: Being worked on by Vedran Miletic
There is no path MTU discovery implemented for IPv4. This makes guessing the end-to-end MTU imperative for ns-3 simulations. We would welcome a contribution that introduced path MTU discovery to ns-3.
Vedran expressed interest in working on PMTU discovery.
Path MTU discovery for IPv6 stacks
path MTU discovery is implemented in ns-3's IPv6 stack.
Packetization Layer Path MTU Discovery
RFC 4821 describes a method to detect PMTU at packetization (i.e., L4) level. This is another good candidate to be implemented.
L4 compliance with PMTU
Even if IPv6 is able to detect PMTU, and IPv4 could be, currently there is no API to probe for a specific PMTU from L4 (e.g., UDP, TCP, etc.). Moreover, TCP is blind with respect to PMTU. I.e., its MSS (Maximum Segment Size) is fixed.
In order to reproduce real TCP performance it is of paramount importance to:
- Define an API to be used by L4 protocols, for PMTU probing.
- Update TCP to react to PMTU changes (dynamic MSS).
- Update TCP to not decrement its Congestion Window upon losses due to PMTU discovery (especially important for IPv6).
DSR RFC compliance
It would be nice to have a switch to change from the current behaviour to the "RFC-strict" behaviour. As a byproduct, DSR could be updated to support IPv6. Although not explicitly stated by the rFC, DSR can be used for IPv6 as well.