GSOC2020Projects

From Nsnam
Revision as of 18:02, 5 February 2020 by Mohit (Talk | contribs) (Project Ideas)

Jump to: navigation, search

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

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

This page contains 2020 Google Summer of Code project ideas for ns-3.

Note: ns-3 will apply to Google Summer of Code on February 5 and will be notified about acceptance on February 20.


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.

ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-19. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.

Org admins

Google Summer of Code organizational admins for ns-3 are Tommaso Pecorella and Tom Henderson; contact them with any questions. They also hang out on Zulip.

Mentors

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. In 2020, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2020 is below:

  • Tom Henderson
  • Tommaso Pecorella
  • Mohit Tahiliani
  • Sebastien Deronne
  • Hany Assasa
  • Ankit Deepak
  • Dizhi Zhou
  • Davide Magrin

Students: how to participate

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

  • Read the official GSoC student guide.
  • Read ns-3's GSoC Student guide (will be updated for 2020 if we are selected)
  • Look through our #Project Ideas below to see if you find a project that interests you.
  • Review the ns-3 tutorial thoroughly, if you have not already done so.
  • Once it is posted, look through the GSoC Student application template to start preparing your proposal.
  • Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.
  • In parallel, make sure you prepare a patch as per the patch requirement guidelines (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.

Below is a list of #Project Ideas proposed by the ns-3 team for Google Summer of Code 2020. 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. A few projects are more Python-centric.

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.

Direct Code Execution upgrade

Mentor: Tom Henderson, others TBD

ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the open DCE issues in our tracker, for starters.

DCE quagga improvements

Many years ago, the quagga routing suite was integrated to DCE. This allows implementations of RIP, BGP, and OSPF to be used in ns-3. However, documentation and helpers to ease the use of these protocols with the rest of ns-3 are limited, and it is difficult to trace the operation of the protocols. This project would focus on freshening and upgrading the quagga support for ns-3 DCE, so that it is much easier to use BGP and OSPF in ns-3 simulations.

Mentor: Tom Henderson

Migrate contributed code to apps

Mentors: Tom Henderson

A large amount of ns-3 code exists out of the mainline and falls out of date. This project would aim to update, finish off, and publish as many apps as possible to the ns-3 App Store. The student will also be responsible for writing test scripts to test daily that compatibility of apps with the ns-3 mainline is not broken. A list of potential modules will be provided below:

Usability improvements

Mentors: Tom Henderson, others TBD

Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some possible project examples:

  • Tools and scripts to conduct and manage data from a large number of simulation runs
  • How to integrate a more Python-centric data flow and tools, such as Jupyter Notebook and bqplot
  • Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by Yavista

User-friendly internet-apps

Mentors: Tom Henderson

Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, "Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file <filename.txt>", or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.).

  • Required Experience:C++
  • Interests: Network performance management
  • Difficulty: Medium
  • Recommended reading:

nam upgrade and support for ns-3

Mentors: Tom Henderson

nam is a Tcl/Tk-based animator for ns-2. Some example videos are found at YouTube. nam has been functionally replaced in many ways by NetAnim, but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos.

  • Required Experience:C++, Tcl/Tk also preferred
  • Interests: Network visualization/animation
  • Difficulty: Medium
  • Recommended reading:
    • the links listed above

NetAnim Python and examples

Mentors: Tom Henderson

NetAnim is an optional animator for ns-3. It has not been actively developed for a few years. It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation. NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use. Python bindings for the animator are also not supported. We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim.

BPF support

Mentors: Tom Henderson

BPF is a current networking implementation trend. What would it take to support BPF programs in ns-3? What are the use cases of interest?

  • Required Experience:C++, C
  • Recommended Experience: BPF, Linux kernel
  • Interests: protocol implementation
  • Difficulty: Medium to hard?
  • Recommended reading:

Wi-Fi code refactoring to facilitate integration of other 802.11 based standards

Mentors: Sébastien Deronne Hany Assasa

