From Nsnam
Revision as of 09:36, 16 April 2022 by Tommaso (Talk | contribs) ("Perfect" ARP and NDP)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 2022 Google Summer of Code project ideas for ns-3.

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-21. We seek contributors 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 Mohit P. Tahiliani; contact them with any questions. They also hang out on Zulip.


Mentors will be paired with contributors 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 Mohit P. Tahiliani or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of code merge. In 2022, 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 2022 can be found among the ideas listed below.

Changes from last year

Google has changed the program again, allowing us to define medium-sized (175 hours) and large-sized (350 hours) projects. Therefore, we will be seeking to define projects with different scopes, accordingly. In general, we seek projects that aim to improve the existing simulator rather than add new features. Google also is opening participation to non-students (18-years or older).

How to apply

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

  • Read the official GSoC contributor guide.
  • Read ns-3's GSoC contributor guide
  • Look through our #Project Ideas below to see if you find a project that interests you.
  • Review the tutorial and contributing guide thoroughly, if you have not already done so.
  • Once it is posted, look through the GSoC application template to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.
  • 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. 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 2022. 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 contributors 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.

Patch requirement guidelines

Each project idea has (or will have) a list of proposed tasks that a contributor must do to ensure his/her ability to carry out the idea successfully. Performing one task is necessary for a successful application, and performing more than one task is not necessary.

If a contributor wants to work on a proposed task he/she should immediately contact the mentor(s) to "claim" that task - in order to avoid (where needed) that multiple contributors are on the same task. A task might involve fixing a specific open issue, or adding some functionalities to the existing code.

Contributors that did already contribute to the ns-3 codebase with non-trivial bug fixing or features additions might be exempted from performing a task. If you have doubts about if your contributions made you eligible for the task exemption contact the mentors.

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 contributors: These ideas are not listed in any priority order. If an idea doesn't have a mentor yet, it means that if you are interested, you should announce your interest and see if there is a mentor who might pick it up.

Medium sized projects (175 hours)

Linux-like Loss Detection Techniques for ns-3 TCP

Mentors: Mohit P. Tahiliani, Vivek Jain, Viyom Mittal

Forward Acknowledgement (FACK), Duplicate Selective Acknowledgement (DSACK), Tail Loss Probe (TLP) and Recent Acknowledgement (RACK) are the loss detection techniques implemented in the Linux kernel. These techniques have been already implemented for ns-3 TCP but their code is not yet merged into the mainline. This project has four main goals: (1) update the implementation of these techniques according to the latest ns-3-dev, (2) develop a framework to test the functionality of these techniques, (3) develop example program(s) to demonstrate the usage of these techniques in ns-3 and (4) merge these techniques in the mainline of ns-3.

Upgrade the AQM Evaluation Suite for ns-3

Mentors: Bhaskar Kataria, Mohit P. Tahiliani, Vivek Jain.

AQM (Active Queue Management) evaluation suite for ns-3 helps to quickly study the performance of AQM algorithms based on the guidelines mentioned in RFC 7928. This suite automates simulation setup, topology creation, traffic generation, program execution, results collection and their graphical representation using ns-3 based on the scenarios mentioned in RFC 7928. It was designed and developed in 2017 and actively maintained till 2019. In the past two years, the traffic control model in ns-3 has grown significantly in terms of supporting state-of-the-art packet scheduling and AQM algorithms. This project has four main goals: (1) upgrade the AQM Evaluation Suite according to the latest ns-3-dev, (2) enable support for latest packet scheduling, AQM algorithms and ECN functionality (3) update the examples in AQM Evaluation Suite to better suit the needs of researchers working in this area, and (4) make AQM Evaluation Suite available on the ns-3 app store.

  • Required Experience: Familiarity with AQM and C++ programming.
  • Bonus Experience: Familiarity with traffic control model in ns-3.
  • Interests: Packet Scheduling algorithms, AQM algorithms and ECN.
  • Difficulty: Medium.
  • Recommended Reading:
  • Patch requirement: Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:
    • ./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"
    • ./waf --run "aqm-eval-suite-runner --number=<unsupported number>"
TCP maximum segment size (MSS) improvements

Mentors: Tommaso Pecorella, others TBD

TCP performances are affected by the maximum segment size (MSS) - a wrong choice might either lead to inefficient transmission (higher overhead) or IP fragmentation.

At the moment ns-3 implementation allows to set the MSS via an Attribute (set by default to 536 bytes by TcpSocket Attribute "SegmentSize"). Although it is stated that it "may be adjusted based on MTU discovery", its value is not changed in a simulation.

The goal of the project is to update the MSS handling, allowing to: 1) Set it to a fixed size, or allowing auto-probing of "optimal" MSS, 2) Use and honor the TcpOptionMSS (RFC 793), with a proper example of use, and 3) React to intermediate links with short MTU, and/or to changes in the Path MTU (PMTU).

The last point is to be carefully handled, as in many points in the code there is an implicit assumption that the MSS is constant in a given flow.

