GSOC2023Projects

From Nsnam
Revision as of 14:32, 4 April 2023 by Tommaso (Talk | contribs) (ICMP socket and generate/handle ICMP messages (host/net unreachable))

(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 2023 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-22. 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, Mohit P. Tahiliani, and Tom Henderson; contact them with any questions. They also hang out on Zulip.

Mentors

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 2023 can be found among the ideas listed below.

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 2023. 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 programs 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 program.

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 either a suggested task, or a link to a generic task, that a contributor must do to demonstrate some ability to carry out a GSoC project successfully. Performing one task is necessary for a successful application, and performing more than one task is not necessary.

Contributors that already contributed 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)

ICMP socket and generate/handle ICMP messages (host/net unreachable)

Mentors: Tommaso Pecorella, Manoj K. Rana.

The current IP stack in ns-3 does not provide an ICMP socket, and in order to send or receive ICMP packets (either IPV4 or IPv6) it is necessary to use a "RAW" socket. This approach works, but has a severe limitation: it does not work if the packet has been fragmented. Moreover, using a RAW socket is far more complex than a normal socket, as the receiver application must filter the incoming packets according to specific rules.

The goal of the idea is to create, test, and document an ICMP socket that works both for IPv4 and IPv6, mimicking the Linux sockets socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) and socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6). Note that the choice of SOCK_DGRAM or SOCK_RAW (i.e., with or without the IP header) is totally left to the proposal.

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

Once the sockets are in place, beside the "normal" tests, it will be necessary to modify the code that is actually made obsolete by the new sockets, e.g.:

  • IPv6 ICMP messages (RA, RS, NA, NS, etc.),
  • IPv4 ICMP messages,
  • ICMP Echo and ICMPv6 Echo messages.

and to handle properly ICMP error messages like Destination Unreachable in the Ping application.

Possible tasks to fulfill the patch requirement:

Dynamic device registration for NetAnim simulation animations

Mentors: Tommaso Pecorella, Manoj K. Rana.

NetAnim is a graphical interface based on QT able to visualise nodes movement and messages between nodes either while the simulation is running or when the simulation is ended. It is particularly useful to visualise network dynamics, and to demonstrate scenarios.

However, it has one severe limitation: it requires events from the nodes and the NetDevices, and to do so it hooks on several callbacks. The problem is that this approach requires that all the NetDevices are compiled along with NetAnim, or the compilation fails. Moreover, if a new NetDevice is added, it is necessary to change the NetAnim code as well.

An example of the first limitation is: suppose you want to not compile the WiMAX module, but you want to use NetAnim. You can't. An example of the second limitation is: suppose you want to make a model for the AppStore - it will not be able to use NetAnim.

The goal of the idea is to refactor NetAnim so that it uses an approach similar to the Energy module - each module willing to use NetAnim will have a (small) class responsible for the communication between the two modules, enabled only if NetAnim is compiled. This will break the dependencies, and will allow more flexibility for AppStore modules.

  • Required Experience: C++ programming.
  • Interests: Code refactoring.
  • Difficulty: Medium.
  • Recommended reading:

Possible tasks to fulfill the patch requirement:

Linux-like Loss Detection Techniques for ns-3 TCP

Mentors: Mohit P. Tahiliani, Bhaskar Kataria

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: Mohit P. Tahiliani, Bhaskar Kataria

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>"
Add support for LEDBAT++ in ns-3

Mentors: Mohit P. Tahiliani

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.

Wi-Fi examples and tutorial

Mentor: Tom Henderson

Note: This could be proposed as either a medium- or large-sized project.

The ns-3 Wi-Fi model is one of the most highly used and advanced ns-3 model, and it is currently being developed, with industry support. to model the future Wi-Fi standards including Wi-Fi 7. There are a large set of examples in the "examples/wireless" directory. Some of these are duplicative and not as in sync with latest standards. There isn't any sort of Wi-Fi specific tutorial or well-designed example program that, for instance, traces the lifecycle of a typical packet through the Wi-Fi model and channel. This project would be to improve the usability and examples of the Wi-Fi module, and write corresponding tutorial documentation. New helpers and trace sources will likely be introduced, and new ways to visualize the Wi-Fi model operation (visualization of output data) are also of interest. The main output will be a Wi-Fi specific tutorial that carefully walks the reader through (new) well-designed example programs. Programs that could be used in academic courses could also be in scope. Providing programs to reproduce published performance results are another possibility. Fixing open issues along the way would also be a bonus.

5G NR examples and tutorial

Mentors: Tom Henderson, Biljana Bojovic, Katerina Koutlia

Note: This could be proposed as either a medium- or large-sized project.

Readers will note the similarity of this project idea to the previous one. Likewise, the ns-3 5G NR model is one of the most highly used and advanced ns-3 model. Unlike Wi-Fi, this code exists as an add-on module to ns-3 at the current time (see the app store page). However, this model is very detailed and it is quite difficult for newcomers to understand and follow something as basic as the lifecycle of a packet through the system. This project would be to improve the usability and examples of the 5G NR module, and write corresponding tutorial documentation. New helpers and trace sources will likely be introduced, and new ways to visualize the 5G NR model operation (visualization of output data) are also of interest. The main output will be a 5G NR specific tutorial that carefully walks the reader through (new) well-designed example programs. Programs that could be used in academic courses could also be in scope. Providing programs to reproduce published performance results are another possibility. Fixing open issues along the way would also be a bonus.

