Google Summer of Code

This year, the Google Summer of Code has started again and has accepted the ns-3 project as a mentoring organization. This means that Google will fund through this program one or more students to work on a student's project and that the ns-3 project will work hard to make this a great experience for everyone involved.

Of course, to apply for this program, every student must complete a project proposal. The shortlist of projects below is really just a starting point: it lists some projects which we believe could be of interest to you but this list is by no means exhaustive. If you have a crazy blue-sky idea and are especially excited about it, we want to hear about it !

Before applying for an ns-3 project, you really should contact us and talk with us about your project. There are many ways to do so but the best way is to reach us through our developer mailing list below:

  • The project's developer mailing-list: subscribe Here.
  • The project's irc channel: #ns-3 on irc.freenode.net
  • The project's gsoc administrator (Mathieu Lacage)
Before submiting a proposal, we strongly encourage you to take a number of simple steps:
  • Make sure you come up with a clear description of the scope of your project.
  • Once you have clearly defined the scope of your project, you will most likely find it reasonably easy to come up with a small schedule which includes a few milestones (we recommend trying to come up with 3 to 5 milestones for a 3 month project).
If your proposal is accepted, there are a few guidelines we would like you to follow and there are a few things you should expect to happen:
  • Be prepared to spend on average 2 to 5 hours a week with your mentor either through IM/email or through the phone/sip/skype: english is our primary communication language.
  • In the early phase of the project, your mentor will try to work closely with you to monitor your progress and update your schedule. Don't worry if your schedule slips: this happens all the time to every developer. What matters is that you and your mentor understand why the schedule is slipping and how to update it to reflect reality.
  • At all times, unless you want to discuss confidential/private matters, please, communicate with your mentor over our developer mailing-list.
  • If your mentor becomes unresponsive or if you experience difficulty communicating and working with him, please contact the project's gsoc administrator.

Here is the guide for student applications.

Most of the ideas listed below typically require basic C++ programming (you have to be able to write a couple of C++ classes, to know what a method is, etc). Beyond this, each project contains a shortlist of basic skills which we believe are needed to be able to grasp the project's scope and start hacking quickly. Even if some of these ideas seem complex or beyond your reach, don't forget that our mentors will provide the necessary technical expertise so you can focus on building a working solution rather than get lost in the details. The list below is very diverse which reflects the fact that there are a lot of very different things which could be done to improve and contribute to this project: kernel programming, statiscal analysis, gui programming, algorithm implementation and optimization, and, parallel programming.

Note: To consistently respond to inquiries, we have posted wiki pages that provide more details for each of these project suggestions, so please also look at our suggested projects page.

Performance evaluation and optimization

This project has a very broad scope: the goal here is to choose performance metrics, obtain performance data from a set of selected real simulation scenarios and, then, attempt to optimize some of the core data structures based on the initial performance data.

Experience with event-driven simulators would tend to support the idea that an important part of this project will be to implement and carefully optimize a so-called Calendar Queue (R. Brown. Calendar Queues: A Fast O(1) Priority Queue Implementation for the Simulation Event Set Problem. Communications of the ACM (CACM), volume 31, number 10, pages 1220--1227, October 1988.).

Requirements:

  • Some interest in algorithms,
  • Basic understanding of computer architecture,
  • Basic C++ programming, and,
  • Basic experimental statistics

Linux kernel network stack integration

The goal here is to be able to run a minimally modified (ideally, unmodified) linux kernel network stack (initially, ipv4/tcp) within our network simulator. There are two distinct components to this project:

  • Implement a set of glue layers to provide a 'kernel' environment for kernel code. This will require: a re-implementation of the basic kernel library functions (memory allocation, timers, etc.), the implementation of a fake linux network driver to act as a bridge between the ns-3 NetDevice class and the linux struct net_device, and, the implementation of an ns-3 fake socket to act as a bridge between ns-3 applications and linux kernel sockets.
  • Re-use the network namespace code to allow instanciating multiple network stacks within a single address space. This area of the kernel code is still undergoing heavy development so, we expect that a lot of debugging will have to happen, as well, as, potentially, cleaning up some rought edges of the kernel implementation.

Requirements:

  • Some experience with C/C++ programming,
  • Basic understanding of Kernel architecture,
  • Not being afraid of having to read large amounts of code.
We believe that this is really a great project for a motivated student because they will get to go through large amounts of interesting and twisted code, hence learning a lot in the process.

Parallel simulations

There are two main reasons why parallel simulations are important:

  • Decrease the overall wall-clock time of a simulation scenario: we want to go as fast a possible, and,
  • Make it possible to simulate a very large scale scenario which would never fit within the memory of a single machine.
For this project, we would like to focus on the former aspect and attempt to make automatic good use of a NUMA multicore platform (the latter is more interesting to us). The goal here is to use posix threads and synchronization primitives to implement a classic conservative synchronization scheduler (Parallel simulation: parallel and distributed simulation systems by Richard M. Fujimoto is a great introduction to these) and to observe its performance on real-world simulation scenarios using off-the-shelf hardware. 2 and 4-way systems will be available for development and testing purposes.

Requirements:

  • Basic C++ programming,
  • Some good understanding of computer architecture, and,
  • Basic thread programming.

GUI developement

The project's core purpose is to provide a research network simulator so, its user-friendliness is not very high: we merely provide a library to develop simulation scenarios. It would be nice to develop a GUI to make the user's learning curves less steep.

The scope of this GUI will depend largely on the interest of the contributors but our long-term goal is to provide GUI-based solutions to the set of tasks outlined below:

  • Physical connectivity layout and visualization,
  • IP connectivity layout and visualization,
  • Mobility configuration and visualization,
  • Parameter configuration,
  • Trace/instrumentation configuration, and,
  • Output analysis.

Requirements:

  • Basic Python programming,
  • GTK+ or QT prior experience, and,
  • Some experience in UI design

Real-world application integration

There are different reasons to integrate real-world applications in a network simulator:

  • Save yourself a lot of work to avoid having to re-implement the application just to run it in a large-scale simulation experiment, and,
  • Make it easier to compare simulation results with real-world results
Quagga and Xorp are two routing daemons which implement a number of useful routing protocols: Quagga has already been ported to other network simulators so, the experience drawn from these past experiments should be re-used to attempt to minimize the amount of patching required to Quagga.

Another potential alternative is to port protolib to ns-3.

Requirements:

  • C++ programming

Statistical framework for network simulation

This project is an ideal project for the student who is interested in the application of statistical and data collection methods to simulation tools, and who would like to build a software-based framework to carry out a large number of simulation experiments in a statistically sound way. This framework would:

  • allow an experimenter to focus on a particular metric and generate automatically a sufficient number of independent replications to meet desired statistical criteria such as a confidence interval
  • provide a set of routines to gather samples from measurement points in the simulation and to generate statistics on these samples
  • study techniques for efficient data collection including the application of sampling techniques to estimate metrics when processing of fine-grained trace data is not scalable
  • provide a way for the experimenter to properly initialize random number generators for a large number of runs

A research group has developed such a framework for the previous simulation tool (ns-2) that our project is replacing, and this framework might be a starting point for our ns-3 framework: ns2measure.

Requirements:

  • proficiency in C++
  • proficiency in statistical methods
  • some ability to code a GUI is preferred (e.g. PyGTK, Qt)


Generated on 18/Nov/2008 at 16:00:02. Thanks to the XORP (http://www.xorp.org) project for this stylesheet.