Moreover, note that finding the optimal PMTU is not that simple, as IPv6 and IPv4 react differently to packets exceeding the link MTU, and they won't notify if a packet is shorter than the link MTU. As a consequence, it would be useful to implement the Packetization Layer Path MTU Discovery (RFC 4821) - which might exceed the GSoC timeframe.

Hence, it would be advisable to carefully select the features to be supported and tested in the project, eventually paving the ground for future enhancements.

Add support for LEDBAT++ in ns-3

Mentors: Mohit P. Tahiliani, Vivek Jain, Viyom Mittal

LEDBAT++ is a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. This project has five main goals: (1) implement LEDBAT++ in ns-3, (2) test the working of LEDBAT++ (3) develop example program(s) to demonstrate the usage of LEDBAT++ in ns-3 (4) document the working of LEDBAT++ in ns-3 and (5) merge LEDBAT++ in the mainline of ns-3.

Flent Enhancements in ns-3

Mentors: Ameya Deshpande, others TBD

Flent is a network benchmarking tool built on top of netperf and similar tools to run predefined tests and aggregate and plot the results. ns-3 has basic support for Flent which is built on top of other ns-3 applications. It supports ping, tcp_1up, tcp_1down, and rrul tests as of now.

The goals of the project are:

1) Add IPv6 support.

ns-3 Flent supports only IPv4 as of now. Adding IPv6 support will enable users to use Flent in IPv6 network simulations and help add IPv6-related tests like rrul46. Flent has options -4 and -6 to explicitly specify IPv4 and IPv6 respectively. ns-3 Flent should also support an attribute to mention IPv4 or IPv6. Ideally, we would want to incorporate this feature with minimal code duplication.

2) Investigate the differences between Flent and ns-3 Flent.

Compare similar scenarios in Flent and ns-3 Flent, find out the reason for the differences, and either correct those differences or document the reason for them. We observed different results in the cases of TCP Linux Reno with 10 ms and 80 ms RTTs and 50Mbps bottleneck bandwidth. Check out the file to understand the topology and the setup.

3) Add support for more tests.

  • Add support for tcp_nup, tcp_ndown and rrul_be_nflows. Flent has test parameters like upload_streams and download_streams to mention the number of streams. ns-3 Flent should also have similar attributes to denote the number of streams.
  • Add support for UDP flood test.
  • Add support for tcp_bidirectional.

Note: There are several tests present in Flent which can be adopted as part of this project. The tests with more use case can be prioritized.

Ping and Ping6 Enhancements in ns-3

Mentors: Tommaso Pecorella, others TBD

The two applications "V4Ping" and "Ping6" do their respective jobs, but they have two main issues:

  1. They have different parameters
  2. There is a lot of code duplication
  3. They have an output that is not consistent with the one you get in Linux

The goals of the project are to fix the above mentioned problems, deprecating the old implementations.

Note that some differences between the Linux and ns-3 parameters are acceptable, but they must be documented and justified.

  • Required Experience: Familiarity with ns-3 Internet Applications, IPv6 fundamentals, C++ programming.
  • Bonus Experience: Familiarity with Ping and Ping6.
  • Interests: Network Benchmarking
  • Difficulty: Medium
  • Recommended reading:
  • Required functionalities and tests:
    • Ping and Ping6 output should be virtually identical to the ones obtained in Linux - use Ubuntu as a reference.
  • Patch requirement:
"Perfect" ARP and NDP

Mentors: Tommaso Pecorella, others TBD

ARP and NDP are fundamental protocols, but sometimes they add noise to the simulation (unwanted delays, packet drops, etc.). Sometimes it is handy to disable ARP and NDP, mainly when debugging particular events, or during tests. Unfortunately, disabling Arp and NDP is not possible. Hence, the idea is to have a "know-all" object that can instantly provide the right answer to the nodes, making the ARP/NDP deterministic. This object have to also cope gracefully with duplicate addresses (e.g., IPv6 link-local addresses), which makes the task non-trivial.

Summarizing, the object must:

  1. Reply instantly to an ARP or NDP request
  2. Discriminate between link-local and global addresses (i.e., behave exactly like ARP and NDP for what concerns node reachability).
  3. Provide warnings in case of duplicate addresses.

Summarizing, it must behave exactly like ARP and NDP, but with zero delay.

  • Required Experience: Familiarity with ARP, NDP, and C++ programming.
  • Interests: IPv4 and IPv6.
  • Difficulty: Medium.
  • Recommended reading:
  • Required functionalities and tests:
    • Seamless replacement for ARP and NDISC though a helper - check "Ipv4L3Protocol::Insert (Ptr<IpL4Protocol> protocol, uint32_t interfaceIndex);"
    • Check that ARP and NDP replies are immediate.
    • Check that NDP-like replies are behaving as expected. E.g., DAD uses NDP-like messages. These might be immediate or not - this must be a design decision and must be tested.
    • Check that ARP and NDP performs like expected after an interface disconnection and reattach (Interface up/down).
  • Patch requirement:
    • Provide a simple script that substitutes "standard" ICMP (either for IPv4 or IPv6) in a node with one returning a fixed, pre-defined value for the lookup functions (virtual NdiscCache::Entry* NdiscCache::Lookup (Ipv6Address dst); and ArpCache::Entry* ArpCache::Lookup (Ipv4Address destination);).

