GSOC2014Projects: Difference between revisions

From Nsnam
Jump to navigation Jump to search
(add some initial project ideas)
Line 87: Line 87:
= Project Ideas =
= Project Ideas =


'''To be completed by the project and mentors at a future date'''
Please see [[GSOC2013StudentGuide | last year's page]] for guidelines on how to create project ideas.
 
'''Note to students:''' These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.
 
===  Decouple traffic generators from sockets  ===
 
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]
 
* ns-3 uses applications that are part traffic generator, part socket-based application.  The traffic generation part is not decoupled from the sockets API, making it hard to use applications over non-socket APIs such as future sensor networks.  This project would work on a cleaner separation between traffic generator (OnOffApplication) and sockets.
* ''Required Experience:'' C++, sockets API
* ''Interests:''
* ''Difficulty:'' easy/medium
* ''Recommended reading:''
** Unix Network Programming (Stevens) or equivalent
 
===  ARP and NDisc cache visibility  ===
 
Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]
 
* There is no API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches.  Something similar to how PrintRoutes is done for IPv4 would be useful.  Additional work on this project could focus  on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP).
* ''Required Experience:'' C++
* ''Interests:'' IPv4 and Ipv6
* ''Difficulty:'' easy/medium
* ''Recommended reading:''
** source code in src/internet, and the bugs mentioned above
 
=== INSTOOLS for ns-3 ===
 
Mentors:  [mailto:tomh@tomh.org Tom Henderson]


