Difference between revisions of "Project Ideas"

From Nsnam
Jump to: navigation, search
(Path MTU discovery)
(DSR RFC compliance)
Line 146: Line 146:
== DSR RFC compliance ==
== DSR RFC compliance ==
The ns-3 DSR implementation is not following strictly the [http://datatracker.ietf.org/doc/rfc4728/ RFC 4728]. The topic has been briefly discussed in [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1895 bug# 1895].
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.

Revision as of 17:48, 20 April 2014

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

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

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.

Google Summer of Code

2013 Google Summer of Code Project Ideas

ns-3 has been admitted to 2013 Google Summer of Code. Our 2013 ideas page: 2013 GSOC project ideas

Introductory projects

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

Mentor: Tom Henderson, Vedran Miletic, or [pdbarnes@llnl.gov Peter Barnes]

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.

Perfect ARP

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.

IPv6 Routing

Mentor: Tom Henderson, Tommaso Pecorella,

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

Mentored projects

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.

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:
    • RFC 3286 An Introduction to the Stream Control Transmission Protocol
    • RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol
    • all the relevant RFCs about SCTP

Feature requests

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:

  1. Define an API to be used by L4 protocols, for PMTU probing.
  2. Update TCP to react to PMTU changes (dynamic MSS).
  3. Update TCP to not decrement its Congestion Window upon losses due to PMTU discovery (especially important for IPv6).

DSR RFC compliance

The ns-3 DSR implementation is not following strictly the RFC 4728. The topic has been briefly discussed in bug# 1895.

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.