Difference between revisions of "GSOC2016Projects"

From Nsnam
Jump to: navigation, search
(Project Ideas)
(Test and extend our qdiscs!)
 
(8 intermediate revisions by 3 users not shown)
Line 68: Line 68:
  
 
'''Note to students:''' These ideas are not listed in any priority order.
 
'''Note to students:''' These ideas are not listed in any priority order.
 +
 +
==== Windows Visual Studio Community support ====
 +
 +
Mentors: [mailto:tomh@tomh.org Tom Henderson]
 +
 +
ns-3 is primarily developed on Linux and OS X, and has had some unofficial Visual Studio support in the past:  https://www.nsnam.org/wiki/Ns-3_on_Visual_Studio_2012.  In this suggested project, the student will help ns-3 produce a maintainable Visual Studio version for the latest free version of Visual Studio (Visual Studio Community 2015).  This will require not only working with the core maintainers on solving compiler compatibility issues, but also providing clear documentation for Windows users, support for [[NetAnim]] animator, support for standing up a Windows buildslave in our regression testbed, and any other things that the student feels will enhance the Windows ns-3 experience (time permitting).  If you select this project idea, please tell us about your experience/ability to work with Visual Studio, and how you plan to take what has already been done for Visual Studio 2012 and improve it.
  
 
==== Freshen ns-3/Click integration ====
 
==== Freshen ns-3/Click integration ====
Line 73: Line 79:
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
  
ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010.  We seek a student interested in the following tasks:  1) since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes.  Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol so that the click-specific pieces are limited and can be maintained more easily. 2) There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac.  We'd like to finish this off and merge it with ns-3-dev. 3) anything else that a student thinks would be useful to support regarding click and ns-3 integration.
+
ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010.  We seek a student interested in the following tasks:   
 +
 
 +
# Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes.  Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol so that the click-specific pieces are limited and can be maintained more easily.  
 +
# There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac.  We'd like to finish this off and merge it with ns-3-dev.
 +
# At the moment click integration is available only for IPv4. Adding IPv6 support will require some refactoring similar to point 1, but it's an equally interesting point.
 +
# Anything else that a student thinks would be useful to support regarding click and ns-3 integration.
 +
 
 +
The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.
 +
 
 +
* ''Required Experience:'' C++
 +
* ''Bonus Experience:'' IPv4, IPv6, Click.
 +
* ''Interests:'' Software integration.
 +
* ''Difficulty:'' Medium.
  
 
==== OpenStack and ns-3 ====
 
==== OpenStack and ns-3 ====
Line 83: Line 101:
 
==== ICCRG TCP Evaluation Suite port ====
 
==== ICCRG TCP Evaluation Suite port ====
  
Mentors: [mailto:tomh@tomh.org Tom Henderson]
+
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit Tahiliani]
  
 
The Internet Congestion Control (ICC) research group has worked on an ns-2-based TCP evaluation suite for several years.  Details about this suite are described in this internet draft:
 
The Internet Congestion Control (ICC) research group has worked on an ns-2-based TCP evaluation suite for several years.  Details about this suite are described in this internet draft:
Line 126: Line 144:
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
  
'''802.15.4 Bootstrap:''' The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.
+
The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.
 
* ''Required Experience:'' C++, WSN
 
* ''Required Experience:'' C++, WSN
 
* ''Bonus Experience:'' 802.15.4 standard
 
* ''Bonus Experience:'' 802.15.4 standard
Line 133: Line 151:
 
* ''Recommended reading:''
 
* ''Recommended reading:''
 
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 
  
 
==== 802.15.4 Beacon-enabled mode ====
 
==== 802.15.4 Beacon-enabled mode ====
Line 139: Line 156:
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
  
'''802.15.4 Beacon-enabled mode:''' The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module.  
+
The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module.  
 
* ''Required Experience:'' C++, WSN
 
* ''Required Experience:'' C++, WSN
 
* ''Bonus Experience:'' 802.15.4 standard
 
* ''Bonus Experience:'' 802.15.4 standard
Line 146: Line 163:
 
* ''Recommended reading:''
 
* ''Recommended reading:''
 
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 +
 +
==== DSR routing RFC compliance ====
 +
 +
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 +
 +
The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.
 +
The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.
 +
A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.
 +
* ''Required Experience:'' C++
 +
* ''Bonus Experience:'' DSR standard
 +
* ''Interests:'' Ad-hoc routing
 +
* ''Difficulty:'' medium
 +
* ''Recommended reading:''
 +
** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]
 +
 +
==== AODV version 2 (AODVv2) routing ====
 +
 +
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]
 +
 +
The Mobile Ad hoc Networks Working Group has worked on designing Ad hoc On-demand Distance Vector version 2 (AODVv2) for past three years. Details about AODVv2 are described in this internet draft:
 +