Besides the commercial 802.11 standards (11b, 11a, 11g, 11n, 11ac & 11ax) that have been implemented in mainstream ns-3 versions, some other modules have been developed to implement "non-commercial" 802.11 amendments, such as 802.11ah and 802.11ad/ay (Wigig), which exist in separate repositories. Since these make use of some common code from the wifi module, developers of these other modules implement their own models on top of the existing wifi model, which result in a very large amount of code in the same module. furthermore, this makes this code very difficult to maintain due to a lot of merge conflicts each time changes have been done in the mainline wifi. A much better approach would be to refactor the wifi module, so that common functionalities can be used from separate modules (802.11h, Wigig, ...) that would later be available in the ns-3 App Store and could be easily plugged in. The goal of this project is to identify a good approach to refactor the wifi module and start its implementation.

  • Required Experience:C++
  • Recommended Experience: 802.11 (Wi-Fi)
  • Interests: Code refactoring
  • Difficulty: Medium to hard
  • Recommended reading:

Wigig: https://github.com/wigig-tools/ns3-802.11ad

802.11ah: https://github.com/imec-idlab/IEEE-802.11ah-ns-3

SCE codepoint for ns-3 TCP and Queue Disciplines

Mentor: Mohit P. Tahiliani, Tom Henderson

Some Congestion Experienced (SCE) is a recently proposed codepoint for Explicit Congestion Notification (ECN). The purpose of SCE codepoint is to deliver an early notification of congestion that is building up in the network devices, prior to delivering Congestion Experienced (CE) codepoint. This project idea is about implementing, testing and documenting SCE codepoint support in ns-3. It requires modifications to TCP model and queue disciplines in ns-3. ECN is already supported in ns-3, so implementing SCE does not require major architectural changes to ns-3 codebase.

  • Required Experience: Familiarity with queue disciplines, TCP and C++ programming.
  • Bonus Experience: Familiarity with SCE codepoint.
  • Interests: Active Queue Management, Explicit Congestion Notification and TCP.
  • Difficulty: Medium to Hard.
  • Recommended Reading:

Internet draft on Some Congestion Experienced Linux implementation of SCE ECN implementation in ns-3

Cheap Nasty Queuing (CNQ) and Lightweight Fair Queueing (LFQ) models for ns-3

Mentor: Mohit P. Tahiliani, Tom Henderson

Cheap Nasty Queuing (CNQ) and Lightweight Fair Queueing (LFQ) are recently proposed Internet drafts in IETF. CNQ provides a single-instance Active Queue Management (AQM) and basic sparse-flow prioritisation whereas LFQ is expected to provide throughput fairness, sparse flow prioritization and ordering guarantees while maintaining a small code footprint, low memory requirements, no multiply operations, only two physical queues, and only one set of AQM state. This project idea is about implementing, testing and documenting CNQ and LFQ in ns-3. These algorithms can be combined with Controlled Delay (CoDel) or CoDel BLUE Alternate (COBALT) to verify the correctness of the implementation.

  • Required Experience: Familiarity with queue disciplines and C++ programming.
  • Bonus Experience: Familiarity with CNQ and LFQ.
  • Interests: Packet Scheduling algorithms
  • Difficulty: Medium to Hard.
  • Recommended Reading:

Internet draft on CNQ Internet draft on LFQ Linux implementation of CNQ Linux implementation of LFQ Queue Disciplines in ns-3

Google’s BBRv2 congestion control algorithm for ns-3 TCP

Mentor: Mohit P. Tahiliani, Tom Henderson

BBRv2 is an enhanced version of BBR (Bottleneck Bandwidth and RTT), both developed at Google. BBRv2 overcomes the limitations of BBR, such as: no response to packet loss, no response to ECN (Explicit Congestion Notification) and unfairness while coexisting with traditional TCP variants (e.g., CUBIC). A BBR model has been developed for ns-3 but is currently out of the mainline. This project is about merging the available implementation of BBR and subsequently implementing, testing and documenting BBRv2 in ns-3.

  • Required Experience: Familiarity with BBR and BBRv2
  • Bonus Experience: Familiarity with CNQ and LFQ.
  • Interests: TCP Congestion Control
  • Difficulty: Medium to Hard.
  • Recommended Reading:

Internet draft on BBR IETF Presentation about BBRv2 Linux implementation of BBR Linux implementation of BBRv2 TCP models in ns-3 BBR implementation in ns-3