I would like to focus on developing one well-worked example that can be used as an entry point to performing 5G NR simulations. This example should scale to very small and very large scenarios. Users should have a clear understanding of which features are implemented and which are lacking or heavily abstracted. Users should be able to trace the lifecycle of an arbitrary packet as it traverses the system, understanding what objects it passes through and where it spends its time queued in the stack. Users should be able to easily manage the configuration of the many parameters of the scenario. Plots of performance should be easily generated.

For starters, I would suggest to add the CTTC LENA 5G nr module to ns-3, in the typical way (as a module in the contrib/ directory) , and build and run the examples. Documentation is available from here: https://5g-lena.cttc.es/. There is an overview tutorial video available here: https://acmse.net/2021/tutorials-offered/#tut-work03. That is the background information.

For more specific guidelines, please view this Google document.

  • Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks
  • Interests: 5G NR simulations
  • Difficulty: Medium.
  • Patch requirement: See the Google document

Large projects (350 hours)

IPv6 global routing

Mentors: Tommaso Pecorella, [TBD].

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 GlobalRouting don't work for IPv6 (NixRouting was migrated to IPv6 recently), 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.).

The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts. The proposer is advised to check the approach used for NixRouting, as it might be a starting point.

Possible tasks to fulfill the patch requirement:

  • 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.
Enable IPv6 support for Ad hoc Routing Protocols in ns-3

Mentors: Tommaso Pecorella, [TBD].

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
Linux-like CAKE queue discipline for ns-3

Mentors: Mohit P. Tahiliani, Bhaskar Kataria

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.

MinstrelHt improvements

Mentor: Tom Henderson

Minstrel-HT is a rate adaptation algorithm for Wi-Fi devices that has been added to the Linux kernel and is in wide use. ns-3 has a model of MinstrelHt, contributed to the project about 10 years ago. Since that time, MinstrelHt has evolved in the Linux kernel, while ns-3's Minstrel has stayed mostly the same. Furthermore, as the above link highlights, there are limited tests and documentation. We are seeking a student interested in upgrading, testing, and documenting ns-3's MinstrelHt to bring it into alignment with modern Linux kernels. For a summary of some of the technical issues, please see this ns-3 tracker issue. Time permitting, some research extensions/features could be considered to be added, such as Minstrel-CDHT, dynamic use of short guard interval, or Minstrel-Piano.

ns3-ai improvements

Mentors: Hao Yin, Collin Brady

ns3-ai is an extension for ns-3 that provides fast and flexible interfaces between ns-3 and Python based open-source frameworks such as TensorFlow and PyTorch using shared memory. However, with large-scale networks, some research problems like resource allocation may require frequent interactions between ns-3 and Python, which can lead to 10x time increases in the simulation time. This proposed project is oriented around performance benchmarking and further optimizing the ns3-ai model and providing more documents and examples.

The project goals are:

  1. Improvements over the current ns3-ai model to reduce the interaction between C++ and Python: Support more data structures with shared memory like Vector and String.
  2. Provide examples of using C++ to implement the ML algorithms within ns-3: Compile with the open-source frameworks like TensorFlow and PyTorch in C++ and implement example algorithms like DQN.
  3. Improve the current examples and documentations and integrate new examples like LTE-handover.
  • Required Experience: Familiarity with Python and C++ programming.
  • Bonus Experience: Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.
  • Interests: ML in wireless communication, IPC programming.
  • Difficulty: Medium
  • Patch requirement: GSOC2023PatchRequirement
  • Recommended reading:
L4S tests and examples

Mentor: Tom Henderson

Quoting Jason Livingood recently on the IETF tsvwg mailing list: "The TSVWG recently finished RFC 9330, 9331, and 9332, related to Low Latency, Low Loss, Scalable Throughput (L4S). As network operators, operating system developers, application developers, and researchers work together to operationalize, test, and measure L4S experiments, this list will serve as a forum for detailed discussions and sharing of experiences. " Jason was referring to a new mailing list formation.

In 2020, ns-3 had a GSoC project on TCP Prague, but the code has not yet been merged, mainly due to lack of completion of tests. Now that the IETF has approved of the L4S RFCs, it would be helpful for ns-3 to have a working model of an L4S-aware TCP. This project would update TCP Prague to the latest Linux code and ensure that the L4S support in our queue models is working correctly, and work to merge TCP Prague to the ns-3 mainline. Then, the project would focus on examples and validations that mirror some of the tests that were conducted in the tsvwg working group and published academic papers on TCP Prague and L4S.

  • Required Experience:"" Some familiarity with how TCP and AQM work.
  • Bonus Experience:** Understanding of Linux code for TCP and AQM.
  • Interests: New congestion control algorithms, IETF standards
  • Difficulty: Medium
  • Patch requirement: GSOC2023PatchRequirement
  • Recommended reading: RFC 9330, paper on dual queue