* https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/
 +
 +
AODVv2 is an important extension of AODV. Some of the mandatory features in AODV are made optional in AODVv2. Moreover, a mechanism to use multiple metric types is also incorporated in AODVv2. The goal of this project is to develop a AODVv2 model for ns-3. The pre-existing AODV model of ns-3 can be used as a reference to start this project. The project can be further extended to include support for IPv6.
 +
 +
* ''Required Experience:'' C++
 +
* ''Bonus Experience:'' AODV standard
 +
* ''Interests:'' Ad-hoc routing
 +
* ''Difficulty:'' medium
 +
* ''Recommended reading:''
 +
** [https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13 AODVv2 internet draft]
 +
** [https://www.nsnam.org/doxygen/group__aodv.html AODV model in ns-3]
 +
** [https://www.nsnam.org/docs/manual/html/new-modules.html Adding a new module to ns-3]
 +
 +
==== Test and extend our qdiscs! ====
 +
 +
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]
 +
 +
ns-3 is on the verge of adding a 'traffic control' layer modelled after Linux tc (see the code review issue [https://codereview.appspot.com/284530043/ here].  We have models of pfifo_fast, RED, adaptive RED, CoDel, and PIE either ready or nearly ready, but we could use more testing of them.  We also need support for ECN added throughout, and could use some additional models such as [http://www.bufferbloat.net/projects/codel/wiki/Cake cake] and [https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-04 fq_codel].  So there is a potentially a lot of interesting work to build on this new capability-- tell us how you might define a summer project to improve our support for modelling AQM and bufferbloat.
 +
 +
* ''Difficulty:'' medium
 +
* ''Recommended reading:''
 +
** IETF internet-drafts about AQM mechanisms like CoDel, PIE, and FQ-CoDel
 +
** reading found on http://bufferbloat.net
 +
** ns-3 code, including the traffic control layer above, our existing models for CoDel and RED, and what was done on a [https://www.nsnam.org/wiki/GSOC2014Bufferbloat GSOC 2014 project]
  
  
 
[[Category:GSoC]]
 
[[Category:GSoC]]

Latest revision as of 07:22, 19 February 2016

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

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

ns-3's GSoC 2016

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

The thirteen week coding period for projects runs from 25 May to 21 August, 2015. The full project timeline is here: https://developers.google.com/open-source/gsoc/timeline?hl=en

ns-3 must apply for GSoC and will learn whether it has been accepted on 29 February 2016.

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 Tom Henderson and our backup org admin is Tommaso Pecorella. The project has participated in past GSoCs during 2008-10 and 2012-15.

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 Tom Henderson or Tommaso Pecorella 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

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.

Students: how to participate

For students interested in applying to ns-3 for GSOC, first wait to see if ns-3 will be selected. If so, then go through the following list to get started:

Below is a list of #Project Ideas proposed by the ns-3 team for Google Summer of Code 2016. 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 a different idea that you'd like to work on, to see if a mentor may be interested. 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 stronger the 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.

Mentors: how to participate

The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. 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 to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

Project Ideas

Note to students: These ideas are not listed in any priority order.

Windows Visual Studio Community support

Mentors: Tom Henderson

ns-3 is primarily developed on Linux and OS X, and has had some unofficial Visual Studio support in the past: https://www.nsnam.org/wiki/Ns-3_on_Visual_Studio_2012. In this suggested project, the student will help ns-3 produce a maintainable Visual Studio version for the latest free version of Visual Studio (Visual Studio Community 2015). This will require not only working with the core maintainers on solving compiler compatibility issues, but also providing clear documentation for Windows users, support for NetAnim animator, support for standing up a Windows buildslave in our regression testbed, and any other things that the student feels will enhance the Windows ns-3 experience (time permitting). If you select this project idea, please tell us about your experience/ability to work with Visual Studio, and how you plan to take what has already been done for Visual Studio 2012 and improve it.

Freshen ns-3/Click integration

Mentors: Tom Henderson

ns-3 and Click modular routing were first integrated in an ns-3 GSoC project from 2010. We seek a student interested in the following tasks:

  1. Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol so that the click-specific pieces are limited and can be maintained more easily.
  2. There was an ns-3 2011 summer project (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to finish this off and merge it with ns-3-dev.
  3. At the moment click integration is available only for IPv4. Adding IPv6 support will require some refactoring similar to point 1, but it's an equally interesting point.
  4. Anything else that a student thinks would be useful to support regarding click and ns-3 integration.

The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.

  • Required Experience: C++
  • Bonus Experience: IPv4, IPv6, Click.
  • Interests: Software integration.
  • Difficulty: Medium.

OpenStack and ns-3

Mentors: Tom Henderson

OpenStack Neutron is the networking layer of OpenStack. ns-3 does not have any integration yet with OpenStack. We invite project proposals that propose some level of integration of ns-3 with OpenStack. In your application, tell us why you think OpenStack should be integrated with ns-3 (what will be the useful use cases supported?) and what you think you can accomplish in a 10-week summer project.

ICCRG TCP Evaluation Suite port

Mentors: Tom Henderson, Mohit Tahiliani

The Internet Congestion Control (ICC) research group has worked on an ns-2-based TCP evaluation suite for several years. Details about this suite are described in this internet draft:

and code is provided here:

We would like to find a student interested in porting this evaluation framework from ns-2 to ns-3. Are you interested in this project? In your application, please tell us how you plan to organize your project. It may be too big of a job to complete the entire port; how would you design a project to make sure that at least a portion of the framework is ported by the end of the summer? Another part of the application that will be evaluated is how well the applicant has reviewed the ns-2 code and compared it to ns-3. Where are the differences between ns-2 and ns-3 that make such a port difficult? What pieces might be relatively easy to port? How would you check whether the results from the ns-3 port compare well with the ns-2 code?

  • Required Experience: C++
  • Bonus Experience: Transport protocols or TCP, ns-2
  • Interests: TCP and transport protocol performance
  • Difficulty: depends on what functionality the student proposes to implement

ns-3 bug squashing and testing

Mentors: Tommaso Pecorella

The ns-3 project is affected by a number of bugs, like any software suite. All the known bugs are classified and tracked in Bugzilla, divided by severity and module.

Over the time some of these bugs have been left without fixes, some have fixes but they are untested, etc. Moreover, in order to kill a bug for good (and not open another bug while fixing the old one), it is necessary to have tests. Tests also prevent the bug from returning at a later time.

The goal of the project is to:

  1. Scan Bugzilla and check what bugs are to prioritize (i.e., fix the priorities).
  2. Fix the bugs (eventually involving the module maintainers).
  3. Provide unit testing for the fixed bugs.
  4. Improve the modules documentation.

The candidate is free to propose the methodology he/she wants to pursue (i.e., fix bugs by module, by importance, etc.).

  • Required Experience: C++
  • Bonus Experience: Bugzilla, bug fixing, unit testing systems.
  • Interests: software maintenance.
  • Difficulty: depends on what bugs and unit testing the student proposes to fix/implement

802.15.4 Bootstrap

Mentors: Tommaso Pecorella

The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.

  • Required Experience: C++, WSN
  • Bonus Experience: 802.15.4 standard
  • Interests: WSN
  • Difficulty: medium
  • Recommended reading:

802.15.4 Beacon-enabled mode

Mentors: Tommaso Pecorella

The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module.

  • Required Experience: C++, WSN
  • Bonus Experience: 802.15.4 standard
  • Interests: WSN
  • Difficulty: medium/hard
  • Recommended reading:

DSR routing RFC compliance

Mentors: Tommaso Pecorella

The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark. The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed. A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.

  • Required Experience: C++
  • Bonus Experience: DSR standard
  • Interests: Ad-hoc routing
  • Difficulty: medium
  • Recommended reading:

AODV version 2 (AODVv2) routing

Mentors: Mohit P. Tahiliani

The Mobile Ad hoc Networks Working Group has worked on designing Ad hoc On-demand Distance Vector version 2 (AODVv2) for past three years. Details about AODVv2 are described in this internet draft:

AODVv2 is an important extension of AODV. Some of the mandatory features in AODV are made optional in AODVv2. Moreover, a mechanism to use multiple metric types is also incorporated in AODVv2. The goal of this project is to develop a AODVv2 model for ns-3. The pre-existing AODV model of ns-3 can be used as a reference to start this project. The project can be further extended to include support for IPv6.

Test and extend our qdiscs!

Mentors: Tom Henderson, Mohit P. Tahiliani

ns-3 is on the verge of adding a 'traffic control' layer modelled after Linux tc (see the code review issue here. We have models of pfifo_fast, RED, adaptive RED, CoDel, and PIE either ready or nearly ready, but we could use more testing of them. We also need support for ECN added throughout, and could use some additional models such as cake and fq_codel. So there is a potentially a lot of interesting work to build on this new capability-- tell us how you might define a summer project to improve our support for modelling AQM and bufferbloat.

  • Difficulty: medium
  • Recommended reading:
    • IETF internet-drafts about AQM mechanisms like CoDel, PIE, and FQ-CoDel
    • reading found on http://bufferbloat.net
    • ns-3 code, including the traffic control layer above, our existing models for CoDel and RED, and what was done on a GSOC 2014 project