Large projects (350 hours)

Enable IPv6 support for Ad hoc Routing Protocols in ns-3

Mentors: Ameya Deshpande, Tommaso Pecorella.

ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.

Possible tasks to fulfill the patch requirement:

  • Issue #271 - olsr header and messages are not printing either their size or their content.
  • Issue #368 - aodv: aodv parameters can be set to "impossible" values
IPv6 global routing

Mentors: Ameya Deshpande, Tommaso Pecorella.

Creating a complex topology can be a problem, and sometimes the user do not want to be (also) concerned about setting up dynamic routing protocols (e.g., RIP, RIPng). For IPv4, ns-3 provides two alternatives: GlobalRouting, and NixRouting, which just "do the trick" - they simply fill the routing tables in intermediate nodes, GlobalRouting using an approach similar to OSPF, NixRouting by leveraging the "abstract" knowledge of the network. Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.

The problem is that they don't work for IPv6, and that's a huge limitation. The goal of the project is to fix that limitation. Note that the project must cope with different IPv6 address kinds (link-local, global, scoped multicast, etc.). Due to the limitation with GlobalRouting w.r.t. wireless channels, it would be advisable to start working with NixRouting.

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.

Possible tasks to fulfill the patch requirement:

  • Add a function to print the path that a packet will use (according to Ipv4NixVectorRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4NixVectorRouting will use.
  • Add a function to print the path that a packet will use (according to Ipv4GlobalRouting), i.e., given source and destination IP print the IP addresses of the nodes that Ipv4GlobalRouting will use.
A TR 38.811-based NTN channel model for ns-3

Mentors: Biljana Bojovic, Michele Polese, Sandra Lagén

Non-Terrestrial-Networks (NTNs) are a promising research topic for future cellular networks. Indeed, such technology promises to provide coverage to rural areas, on top of offering a versatile way to strategically densify the network. The 3GPP has picked up on the research interest regarding NTNs by developing an ad hoc extension for their statistical channel model. This project has the main goal of extending the TR. 38.901 implementation available in ns-3 with its NTN extension outlined in TR 38.811. Additionally, the candidate should undertake a calibration campaign, to test their implementation, and merge the work in the mainline ns-3.

  • Required Experience: Familiarity with statistical channel models and C++ programming.
  • Bonus Experience: Familiarity with the 3GPP TR. 38.901 channel model.
  • Interests: Statistical channel models, NTNs.
  • Difficulty: Medium to Hard.
  • Recommended reading:
    • 3GPP TR. 38.901 [Baseline channel model]
    • 3GPP TR. 38.811 [NTN channel extension]
    • Zugno, T., Polese, M., Patriciello, N., Bojović, B., Lagen, S. and Zorzi, M., 2020, June. “Implementation of a Spatial Channel Model for ns-3”, In Proceedings of the 2020 Workshop on ns-3 [Baseline TR 38.901 ns-3 implementation]
A simplified channel and beamforming model for ns-3

Mentors: Biljana Bojovic, Michele Polese, Sandra Lagén

3GPP has defined in TR 38.901 a spatial channel model for simulations of 5G. TR 38.901 implementation is available in ns-3, and it is linked with the beamforming vector design at transmit/receive nodes. However, the model is complex (involving many clusters and rays simulation for a single transmit-receive node link) and involves a high computational complexity, specially for large-scale simulations. The objective of this project would be to decouple the beamforming and the channel modeling for multi-antenna systems and derive simple models adequate for large-scale simulations. Beamforming can be abstracted through a single beamforming gain into the desired direction, and fading would be encapsulated as part of the channel with simplified models. Additionally, the candidate should undertake a complexity comparison study and assess the performance difference with respect to the TR 38.901 model in different frequencies, and merge the work in the mainline ns-3.

  • Required Experience: Familiarity with channel models, beamforming, and C++ programming.
  • Bonus Experience: Familiarity with the 3GPP TR 38.901 channel model.
  • Interests: channel models, beamforming.
  • Difficulty: Medium.
  • Recommended reading:
    • 3GPP TR 38.901 [Baseline channel model]
    • Zugno, T., Polese, M., Patriciello, N., Bojović, B., Lagen, S. and Zorzi, M., 2020, June. “Implementation of a Spatial Channel Model for ns-3”, In Proceedings of the 2020 Workshop on ns-3 [Baseline TR 38.901 ns-3 implementation]
Linux-like CAKE queue discipline for ns-3

Mentors: Mohit P. Tahiliani, Ameya Deshpande

Common Applications Kept Enhanced (CAKE) is the most recent queue discipline added in Linux 4.19. It is a comprehensive queue management framework targeted for home Internet gateways, and integrates the following four components: bandwidth shaping, a new Active Queue Management (AQM) algorithm called COBALT (CoDel BLUE Alternate), handling Differentiated Services (DiffServ) and TCP ACK filtering. The main tasks in this project include: implementation, testing and documentation of individual components of CAKE in ns-3, followed by the integration of these components to form CAKE queue discipline in ns-3.