Please see [[GSOC2013StudentGuide | last year's page]] for guidelines on how to create project ideas.
'''INSTOOLS for ns-3:''' [http://groups.geni.net/geni/wiki/InstrumentationTools INSTOOLS] is a software instrumentation package for GENI experiments.  It logs a lot of artifacts of experiments, such as ARP and IP routing tables, Netflow graphs, etc, to databases.  The aim of this project is to instrument ns-3 nodes to capture as much of this data as is applicable.  A bonus is to try to integrate further with ProtoGENI and INSTOOLS such as making the ns-3 data archived just like it was a GENI experiment.
* ''Required Experience:'' Familiarity with Linux networking and with C++ programming. 
* ''Bonus Experience:'' Experience with GENI and/or Emulab
* ''Interests:'' Simulator tool development, integration with testbed experiments
* ''Difficulty:'' Medium
* ''Recommended Reading:'' http://groups.geni.net/geni/wiki/InstrumentationTools
 
=== bufferbloat-related models ===
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
 
'''bufferbloat models:''' [https://www.youtube.com/watch?v=-D-cJNtKwuw Bufferbloat] is an interesting contemporary research topic.
This project proposal is to develop models, examples, and visualizations around the bufferbloat problem.  Some technical solutions include Linux Byte Queue Limits (BQL) and active queue management (AQM) techniques (we just have RED queues in ns-3-dev but no models yet for the others). Note:  There is already some ns-3 code available (see below) but the authors have not updated it for a while; this or some recent ns-2 code could be a starting point.  Also, work could be done on using actual Linux code in the ns-3 Direct Code Execution (DCE) project.
* ''Interests:'' Internet performance, linux kernel networking 
* ''Difficulty:'' easy to hard, depending on the depth of the project
* ''Recommended reading:''
** http://gettys.wordpress.com/category/bufferbloat/
** [http://www.bufferbloat.net/projects/cerowrt CeroWrt]
** [http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-3.pdf ICCRG presentation]
** [http://pollere.net/CoDel.html ns-2 code]
** [https://codereview.appspot.com/6463048/ ns-3 code review]




[[Category:GSoC]]
[[Category:GSoC]]

Revision as of 20:17, 12 February 2014

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

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

GSoC 2014 Ideas

This webpage highlights project ideas for ns-3's Google Summer of Code 2014 effort.

GSOC 2014 Timeline is:

  • February 3 - 20:00 UTC: Mentoring organizations can begin submitting applications to Google.
  • February 14 - 20:00 UTC: Mentoring organization application deadline.
  • February 24 - 20:00 UTC: List of accepted mentoring organizations published on the Google Summer of Code 2014 site.
  • February 24 - March 21: Would-be student participants discuss application ideas with mentoring organizations.
  • March 10 - 19:00 UTC: Student application period opens.
  • March 21 - 19:00 UTC: Student application deadline.
  • April 21 - 19:00 UTC: Student selections announced
  • May 19 - Coding begins
  • August 18 - Coding ends

Full timeline is here: http://www.google-melange.com/gsoc/events/google/gsoc2014

While discussions about ideas can be done earlier, please note that ns-3 will not receive an answer to its GSOC application before February 24.

About the ns-3 project

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

Our GSoC organizational admin is TBD and our backup org admin is Tom Henderson. The project has participated in past GSoCs during 2008-10 and 2012-13.

Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Lalith Suresh of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge.

ns-3 and other GSoC mentoring organisations

ns-3 is one of ~175 mentoring organizations, and at other organizations have posted project ideas related to ns-3 in the past. For instance, the Wiselib project has listed ns-3 integration as one of its project ideas at http://www.Wiselib.org/gsoc.

Students interested in ns-3 and GSoC are also encouraged to explore whether other organizations might be a suitable mentoring organization for their project idea. Please keep in mind, though, that the ns-3 project is not involved in the selection process for these other mentoring organizations, and you will have to apply there instead.

Getting started

For students interested in applying to ns-3 for GSOC, go through the following list to get started:

Project Ideas

The following are a list of project proposals from the ns-3 team for Google Summer of Code 2014. Applicants are however free to propose their own ideas. In addition, please note that these ideas are not limited to GSoC, anyone is welcome to work on them. Please email the ns-developers list if you have an idea that you'd like to work on. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the ns-developers list. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the more stronger a proposal it will develop into, and the higher your chances of being accepted into the programme.

Each project idea within a particular priority has been tagged with the following properties:

  • Required Experience: Languages, concepts, or packages with which applicants must be familiar.
  • Bonus Experience: Other experience or familiarity which would be greatly helpful to applicants for this project.
  • Interests: Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
  • Difficulty: easy, medium or difficult
  • Recommended reading: pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.

Guidelines for project ideas

For mentors who're adding project ideas to the list below, please ensure that:

  • The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
  • The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
  • There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply or they directly apply to an ns-3 module that is in the process of merging with ns-3-dev.

Project Ideas

Please see last year's page for guidelines on how to create project ideas.

Note to students: These ideas are not listed in any priority order, and other project ideas not listed here are also encouraged.

Decouple traffic generators from sockets

Mentors: Tom Henderson Vedran Miletić

  • ns-3 uses applications that are part traffic generator, part socket-based application. The traffic generation part is not decoupled from the sockets API, making it hard to use applications over non-socket APIs such as future sensor networks. This project would work on a cleaner separation between traffic generator (OnOffApplication) and sockets.
  • Required Experience: C++, sockets API
  • Interests:
  • Difficulty: easy/medium
  • Recommended reading:
    • Unix Network Programming (Stevens) or equivalent

ARP and NDisc cache visibility

Mentors: Tom Henderson Vedran Miletić

  • There is no API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. Something similar to how PrintRoutes is done for IPv4 would be useful. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP).
  • Required Experience: C++
  • Interests: IPv4 and Ipv6
  • Difficulty: easy/medium
  • Recommended reading:
    • source code in src/internet, and the bugs mentioned above

INSTOOLS for ns-3

Mentors: Tom Henderson

INSTOOLS for ns-3: INSTOOLS is a software instrumentation package for GENI experiments. It logs a lot of artifacts of experiments, such as ARP and IP routing tables, Netflow graphs, etc, to databases. The aim of this project is to instrument ns-3 nodes to capture as much of this data as is applicable. A bonus is to try to integrate further with ProtoGENI and INSTOOLS such as making the ns-3 data archived just like it was a GENI experiment.

  • Required Experience: Familiarity with Linux networking and with C++ programming.
  • Bonus Experience: Experience with GENI and/or Emulab
  • Interests: Simulator tool development, integration with testbed experiments
  • Difficulty: Medium
  • Recommended Reading: http://groups.geni.net/geni/wiki/InstrumentationTools

bufferbloat-related models

Mentors: Tom Henderson

bufferbloat models: Bufferbloat is an interesting contemporary research topic. This project proposal is to develop models, examples, and visualizations around the bufferbloat problem. Some technical solutions include Linux Byte Queue Limits (BQL) and active queue management (AQM) techniques (we just have RED queues in ns-3-dev but no models yet for the others). Note: There is already some ns-3 code available (see below) but the authors have not updated it for a while; this or some recent ns-2 code could be a starting point. Also, work could be done on using actual Linux code in the ns-3 Direct Code Execution (DCE) project.