https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&user=Tommaso&feedformat=atomNsnam - User contributions [en]2024-03-28T20:24:47ZUser contributionsMediaWiki 1.24.1https://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13041GSOC2024Projects2024-02-11T19:05:46Z<p>Tommaso: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''Note to contributors:''' These ideas are not listed in any priority order.<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope. Please check each idea for details about its foreseen difficulty level.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#Improving 5G NR module usability]] (medium size project, 175h)<br />
* [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br />
* [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== 5G NR module benchmark analysis for different channel models =====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13040GSOC2024Projects2024-02-11T19:03:41Z<p>Tommaso: /* Lr-WPAN (IEEE 802.15.4) preamble detection support */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#Improving 5G NR module usability]] (medium size project, 175h)<br />
* [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br />
* [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== 5G NR module benchmark analysis for different channel models =====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet].<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13039GSOC2024Projects2024-02-11T19:03:06Z<p>Tommaso: /* 5G NR models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#Improving 5G NR module usability]] (medium size project, 175h)<br />
* [[#Improving 5G NR module visualizations]] (medium size project, 175h)<br />
* [[#5G NR module benchmark analysis for different channel models]] (medium size project, 175h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== 5G NR module benchmark analysis for different channel models =====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13038GSOC2024Projects2024-02-11T19:01:46Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#Improving 5G NR module usability]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira], [mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== 5G NR module benchmark analysis for different channel models =====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13037GSOC2024Projects2024-02-11T19:00:16Z<p>Tommaso: /* 5G NR models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#Improving 5G NR module usability]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira],[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
=====5G NR module benchmark analysis for different channel models=====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13036GSOC2024Projects2024-02-11T18:59:22Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
=== 5G NR models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira],[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
=====5G NR module benchmark analysis for different channel models=====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13035GSOC2024Projects2024-02-11T18:59:02Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project, 175h)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project, 175h)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project, 350h)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project, 350h)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira],[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
=====5G NR module benchmark analysis for different channel models=====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13034GSOC2024Projects2024-02-11T18:57:20Z<p>Tommaso: /* Internet models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. Some of the below links are from our 2023 edition; we will update them if we learn that we are accepted into GSOC again on February 20.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before updating the above link for 2024, but it will be similar to last year's application.<br />
* Next, proceed to get in touch with the developers on the mailing list or Zulip chat room and refine your proposal.<br />
* 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.<br />
<br />
Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2024. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
'''Note:''' This patch requirement may be updated or removed for our 2024 program; please check back later.<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project, 175h)<br />
* [[#IPv6 global routing]] (large size project, 350h)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project, 175h)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project, 350h)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
===== Improving 5G NR module usability =====<br />
<br />
Mentors: [mailto:bbojovic@cttc.es Biljana Bojovic],[mailto:kkoutlia@cttc.es Katerina Koutlia] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. The project consists of the following: <br />
<br />
* Improving nr helpers support: The outcome would be the implementation of new helpers and the improvement of existing ones, with the final goal of easing the usage of the 5G nr module. For example, some helpers do not have Doxygen documentation, and others require more than 30 lines of code just to specify the required 3GPP scenario. Helpers could be focused on simplifying the setup of nr scenarios, for example, the internet, the 3GPP scenario, the XR applications, the management of the configuration of many parameters of the scenario, etc. All nr examples should be updated to make use of these new helpers.<br />
<br />
* A completely new example should be created that would be 3GPP compliant and ready for research purposes and collaborative research. The idea is that if a new user is interested in implementing some new MAC scheduler or PHY algorithms, can take this new example as it is and use it to run a simulation campaign for its research on a realistic 5G scenario that is according to a selected 3GPP reference scenario. We could even think of a set of different predefined 3GPP scenarios, e.g. indoor, outdoor, etc. So, the new 5G-LENA user would not have to waste his/her research time in creating a new example but could pick this example and use it as it is to test his/her algorithm. Such examples would allow collaborative research because the users could reference such examples in their publications, and compare these results with the results with other researchers' algorithms.<br />
<br />
* As a final step, to validate the correct configuration through the helpers, it would be useful to have an easy way to generate plots of indicative performance metrics, such as the throughput and/or the delay (other metrics are also welcomed). For this purpose, some plotting scripts should be added to the examples folder. <br />
<br />
* Additionally, creating an “integration” example could be defined as the final part of the project, in the case of applying for a large project. The integration example is the example that demonstrates to nr users how to combine the nr module with another ns-3 module. See ns-3 Appstore here: https://apps.nsnam.org/app/tag/all/). Alternatively, integration with some external research tools could be proposed. For example, the interesting scenarios would involve the integration example that considers some of the following:<br />
** NetSimulyzer (https://apps.nsnam.org/app/netsimulyzer/),<br />
** Ns-3 gym (https://apps.nsnam.org/app/ns3-gym/) <br />
** NYSIM (https://apps.nsnam.org/app/nyusim/)<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
===== Improving 5G NR module visualizations =====<br />
<br />
Mentors: [mailto:gcarvalho@cttc.es Gabriel Ferreira],[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
Note: This could be proposed as either a small- or medium-sized project.<br />
<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be to improve the usability and examples of the 5G nr module by adding visualization tools to enrich the end-user experience.<br />
<br />
The main output will be the creation or porting of one (if small) or more examples from C++ to Python and adding visualization capabilities based on existing traces. The idea is that users can then see how the visualization was generated and better understand how the metrics collection works, and how changing parameters can affect simulation results. For this, the Jupyter notebook will be used, while Python scripts will be implemented for the visualization of the results. <br />
<br />
Examples to be implemented in Python:<br />
<br />
* An animated version of the REM map showing gNB beams moving along with a moving UE.<br />
* Resource allocation grid comparison for different resource schedulers.<br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), then building and running the examples. After getting used to C++, then proceed to use the Python bindings, as described by the documentation: https://www.nsnam.org/docs/manual/html/python.html#using-the-bindings-from-the-ns-3-source.<br />
Documentation is available 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 [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Required Experience: C++ and Python programming, understanding of 5G NR, LTE, and wireless networks<br />
* Interests: 5G NR simulations<br />
* Difficulty: Medium.<br />
* Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
=====5G NR module benchmark analysis for different channel models=====<br />
<br />
Mentors:[mailto:aashtari@cttc.es Amir Ashtari Gargari], <br />
[mailto:bbojovic@cttc.es Biljana Bojovic] and [mailto:gcarvalho@cttc.es Gabriel Ferreira]<br />
<br />
Note: This could be proposed as either a medium- or large-sized project.<br />
The ns-3 5G nr module (aka 5G-LENA) is one of the most highly used and advanced ns-3 modules for simulating the 5G NR network. This project would be focused on improving the usability and examples of the 5G nr module. <br />
<br />
The ns-3 nr module should be able to make use of different channel models, however, all the currently available examples in the nr module use the ns-3 3GPP channel model. This project should extend the nr module to allow the configuration of additional channel models, such as TwoRaySpectrumPropagationLoss, and NYSim, and create a benchmark example that would allow switching among different channel models. The project should consist of the following steps:<br />
<br />
* TwoRaySpectrumPropagationLossModel was developed by Matteo Pagin during GSoC 2022: https://www.nsnam.org/wiki/GSOC2022Channel, with a main goal to provide an alternative channel model to ns-3 3GPP channel model that would be less computationally expensive and thus be a good choice for the large-scale 5G NR simulation. Matteo Pagin developed during his GSoC an NR example that uses this model, this example should be ported to the NR module. To allow the configuration of this model Matteo Pagin extended the NrHelper to allow that configuration. Such changes should be ported also to the NR module and used as an example of how to extend the NrHelper to allow the configuration of the NYSim channel model.<br />
<br />
* Additionally, the student should investigate what are the API changes that should be done in the NR module, mainly NrHelper, to allow the usage of the NYSim channel model. As an example, see how the mmWave module makes use of both 3GPP and NYSim channel models: https://apps.nsnam.org/app/mmwave/. Also, see the NYSim module in the ns-3 App Store:https://apps.nsnam.org/app/nyusim/. See also an additional description in the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
<br />
* Finally, a common benchmark scenario example that can make use of these three channel models should be created and used to perform the profiling study. An example could be the extension of Matteo's example or a completely new example. Additionally, the performance evaluation analysis of the NR should be done for the three models, and provide some insights into the assessed differences. <br />
<br />
* If during the performance analysis, the student detects the performance bottlenecks in the simulator that could be improved, the project could be extended to be a large-sized project.<br />
<br />
The project proposal should contain a refactoring plan and should list what changes will be made to the NR module to support the use of the TwoRaySpectrumPropagationLossModel and NYSim channel model. The project plan should also contain some idea of what scenario will be used for the performance evaluation, which frequency, outdoor or indoor, and the number of gNBs and UEs that will be profiled. The project plan should also include a description of the performance analysis with a target performance indicative metrics. There will be benchmark metrics related to the speed of the execution of the simulator, and also the NR performance metrics such as throughput and delay. The project plan should well define the development steps that would result in the often MRs toward the nr module and ns-3 upstream during the whole duration of the project. <br />
<br />
For starters, we would suggest adding the CTTC 5G-LENA (nr module) to ns-3, in the typical way (as a module in the contrib/ directory), and building and running 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.<br />
<br />
For more specific guidelines, please view this [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document].<br />
*Required Experience: C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
*Interests: 5G NR simulations<br />
*Difficulty: Medium-High.<br />
*Patch requirement: See the [https://docs.google.com/document/d/1cQLIF1cdft1yj3vyWrjrxN2xDJMx8PuWaa9NP_nKf64/edit?usp=sharing Google document]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13021GSOC2024Projects2024-02-02T18:16:45Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
* [[#Lr-WPAN (IEEE 802.15.4) preamble detection support]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13020GSOC2024Projects2024-02-02T18:16:18Z<p>Tommaso: /* Mesh Link Establishment (MLE) protocol */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Lr-WPAN (IEEE 802.15.4) preamble detection support =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], alramonet@is.tokushima-u.ac.jp Alberto Gallegos Ramonet.<br />
<br />
A preamble is a series of defined bits that signal the data transmission between two or more devices. The current Lr-WPAN module takes into consideration the preamble transmission time but<br />
it does not support preamble detection (hence there is no chance of detection failure). Implementing preamble detection would have the added benefit of adding RSSI support to the Lr-WPAN module which<br />
itself has many added benefits.<br />
<br />
This project touches on some core PHY functions of the Lr-WPAN module (the detection of packets). Unlike similar ns-3 modules, Lr-WPAN is relatively simple, therefore, it is a good opportunity to learn about Lr-WPAN and how PHYs are handled in ns-3.<br />
<br />
As usual, reduction of code duplicity and a flexible scalable design is desired (e.g. Allow the inclusion of different preambles in the future).<br />
<br />
* ''Required Experience:'' Basic understanding of IEEE 802.15.4, C++ programming.<br />
* ''Bonus Experience:'' PHY process familiarity, Familiarity with ns-3's Lr-WPAN<br />
* ''Interests:'' Lr-WPAN, MAC and PHY designs<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://ieeexplore.ieee.org/document/1700009 IEEE 802.15.4-2006]<br />
** [https://ieeexplore.ieee.org/document/7460875 IEEE 802.15.4-2015]<br />
** [https://www.nsnam.org/docs/models/html/lr-wpan.html ns-3 lr-wpan module]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13019GSOC2024Projects2024-02-01T04:29:31Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13018GSOC2024Projects2024-02-01T04:28:26Z<p>Tommaso: /* Mesh Link Establishment (MLE) protocol */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
==== Mesh Link Establishment (MLE) protocol ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
** [https://www.threadgroup.org/ThreadSpec Thread specifications]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13017GSOC2024Projects2024-02-01T04:27:34Z<p>Tommaso: /* Internet models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#DHCPv6 (DHCP for IPv6)]] (medium size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Mesh Link Establishment (MLE) protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13016GSOC2024Projects2024-02-01T04:26:51Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
===== DHCPv6 (DHCP for IPv6) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
DHCP is extremely important for IPv4 networks, because IPv4 lacks the address auto-configuration. Hence, DHCP is practically always used in IPv4.<br />
IPv6 does have the address auto-configuration (SLAAC), but it also does have DHCPv6. The two techniques are equally useful, and each have its pros and cons.<br />
<br />
ns-3 does have a model for DHCP, but it does not have one for DHCPv6. The goal is to add this functionality.<br />
<br />
The candidate should outline in the proposal the approach to the implementation (e.g., new application, extension of the current DHCP model, etc.).<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with DHCP and/or DHCPv6<br />
* ''Interests:'' IPv6<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8415 RFC 8415]<br />
<br />
Possible tasks to fulfil the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Mesh Link Establishment (MLE) protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13015GSOC2024Projects2024-02-01T04:15:13Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (medium size project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (medium size project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (large size project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Mesh Link Establishment (MLE) protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13014GSOC2024Projects2024-02-01T04:14:49Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]] (Medium project)<br />
* [[#6LoWPAN neighbor discovery protocol]] (Medium project)<br />
* [[#Mesh Link Establishment (MLE) protocol ]] (Large project)<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Mesh Link Establishment (MLE) protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13013GSOC2024Projects2024-02-01T04:13:51Z<p>Tommaso: /* IPv6 support in Ad hoc Routing Protocols */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]]<br />
* [[#6LoWPAN neighbor discovery protocol]]<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Mesh Link Establishment (MLE) protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], TBD.<br />
<br />
The Mesh Link Establishment (MLE) is a proposed IETF protocol for establishing and configuring secure radio links in IoT networks. It was originally proposed for IEEE 802.15.4, and the IETF draft seems to be not progressing.<br />
However, MLE is being used in Thread, and it can be useful to implement it.<br />
<br />
The goal of the project is to study the differences between the IETF version of MLE and the one being used in Thread, and propose an implementation that complies with either, or both.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Hard.<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-ietf-6lo-mesh-link-establishment MLE draft]<br />
** [https://openthread.io/guides/thread-primer/network-discovery Thread primer]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13012GSOC2024Projects2024-02-01T04:00:11Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]]<br />
* [[#6LoWPAN neighbor discovery protocol]]<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13011GSOC2024Projects2024-02-01T03:59:50Z<p>Tommaso: /* 6LoWPAN mesh-under routing enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]]<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
<br />
===== 6LoWPAN neighbor discovery protocol =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniquness across a network that can potentially use different MAC/PHY layers.<br />
<br />
There is a model for 6LoWPAN-ND, but it still not merged in the main ns-3 branch. The goal is to cleanup the implementation, remove an actual limitation due to a questionble assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).<br />
<br />
The candidate should outline in the proposal the parts of the code should be modified, and how. The repository for 6LoWPAN-ND is necessary, and the link will be shared upon request.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with 6LoWPAN and 6LoWPAN-ND<br />
* ''Interests:'' IPv6 and IoT networks<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/rfc8505 RFC 8505]<br />
** [https://datatracker.ietf.org/doc/html/rfc6775 RFC 6775]<br />
** [https://datatracker.ietf.org/doc/html/rfc4944 RFC 4944]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* Patch the actual 6LoWPAN-ND to remove the limitation about concurrent address registrations.<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13010GSOC2024Projects2024-02-01T03:50:02Z<p>Tommaso: /* IoT models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* [[#6LoWPAN mesh-under routing enhancements]]<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13009GSOC2024Projects2024-02-01T03:49:31Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* TBD<br />
<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
<br />
===== 6LoWPAN mesh-under routing enhancements =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
The 6LoWPAN module offers a simple option to implement a multi-hop topology by using a contolled flooding. However, the implemented controlled flooding is very simple, and is not efficient in complex networks. This is mainly due to the lack of congestion control, or rather its naive implementation.<br />
A better approach would be to borrow some concepts and ideas from RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL), so that messages do not generate network congestions when the network is large.<br />
<br />
The candidate should outline what parts of code are going to be affected, and how they can be enhanced thanks to RFC 7731.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with mesh routing and 6LoWPAN ns-3<br />
* ''Interests:'' IPv6 mesh routing<br />
* ''Difficulty:'' Easy.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/sixlowpan.html#mesh-under-routing Mesh-under in ns-3 6LoWPAN]<br />
** [https://datatracker.ietf.org/doc/html/rfc7731 RFC 7731]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* TBD<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13008GSOC2024Projects2024-01-31T19:38:51Z<p>Tommaso: /* Internet models enhancements */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable)]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* TBD<br />
<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13007GSOC2024Projects2024-01-31T19:36:32Z<p>Tommaso: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
The projects can be grouped depending on their scope and/or their size. Below they are organized according to their scope.<br />
<br />
=== Internet models enhancements ===<br />
<br />
* [[#ICMP socket and generate/handle ICMP messages (host/net unreachable) | ICMP socket and generate/handle ICMP messages]] (medium size project)<br />
* [[#IPv6 global routing]] (large size project)<br />
* [[#IPv6 support in Ad hoc Routing Protocols]] (large size project)<br />
<br />
=== IoT models enhancements ===<br />
<br />
* TBD<br />
<br />
<br />
== Medium sized projects (175 hours) ==<br />
<br />
<br />
=== ICMP socket and generate/handle ICMP messages (host/net unreachable) ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
== Large projects (350 hours) ==<br />
<br />
=== IPv6 global routing ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
=== IPv6 support in Ad hoc Routing Protocols ===<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13006GSOC2024Projects2024-01-31T19:29:41Z<p>Tommaso: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
=== Medium sized projects (175 hours) ===<br />
<br />
[[#ICMP socket and generate/handle ICMP messages (host/net unreachable) | ICMP socket and generate/handle ICMP messages]]<br />
<br />
==== ICMP socket and generate/handle ICMP messages (host/net unreachable) ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
=== Large projects (350 hours) ===<br />
<br />
==== IPv6 global routing ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13005GSOC2024Projects2024-01-31T19:27:47Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
[[#ICMP socket and generate/handle ICMP messages (host/net unreachable) | ICMP socket and generate/handle ICMP messages]]<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13004GSOC2024Projects2024-01-31T19:27:21Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
[[ICMP socket and generate/handle ICMP messages (host/net unreachable) | ICMP socket and generate/handle ICMP messages]]<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13003GSOC2024Projects2024-01-31T19:26:31Z<p>Tommaso: </p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
[[ICMP socket and generate/handle ICMP messages]]<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13002GSOC2024Projects2024-01-31T07:11:24Z<p>Tommaso: /* Mentors */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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. 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.<br />
<br />
The current list of prospective mentors can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13001GSOC2024Projects2024-01-31T07:03:37Z<p>Tommaso: </p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2024Projects&diff=13000GSOC2024Projects2024-01-31T07:02:53Z<p>Tommaso: Created page with "{{TOC}} This page contains 2024 Google Summer of Code project ideas for ns-3. * [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions] * GS..."</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2024 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-23. We seek contributors interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Dynamic device registration for NetAnim simulation animations =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Linux-like Loss Detection Techniques for ns-3 TCP =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br />
* ''Interests:'' TCP packet loss detection techniques.<br />
* ''Difficulty:'' Medium to Hard.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended Reading:''<br />
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]<br />
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
<br />
===== Upgrade the AQM Evaluation Suite for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with AQM and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br />
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended Reading:''<br />
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br />
** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br />
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br />
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:<br />
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''<br />
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''<br />
<br />
===== Add support for LEDBAT++ in ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]<br />
<br />
===== Wi-Fi examples and tutorial =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://www.wired.com/story/what-is-wi-fi-7/ 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.<br />
<br />
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks<br />
* ''Interests:'' Wi-Fi simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Background:''<br />
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).<br />
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.<br />
** check back later for more links<br />
<br />
===== 5G NR examples and tutorial =====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://apps.nsnam.org/app/nr/ 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].<br />
<br />
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* ''Interests:'' 5G NR simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
===== IPv6 global routing =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Linux-like CAKE queue discipline for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br />
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br />
* ''Difficulty:'' Medium to Hard<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br />
** [https://lwn.net/Articles/758353/ Let them run CAKE]<br />
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br />
<br />
===== MinstrelHt improvements =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
[https://lwn.net/Articles/376765/ 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 [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager 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 [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue]. Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].<br />
<br />
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.<br />
* ''Interests:'' Wi-Fi, adaptive algorithms.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]<br />
* ''Getting started:''<br />
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?<br />
<br />
===== ns3-ai improvements =====<br />
<br />
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]<br />
<br />
[https://apps.nsnam.org/app/ns3-ai/ 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.<br />
<br />
The project goals are:<br />
# 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.<br />
# 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.<br />
# Improve the current examples and documentations and integrate new examples like LTE-handover.<br />
<br />
* ''Required Experience:'' Familiarity with Python and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.<br />
* ''Interests:'' ML in wireless communication, IPC programming.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]<br />
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]<br />
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]<br />
<br />
===== L4S tests and examples =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
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 [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.<br />
<br />
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ 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.<br />
<br />
* ''Required Experience:"" Some familiarity with how TCP and AQM work.<br />
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.<br />
* ''Interests:'' New congestion control algorithms, IETF standards<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12805GSOC2023Projects2023-04-04T14:32:07Z<p>Tommaso: /* ICMP socket and generate/handle ICMP messages (host/net unreachable) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Dynamic device registration for NetAnim simulation animations =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Linux-like Loss Detection Techniques for ns-3 TCP =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br />
* ''Interests:'' TCP packet loss detection techniques.<br />
* ''Difficulty:'' Medium to Hard.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended Reading:''<br />
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]<br />
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
<br />
===== Upgrade the AQM Evaluation Suite for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with AQM and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br />
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended Reading:''<br />
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br />
** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br />
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br />
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:<br />
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''<br />
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''<br />
<br />
===== Add support for LEDBAT++ in ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]<br />
<br />
===== Wi-Fi examples and tutorial =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://www.wired.com/story/what-is-wi-fi-7/ 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.<br />
<br />
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks<br />
* ''Interests:'' Wi-Fi simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Background:''<br />
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).<br />
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.<br />
** check back later for more links<br />
<br />
===== 5G NR examples and tutorial =====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://apps.nsnam.org/app/nr/ 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].<br />
<br />
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* ''Interests:'' 5G NR simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
===== IPv6 global routing =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Linux-like CAKE queue discipline for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br />
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br />
* ''Difficulty:'' Medium to Hard<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br />
** [https://lwn.net/Articles/758353/ Let them run CAKE]<br />
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br />
<br />
===== MinstrelHt improvements =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
[https://lwn.net/Articles/376765/ 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 [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager 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 [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue]. Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].<br />
<br />
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.<br />
* ''Interests:'' Wi-Fi, adaptive algorithms.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]<br />
* ''Getting started:''<br />
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?<br />
<br />
===== ns3-ai improvements =====<br />
<br />
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]<br />
<br />
[https://apps.nsnam.org/app/ns3-ai/ 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.<br />
<br />
The project goals are:<br />
# 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.<br />
# 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.<br />
# Improve the current examples and documentations and integrate new examples like LTE-handover.<br />
<br />
* ''Required Experience:'' Familiarity with Python and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.<br />
* ''Interests:'' ML in wireless communication, IPC programming.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]<br />
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]<br />
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]<br />
<br />
===== L4S tests and examples =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
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 [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.<br />
<br />
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ 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.<br />
<br />
* ''Required Experience:"" Some familiarity with how TCP and AQM work.<br />
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.<br />
* ''Interests:'' New congestion control algorithms, IETF standards<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12804GSOC2023Projects2023-04-04T14:31:51Z<p>Tommaso: /* Dynamic device registration for NetAnim simulation animations */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto: manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Dynamic device registration for NetAnim simulation animations =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Linux-like Loss Detection Techniques for ns-3 TCP =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br />
* ''Interests:'' TCP packet loss detection techniques.<br />
* ''Difficulty:'' Medium to Hard.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended Reading:''<br />
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]<br />
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
<br />
===== Upgrade the AQM Evaluation Suite for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with AQM and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br />
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended Reading:''<br />
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br />
** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br />
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br />
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:<br />
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''<br />
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''<br />
<br />
===== Add support for LEDBAT++ in ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]<br />
<br />
===== Wi-Fi examples and tutorial =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://www.wired.com/story/what-is-wi-fi-7/ 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.<br />
<br />
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks<br />
* ''Interests:'' Wi-Fi simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Background:''<br />
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).<br />
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.<br />
** check back later for more links<br />
<br />
===== 5G NR examples and tutorial =====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://apps.nsnam.org/app/nr/ 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].<br />
<br />
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* ''Interests:'' 5G NR simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
===== IPv6 global routing =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Linux-like CAKE queue discipline for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br />
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br />
* ''Difficulty:'' Medium to Hard<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br />
** [https://lwn.net/Articles/758353/ Let them run CAKE]<br />
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br />
<br />
===== MinstrelHt improvements =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
[https://lwn.net/Articles/376765/ 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 [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager 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 [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue]. Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].<br />
<br />
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.<br />
* ''Interests:'' Wi-Fi, adaptive algorithms.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]<br />
* ''Getting started:''<br />
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?<br />
<br />
===== ns3-ai improvements =====<br />
<br />
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]<br />
<br />
[https://apps.nsnam.org/app/ns3-ai/ 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.<br />
<br />
The project goals are:<br />
# 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.<br />
# 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.<br />
# Improve the current examples and documentations and integrate new examples like LTE-handover.<br />
<br />
* ''Required Experience:'' Familiarity with Python and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.<br />
* ''Interests:'' ML in wireless communication, IPC programming.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]<br />
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]<br />
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]<br />
<br />
===== L4S tests and examples =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
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 [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.<br />
<br />
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ 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.<br />
<br />
* ''Required Experience:"" Some familiarity with how TCP and AQM work.<br />
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.<br />
* ''Interests:'' New congestion control algorithms, IETF standards<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12803GSOC2023Projects2023-04-04T14:31:26Z<p>Tommaso: /* Dynamic device registration for NetAnim simulation animations */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto: manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Dynamic device registration for NetAnim simulation animations =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto: manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Linux-like Loss Detection Techniques for ns-3 TCP =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br />
* ''Interests:'' TCP packet loss detection techniques.<br />
* ''Difficulty:'' Medium to Hard.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended Reading:''<br />
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]<br />
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
<br />
===== Upgrade the AQM Evaluation Suite for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with AQM and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br />
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended Reading:''<br />
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br />
** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br />
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br />
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:<br />
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''<br />
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''<br />
<br />
===== Add support for LEDBAT++ in ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]<br />
<br />
===== Wi-Fi examples and tutorial =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://www.wired.com/story/what-is-wi-fi-7/ 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.<br />
<br />
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks<br />
* ''Interests:'' Wi-Fi simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Background:''<br />
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).<br />
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.<br />
** check back later for more links<br />
<br />
===== 5G NR examples and tutorial =====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://apps.nsnam.org/app/nr/ 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].<br />
<br />
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* ''Interests:'' 5G NR simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
===== IPv6 global routing =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Linux-like CAKE queue discipline for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br />
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br />
* ''Difficulty:'' Medium to Hard<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br />
** [https://lwn.net/Articles/758353/ Let them run CAKE]<br />
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br />
<br />
===== MinstrelHt improvements =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
[https://lwn.net/Articles/376765/ 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 [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager 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 [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue]. Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].<br />
<br />
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.<br />
* ''Interests:'' Wi-Fi, adaptive algorithms.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]<br />
* ''Getting started:''<br />
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?<br />
<br />
===== ns3-ai improvements =====<br />
<br />
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]<br />
<br />
[https://apps.nsnam.org/app/ns3-ai/ 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.<br />
<br />
The project goals are:<br />
# 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.<br />
# 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.<br />
# Improve the current examples and documentations and integrate new examples like LTE-handover.<br />
<br />
* ''Required Experience:'' Familiarity with Python and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.<br />
* ''Interests:'' ML in wireless communication, IPC programming.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]<br />
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]<br />
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]<br />
<br />
===== L4S tests and examples =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
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 [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.<br />
<br />
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ 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.<br />
<br />
* ''Required Experience:"" Some familiarity with how TCP and AQM work.<br />
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.<br />
* ''Interests:'' New congestion control algorithms, IETF standards<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12802GSOC2023Projects2023-04-04T14:31:10Z<p>Tommaso: /* ICMP socket and generate/handle ICMP messages (host/net unreachable) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. <br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2023ApplicationTemplate |2023 GSoC Contributor application template]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
Each project idea has either a suggested task, or a link to a [[GSOC2023PatchRequirement | 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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
===== ICMP socket and generate/handle ICMP messages (host/net unreachable) =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto: manoj24.rana@gmail.com Manoj K. Rana].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Dynamic device registration for NetAnim simulation animations =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [[GSOC2023PatchRequirement]]<br />
<br />
===== Linux-like Loss Detection Techniques for ns-3 TCP =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with TCP implementation in Linux kernel.<br />
* ''Interests:'' TCP packet loss detection techniques.<br />
* ''Difficulty:'' Medium to Hard.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended Reading:''<br />
** Forward Acknowledgement (FACK) [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.2559&rep=rep1&type=pdf Paper]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Duplicate Selective Acknowledgment (DSACK) [[https://tools.ietf.org/html/rfc2883 RFC 2883]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
** Tail Loss Probe (TLP) [[https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Internet Draft]] [[https://gitlab.com/ShikhaBakshi/ns-3-dev/-/commits/TLP Implementation]]<br />
** Recent Acknowledgment (RACK) [[https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 Internet Draft]] [[https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/34/commits Implementation]]<br />
<br />
===== Upgrade the AQM Evaluation Suite for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with AQM and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with traffic control model in ns-3.<br />
* ''Interests:'' Packet Scheduling algorithms, AQM algorithms and ECN.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended Reading:''<br />
** AQM Evaluation Suite [[https://dl.acm.org/doi/abs/10.1145/3067665.3067674 Paper]] [[https://aqm-eval-suite.github.io/ Implementation]]<br />
** [https://tools.ietf.org/html/rfc7928 RFC 7928]<br />
** [https://www.nsnam.org/docs/models/html/traffic-control-layer.html Traffic Control Model in ns-3]<br />
* ''Patch requirement:'' Create a pull request to handle the case when an incorrect Scenario name or number is passed via command line. Examples:<br />
** ''./waf --run "aqm-eval-suite-runner --name=<unsupported scenario>"''<br />
** ''./waf --run "aqm-eval-suite-runner --number=<unsupported number>"''<br />
<br />
===== Add support for LEDBAT++ in ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with TCP, and in particular with LEDBAT<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01 LEDBAT++: Internet Draft]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/blob/master/src/internet/model/tcp-ledbat.cc LEDBAT implementation in ns-3]<br />
<br />
===== Wi-Fi examples and tutorial =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://www.wired.com/story/what-is-wi-fi-7/ 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.<br />
<br />
* ''Required Experience:'' C++ programming, understanding of Wi-Fi and wireless networks<br />
* ''Interests:'' Wi-Fi simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Background:''<br />
** IEEE P802.11 TGax defined [https://www.ieee802.org/11/Reports/tgax_update.htm simulation scenarios and methodology], which can be a target (such as the residential scenario 1).<br />
** MATLAB has [https://www.mathworks.com/help/wlan/ug/802-11ax-multinode-system-level-simulation-of-residential-scenario-using-matlab.html TGax residential scenario support] which can be used as a guide.<br />
** check back later for more links<br />
<br />
===== 5G NR examples and tutorial =====<br />
<br />
Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:bbojovic@cttc.es Biljana Bojovic], [mailto:kkoutlia@cttc.es Katerina Koutlia]<br />
<br />
'''Note:''' This could be proposed as either a medium- or large-sized project.<br />
<br />
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 [https://apps.nsnam.org/app/nr/ 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
For more specific guidelines, please view [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing this Google document].<br />
<br />
* ''Required Experience:'' C++ programming, understanding of 5G NR, LTE, and wireless networks<br />
* ''Interests:'' 5G NR simulations<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' See the [https://docs.google.com/document/d/1-xAt9c_XGcdOvDfcbr22aXM2mB-jK68zmtCIpqrDp_E/edit?usp=sharing Google document]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
===== IPv6 global routing =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
===== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 =====<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values<br />
<br />
===== Linux-like CAKE queue discipline for ns-3 =====<br />
<br />
Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:bhaskar.k7920@gmail.com Bhaskar Kataria]<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br />
* ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br />
* ''Difficulty:'' Medium to Hard<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br />
** [https://lwn.net/Articles/758353/ Let them run CAKE]<br />
** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br />
<br />
===== MinstrelHt improvements =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
[https://lwn.net/Articles/376765/ 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 [https://www.nsnam.org/docs/release/3.37/models/html/wifi-design.html#minstrelwifimanager 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 [https://gitlab.com/nsnam/ns-3-dev/-/issues/281 ns-3 tracker issue]. Time permitting, some research extensions/features could be considered to be added, such as [https://ieeexplore.ieee.org/document/8548800 Minstrel-CDHT], dynamic use of short guard interval, or [https://ieeexplore.ieee.org/abstract/document/6289295 Minstrel-Piano].<br />
<br />
* ''Required Experience:'' Familiarity with how Wi-Fi works, and with C++ programming.<br />
* ''Interests:'' Wi-Fi, adaptive algorithms.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' See [https://gitlab.com/nsnam/ns-3-dev/-/issues/868 ns-3 issue 868] on supporting Buffer Occupancy metric in the wifi stack. Or else work on the [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** [https://theses.hal.science/INSA-LYON-THESES/tel-03126953v1 Remy Grunblatt's thesis (especially chapter 5)]<br />
* ''Getting started:''<br />
** Is [https://gitlab.com/nsnam/ns-3-dev/-/issues/51 this bug] still an issue with our implementation?<br />
<br />
===== ns3-ai improvements =====<br />
<br />
Mentors: [mailto:haoyin@uw.edu Hao Yin], [mailto:collinbrady1993@gmail.com Collin Brady]<br />
<br />
[https://apps.nsnam.org/app/ns3-ai/ 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.<br />
<br />
The project goals are:<br />
# 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.<br />
# 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.<br />
# Improve the current examples and documentations and integrate new examples like LTE-handover.<br />
<br />
* ''Required Experience:'' Familiarity with Python and C++ programming.<br />
* ''Bonus Experience:'' Familiarity with Inter Process Communication (IPC, e.g., shared memory) and ML algorithms in communication.<br />
* ''Interests:'' ML in wireless communication, IPC programming.<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:''<br />
** The ns3-ai model: [https://dl.acm.org/doi/10.1145/3389400.3389404 Paper], [https://github.com/hust-diangroup/ns3-ai Code]<br />
** Shared memory blogs: '[https://yyc.solvcon.net/en/latest/writing/2016/resource/index.html Python_C++], [https://www.tutorialspoint.com/inter_process_communication/inter_process_communication_shared_memory.htm IPC shared memory]<br />
** AI frameworks with C++: [https://pytorch.org/tutorials/advanced/cpp_frontend.html PyTorch], [https://www.tensorflow.org/api_docs/cc TensorFlow]<br />
<br />
===== L4S tests and examples =====<br />
<br />
Mentor: [mailto:tomh@tomh.org Tom Henderson]<br />
<br />
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 [https://www.ietf.org/mailman/listinfo/l4s-discuss a new mailing list] formation.<br />
<br />
In 2020, ns-3 had a GSoC project on [https://deepakkavoor.github.io/gsoc-2020-prague/ 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.<br />
<br />
* ''Required Experience:"" Some familiarity with how TCP and AQM work.<br />
* ''Bonus Experience:** Understanding of Linux code for TCP and AQM.<br />
* ''Interests:'' New congestion control algorithms, IETF standards<br />
* ''Difficulty:'' Medium<br />
* ''Patch requirement:'' [[GSOC2023PatchRequirement]]<br />
* ''Recommended reading:'' [https://datatracker.ietf.org/doc/rfc9330/ RFC 9330], [https://arxiv.org/pdf/2209.01078.pdf paper on dual queue]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12758GSOC2023Projects2023-01-27T00:53:29Z<p>Tommaso: /* Project Ideas */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== Dynamic device registration for NetAnim simulation animations ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
====== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12757GSOC2023Projects2023-01-27T00:52:23Z<p>Tommaso: /* Enable IPv6 support for Ad hoc Routing Protocols in ns-3 */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== Dynamic device registration for NetAnim simulation animations ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
====== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12756GSOC2023Projects2023-01-27T00:52:02Z<p>Tommaso: /* IPv6 global routing */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== Dynamic device registration for NetAnim simulation animations ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
====== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12755GSOC2023Projects2023-01-27T00:51:39Z<p>Tommaso: /* NetAnim refactoring */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== Dynamic device registration for NetAnim simulation animations ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
====== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12754GSOC2023Projects2023-01-26T05:20:32Z<p>Tommaso: /* IPv6 global routing */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== NetAnim refactoring ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
<br />
====== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with AODV implementations in ns-3<br />
* ''Interests:'' Ad hoc routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br />
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/271 Issue #271] - olsr header and messages are not printing either their size or their content.<br />
* [https://gitlab.com/nsnam/ns-3-dev/-/issues/368 Issue #368] - aodv: aodv parameters can be set to "impossible" values</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12753GSOC2023Projects2023-01-26T05:19:30Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
====== NetAnim refactoring ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
* ''Required Experience:'' C++ programming.<br />
* ''Interests:'' Code refactoring.<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/wiki/NetAnim_3.108 NetAnim]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/162 Issue #162]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12752GSOC2023Projects2023-01-26T05:06:20Z<p>Tommaso: /* IPv6 global routing */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.).<br />
<br />
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.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12751GSOC2023Projects2023-01-26T05:02:32Z<p>Tommaso: /* Medium sized projects (175 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
====== ICMP socket and generate/handle ICMP messages (host/net unreachable) ======<br />
<br />
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
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.:<br />
* IPv6 ICMP messages (RA, RS, NA, NS, etc.),<br />
* IPv4 ICMP messages,<br />
* ICMP Echo and ICMPv6 Echo messages.<br />
and to handle properly ICMP error messages like Destination Unreachable in the Ping application.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv4 and IPv6 sockets, C++ programming.<br />
* ''Interests:'' Sockets and API interface implementation<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://man7.org/linux/man-pages/man2/socket.2.html Linux socket]<br />
** [https://courses.cs.vt.edu/cs4254/fall04/slides/raw_1.pdf Raw Sockets and ICMP, Srinidhi Varadarajan]<br />
** [https://gitlab.com/nsnam/ns-3-dev/-/issues/810 Issue #810]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* [TBD]<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
* 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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2023Projects&diff=12750GSOC2023Projects2023-01-26T04:35:12Z<p>Tommaso: /* Large projects (350 hours) */</p>
<hr />
<div>{{TOC}}<br />
<br />
This page contains 2023 Google Summer of Code project ideas for ns-3. Please note that ns-3 is applying to Google Summer of Code and will learn of acceptance or not on February 22.<br />
<br />
* [https://developers.google.com/open-source/gsoc/faq GSoC Frequently Asked Questions]<br />
* [[GSOC2023ContributorGuide |ns-3's 2023 GSoC Contributor guide]]<br />
* [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor/student guide (not ns-3 specific)]<br />
* [[GSOC2022ApplicationTemplate |2022 GSoC Contributor application template (2022 version, until we are accepted]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [https://archive.flossmanuals.net/gsocmentoring/index.html GSoC Mentor guide (not ns-3 specific)]<br />
* [[GSOCSelectionProcess | GSoC Contributor Selection Process]]<br />
* ''Get in contact with the ns-3 team'': [https://groups.google.com/g/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br />
<br />
=== About the ns-3 project ===<br />
<br />
ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Org admins ===<br />
<br />
Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br />
<br />
=== Mentors ===<br />
<br />
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.<br />
<br />
The current list of prospective mentors for 2023 can be found among the ideas listed below.<br />
<br />
=== How to apply ===<br />
<br />
For students or contributors interested in applying to ns-3 for GSoC, please go through the following list to get started:<br />
* Read the official [https://developers.google.com/open-source/gsoc/resources/guide GSoC contributor guide].<br />
* Read [[GSOC2023ContributorGuide |ns-3's GSoC contributor guide]]<br />
* Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br />
* Review the [https://www.nsnam.org/documentation/development-tree/ tutorial and contributing guide] thoroughly, if you have not already done so.<br />
* Once it is posted, look through the [[GSOC2023ApplicationTemplate |GSoC application template]] to start preparing your proposal. We will wait to see whether we are actually part of GSoC before posting this.<br />
* Next, proceed to get in touch with the developers on the mailing list or chat room and refine your proposal.<br />
* 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.<br />
<br />
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 [https://groups.google.com/g/ns-developers 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 [https://groups.google.com/g/ns-developers 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.<br />
<br />
<blockquote><br />
Each project idea within a particular priority has been tagged with the following properties:<br />
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br />
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br />
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful contributors might apply their experiences coming out of this project.<br />
* ''Difficulty:'' easy, medium or difficult<br />
* ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br />
<br />
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.<br />
</blockquote><br />
<br />
=== Patch requirement guidelines ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mentors: how to participate ===<br />
<br />
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:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
== Project Ideas ==<br />
<br />
'''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.<br />
<br />
==== Medium sized projects (175 hours) ====<br />
<br />
To be added.<br />
<br />
==== Large projects (350 hours) ====<br />
<br />
====== IPv6 global routing ======<br />
<br />
Mentors: [mailto:ameyanrd@outlook.com Ameya Deshpande], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella].<br />
<br />
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).<br />
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.<br />
Neither actually use any message between the nodes, so they also reduce the network overhead - something that is useful in many cases.<br />
<br />
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.<br />
<br />
The most important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br />
<br />
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br />
* ''Bonus Experience:'' Familiarity with NixRouting and GlobalRouting implementations in ns-3<br />
* ''Interests:'' IPv6 routing<br />
* ''Difficulty:'' Medium.<br />
* ''Recommended reading:''<br />
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/nix-vector-routing.html NixRouting model in ns-3]<br />
** [https://www.nsnam.org/docs/models/html/routing-overview.html#global-centralized-routing GlobalRouting model in ns-3]<br />
<br />
Possible tasks to fulfill the patch requirement:<br />
* 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.<br />
* 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.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=Installation&diff=12732Installation2022-12-04T10:45:51Z<p>Tommaso: </p>
<hr />
<div>{{TOC}}<br />
<br />
This is a detailed installation guide for ns-3. Basic installation instructions can be found in the [https://www.nsnam.org/docs/tutorial/html/index.html ns-3 tutorial] (see the [https://www.nsnam.org/docs/tutorial/html/quick-start.html Quick Start] chapter or else the more complete [https://www.nsnam.org/docs/tutorial/html/getting-started.html Getting Started] chapter).<br />
<br />
== Supported platforms ==<br />
<br />
ns-3 is primarily developed on GNU/Linux and macOS platforms, and the minimal requirements to run basic simulations are a C++ compiler; either [https://gcc.gnu.org/ g++] or [https://clang.llvm.org/ clang++] compiler, build system ([https://cmake.org CMake] and either [https://www.gnu.org/software/make/ make] or [https://ninja-build.org/ ninja]), and [http://www-python.org/ Python (version 3)] interpreter. The below instructions are per-platform instructions for supplemental packages that enable optional features of ns-3 or companion tools.<br />
<br />
=== Operating system and compiler support ===<br />
<br />
ns-3 is supported and currently tested on the following primary platforms:<br />
<br />
# Linux (x86 and x86_64): gcc/g++ versions 8 and above<br />
## '''Note:''' If you are using RHEL or Centos, you will likely need to install a more up-to-date compiler than the default; search for how to enable 'software collections' or 'devtoolset' on these distributions. Other Linux distributions typically have a suitable default compiler (at least version 4.9).<br />
# MacOS Apple LLVM: version 11.0.0 and above<br />
# FreeBSD and Linux (x86_64): clang/LLVM version 8 and later<br />
<br />
The minimum Python version supported is currently version 3.6 or greater (major version 3).<br />
<br />
By supported, we mean that the project tries to support most or all of the build options on these platforms unless there is a good reason to exclude the option; and at least the debug build will compile. If you intend to do serious work using ns-3, and are forced by circumstances to use a Windows platform, consider virtualization of a popular Linux platform or using [https://msdn.microsoft.com/en-us/commandline/wsl/install_guide Windows Subsystem for Linux]. <br />
<br />
Some aspects of ns-3 depend on Unix (or specifically Linux) support, such as the emulation or TapBridge features, and those components are not enabled on the Windows or MacOS versions cited above.<br />
<br />
Additional maintainers are invited to make more platforms, compilers and environments supported.<br />
<br />
=== Integrated development environment support ===<br />
<br />
Please see [https://www.nsnam.org/docs/tutorial/html/getting-started.html#building-with-ides this tutorial section] on configuring IDEs.<br />
<br />
==== Eclipse ====<br />
The [https://www.eclipse.org/ Eclipse IDE] is not an officially supported platform, but some developers use it and have compiled a [[HOWTO configure Eclipse with ns-3|HOWTO]].<br />
<br />
==== NetBeans ====<br />
[https://netbeans.org/ NetBeans] is not officially supported either, but there is a [[HOWTO_configure_NetBeans_with_ns-3|HOWTO]] as well.<br />
<br />
==== QtCreator ====<br />
Same rule applies to [http://qt-project.org/wiki/category:tools::qtcreator Qt Creator]; it's not officially supported, but there are developers that use it and [[HOWTO configure QtCreator with ns-3|HOWTO]] is available.<br />
<br />
=== Support for optional features ===<br />
<br />
There are a few options that are not enabled by default and are not available on all platforms. At the end of the configuration process (explained below), the status of these options are shown as detected by a '''waf''' or '''ns3''' script:<br />
<br />
<pre><br />
---- Summary of optional NS-3 features:<br />
Python Bindings : not enabled (Python library or headers missing)<br />
BRITE Integration : not enabled (BRITE not enabled (see option --with-brite))<br />
NS-3 Click Integration : not enabled (nsclick not enabled (see option --with-nsclick))<br />
GtkConfigStore : not enabled (library 'gtk+-2.0 >= 2.12' not found)<br />
XmlIo : not enabled (library 'libxml-2.0 >= 2.7' not found)<br />
Threading Primitives : enabled<br />
Real Time Simulator : enabled<br />
Emulated Net Device : not enabled (<netpacket/packet.h> include not detected)<br />
Network Simulation Cradle : not enabled (architecture None not supported)<br />
MPI Support : not enabled (option --enable-mpi not selected)<br />
NS-3 OpenFlow Integration : not enabled (OpenFlow not enabled (see option --with-openflow))<br />
SQlite stats data output : not enabled (library 'sqlite3' not found)<br />
Tap Bridge : not enabled (<linux/if_tun.h> include not detected)<br />
PyViz visualizer : not enabled (Python Bindings are needed but not enabled)<br />
Use sudo to set suid bit : not enabled (option --enable-sudo not selected)<br />
Build tests : not enabled (defaults to disabled)<br />
Build examples : not enabled (defaults to disabled)<br />
GNU Scientific Library (GSL) : not enabled (GSL not found)<br />
</pre><br />
<br />
Generally if the platform is missing some requirement for an option it is marked as "not enabled." Note that "disabled by user request" will be shown when the user explicitly disables a feature (such as "--disable-python"); and if a feature defaults to disabled this will also be noted (e.g., option --enable-sudo not selected).<br />
<br />
The table below is meant to help sort out the different features and on which platforms they are supported. This table reflects the status as of ns-3.15 and may have changed since then:<br />
<br />
{| border=1 cellspacing=0 cellpadding=3<br />
<br />
|+ Option status<br />
! Option !! Linux !! FreeBSD !! Mac OS X<br />
|-<br />
! Optimized build <br />
| Y || Y || Y<br />
|-<br />
! Python bindings<br />
| Y || Y || Y<br />
|-<br />
! Threading<br />
| Y || Y || Y<br />
|-<br />
! Real-time simulator<br />
| Y || Y || Y<br />
|-<br />
! Emulated Net Device<br />
| Y || N || N<br />
|-<br />
! Tap Bridge<br />
| Y || N || N<br />
|-<br />
! Network simulation cradle<br />
| Y<sup>1</sup> || ? || N<br />
|-<br />
! Static builds<br />
| Y || Y || Y<br />
<br />
|}<br />
<br />
''Key:'' '''Y''' = supported; '''N''' = not supported; '''?''' = unknown; '''dev''' = support in ns-3-dev (next release)<br />
<br />
''Notes:''<br />
<br />
# NSC works best with gcc-3.4 or gcc-4.2 or greater series. Try to avoid using gcc-4.0 and gcc-4.1 series; some build problems have been found with these versions of compilers.<br />
<br />
=== Using older version of ns-3 on newer systems ===<br />
<br />
It can be the case that trying to use an old version of ns-3 on a newer system can lead to warnings or errors because the compilers have become more strict over time. The below wiki page has some suggestions to work around this.<br />
<br />
https://www.nsnam.org/wiki/HOWTO_build_old_versions_of_ns-3_on_newer_compilers<br />
<br />
=== Using newer version of ns-3 on older systems ===<br />
<br />
Conversely, it can be the case that a user has an old version of Linux but newer compilers and libraries are needed to run the latest versions of ns-3. This blog has some recommendations on how to use chroot jails to work around this:<br />
<br />
https://www.projectguideline.com/installing-ns3-35-in-debian-10-chroot-jail-under-debian-11-host-os-or-any-version-of-linux-host/<br />
<br />
== Prerequisites ==<br />
<br />
The core of ns-3 requires a gcc/g++ installation of 4.9 or greater (Linux), or a recent version of clang compiler (OS X, Linux, or BSD), and Python 3.5 or greater. As mentioned above, different options require additional support. This is a list of packages (for Debian/Ubuntu systems) that are needed to support different ns-3 options. Note that other distributions (e.g., Fedora, FreeBSD) may have different package names or capitalization (e.g. ImageMagik). Installation should be similar for Red Hat/Fedora based systems, with "yum" replacing "apt-get", but some differences exist, so below is a guide for both Ubuntu (should generally apply to Debian) and Fedora/RedHat-based systems:<br />
<br />
=== Linux ===<br />
<br />
==== Ubuntu/Debian/Mint ====<br />
<br />
The following list of packages should be accurate through the Ubuntu 22.10 release; other releases or other Debian-based systems may slightly vary. Ubuntu 16.04 LTS release is probably the oldest release that is known to work with the most recent ns-3 releases.<br />
<br />
The list of packages depends on which version of ns-3 you are trying to build.<br />
<br />
* '''minimal requirements for release 3.36 and later:'''<br />
<br />
apt install g++ python3 cmake ninja-build git<br />
<br />
Git is not required if you are only downloading a source archive.<br />
<br />
Ubuntu comes with 'make' build tool, but if you are missing it (possibly on some other Debian-based distribution), you may want to install make or ninja-build. ninja is an alternative to make.<br />
<br />
* '''recommended also for release 3.37 and later:'''<br />
<br />
Ccache is a compiler cache optimization that will speed up builds across multiple ns-3 directories, at the cost of up to an extra 5 GB of disk space used in the cache.<br />
<br />
apt install ccache<br />
<br />
Note: For Ubuntu 20.04 release and earlier, the version of ccache provided by apt (3.7.7 or earlier) may not provide performance benefits, and users are recommended to install version 4 or later, possibly as a source install. For Ubuntu 22.04 and later, ccache can be installed using apt. <br />
<br />
* '''minimal recommended requirements for release 3.30-3.35:'''<br />
<br />
apt install g++ python3<br />
<br />
* '''minimal recommended requirements for release 3.29 and earlier:'''<br />
<br />
apt install g++ python2<br />
<br />
'''Note:''' As of ns-3.30 release (August 2019), ns-3 uses Python 3 by default, but earlier releases depend on Python 2 packages, and at least a Python 2 interpreter is recommended. If working with an earlier release, one may in general substitute 'python' for 'python3' in the below (e.g. install 'python-dev' instead of 'python3-dev').<br />
<br />
'''Note:''' As of January 2022 (ns-3.36 release and ns-3-dev), the minimum g++ version is g++-8. Older Ubuntu releases (18.04, 16.04) come with an older default g++. On Ubuntu 18.04, this StackOverflow answer can be followed to install and prefer g++-8: https://askubuntu.com/a/1028656. On older Ubuntu such as 16.04, to use the most recent code, you must install g++-8 or g++-9 from the Ubuntu toolchain: https://launchpad.net/%7Eubuntu-toolchain-r/+archive/ubuntu/test<br />
<br />
The remaining are needed for '''optional''' ns-3 components.<br />
<br />
* '''minimal requirements for Python visualizer and bindings (ns-3.37 and newer):''' cppyy Python module and Pyviz dependencies<br />
<br />
python3 -m pip install --user cppyy<br />
apt install gir1.2-goocanvas-2.0 python3-gi python3-gi-cairo python3-pygraphviz gir1.2-gtk-3.0 ipython3 <br />
<br />
* '''minimal requirements for Python API users (release 3.30 to ns-3.36):''' This is the minimal set of packages needed to work with Python bindings from a released tarball.<br />
<br />
apt install g++ python3 python3-dev pkg-config sqlite3 cmake<br />
<br />
* '''additional minimal requirements for Python (development):''' For use of ns-3-allinone repository (cloned from Git), additional packages are needed to fetch and successfully install pybindgen and netanim.<br />
<br />
apt install python3-setuptools git<br />
<br />
* '''Netanim animator:''' qt5 development tools are needed for Netanim animator; qt4 will also work but we have migrated to qt5. qt6 compatibility is not tested.<br />
<br />
apt install qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools<br />
<br />
'''Note:''' For Ubuntu 20.10 and earlier, the single 'qt5-default' package suffices<br />
<br />
apt install qt5-default<br />
<br />
* Support for ns-3-pyviz visualizer (release 3.36 and earlier)<br />
<br />
** For Ubuntu 18.04 and later, python-pygoocanvas is no longer provided. The ns-3.29 release and later upgrades the support to GTK+ version 3, and requires these packages:<br />
<br />
apt install gir1.2-goocanvas-2.0 python3-gi python3-gi-cairo python3-pygraphviz gir1.2-gtk-3.0 ipython3 <br />
<br />
** For ns-3.28 and earlier releases, PyViz is based on GTK+ 2, GooCanvas, and GraphViz:<br />
<br />
apt install python-pygraphviz python-kiwi python-pygoocanvas libgoocanvas-dev ipython<br />
<br />
* Support for MPI-based distributed emulation<br />
<br />
apt install openmpi-bin openmpi-common openmpi-doc libopenmpi-dev<br />
<br />
* Support for bake build tool:<br />
<br />
apt install mercurial unzip<br />
<br />
* Debugging:<br />
<br />
apt install gdb valgrind <br />
<br />
* Support for utils/check-style-clang-format.py code style check program (since ns-3.37):<br />
<br />
apt install clang-format<br />
<br />
Note: clang-format-14 through clang-format-16 version is required.<br />
<br />
* Doxygen and related inline documentation:<br />
*:<br />
apt install doxygen graphviz imagemagick<br />
apt install texlive texlive-extra-utils texlive-latex-extra texlive-font-utils dvipng latexmk<br />
*:<br />
** If you get an error such as 'convert ... not authorized source-temp/figures/lena-dual-stripe.eps', see this post about editing ImageMagick's security policy configuration: https://cromwell-intl.com/open-source/pdf-not-authorized.html. In brief, you will want to make this kind of change to ImageMagick security policy:<br />
<br />
--- ImageMagick-6/policy.xml.bak 2020-04-28 21:10:08.564613444 -0700<br />
+++ ImageMagick-6/policy.xml 2020-04-28 21:10:29.413438798 -0700<br />
@@ -87,10 +87,10 @@<br />
<!-- in order to avoid to get image with password text --><br />
<policy domain="path" rights="none" pattern="@*"/><br />
<!-- disable ghostscript format types --><br />
- <policy domain="coder" rights="none" pattern="PS" /><br />
+ <policy domain="coder" rights="read|write" pattern="PS" /><br />
<policy domain="coder" rights="none" pattern="PS2" /><br />
<policy domain="coder" rights="none" pattern="PS3" /><br />
<policy domain="coder" rights="none" pattern="EPS" /><br />
- <policy domain="coder" rights="none" pattern="PDF" /><br />
+ <policy domain="coder" rights="read|write" pattern="PDF" /><br />
<policy domain="coder" rights="none" pattern="XPS" /><br />
</policymap><br />
<br />
<br />
* The ns-3 manual and tutorial are written in reStructuredText for Sphinx (doc/tutorial, doc/manual, doc/models), and figures typically in dia (also needs the texlive packages above):<br />
<br />
apt install python3-sphinx dia <br />
<br />
'''Note:''' Sphinx version >= 1.12 required for ns-3.15. To check your version, type "sphinx-build". To fetch this package alone, outside of the Ubuntu package system, try "sudo easy_install -U Sphinx".<br />
<br />
* GNU Scientific Library (GSL) support for more accurate 802.11b WiFi error models (not needed for OFDM):<br />
<br />
apt install gsl-bin libgsl-dev libgslcblas0<br />
<br />
If the above doesn't work (doesn't detect GSL on the system), consult: https://coral.ise.lehigh.edu/jild13/2016/07/11/hello/. But don't worry if you are not using 802.11b models.<br />
<br />
* To read pcap packet traces<br />
<br />
apt install tcpdump<br />
<br />
* Database support for statistics framework<br />
<br />
apt install sqlite sqlite3 libsqlite3-dev<br />
<br />
* Xml-based version of the config store (requires libxml2 >= version 2.7)<br />
<br />
apt install libxml2 libxml2-dev<br />
<br />
* Support for generating modified python bindings (ns-3.36 and earlier):<br />
<br />
apt install cmake libc6-dev libc6-dev-i386 libclang-dev llvm-dev automake python3-pip<br />
python3 -m pip install --user cxxfilt<br />
<br />
and you will want to install castxml and pygccxml as per the instructions for python bindings (or through the ''bake'' build tool as described in the tutorial). The 'castxml' and 'pygccxml' packages provided by Ubuntu 18.04 and earlier are not recommended; a source build (coordinated via bake) is recommended. If you plan to work with bindings or rescan them for any ns-3 C++ changes you might make, please read the [https://www.nsnam.org/docs/manual/html/python.html chapter in the manual] on this topic.<br />
<br />
'''Note:''' Ubuntu versions (through 19.04) and systems based on it (e.g. Linux Mint 18) default to an old version of clang and llvm (3.8), when simply 'libclang-dev' and 'llvm-dev' are specified. The packaging on these 3.8 versions is broken. Users of Ubuntu will want to explicitly install a newer version by specifying 'libclang-6.0-dev' and 'llvm-6.0-dev'. Other versions newer than 6.0 may work (not tested).<br />
<br />
* A GTK-based configuration system<br />
<br />
apt install libgtk-3-dev<br />
<br />
* To experiment with virtual machines and ns-3<br />
<br />
apt install vtun lxc uml-utilities<br />
<br />
* Support for openflow module (requires libxml2-dev if not installed above) and Boost development libraries<br />
<br />
apt install libxml2 libxml2-dev libboost-all-dev<br />
<br />
[[#Installation| <span class="mw-ui-button mw-ui-progressive" style ="margin:.1em">Jump to installation</span>]]<br />
<br />
==== Fedora/RedHat ====<br />
<br />
Note: This has not been updated for ns-3.37 release yet.<br />
<br />
The following list of packages should be aligned with recent Fedora releases; other releases may slightly vary. Note that these distributions sometimes change the package structure over time.<br />
<br />
'''Important''': If you are using RedHat or CentOS, either versions 6 or 7, the default compilers are too old to build recent ns-3 releases. You must upgrade gcc and g++ to a more recent version. See below.<br />
<br />
<u>Fedora and virtual machines</u><br />
<br />
The Waf build system can use several GB of space on /tmp when building ns-3. Fedora and RedHat have chosen to mount /tmp on tmpfs, sized at half of the RAM by default. On a virtual machine, where possibly as little as 4GB of RAM may be configured, this will lead to a 2GB /tmp partition and the ns-3 build will fail with a message such as:<br />
<br />
src/internet/bindings/ns3module.cc:148895:1: fatal error: error writing to /tmp/ccvdnttM.s: No space left on device<br />
<br />
One workaround is to increase your tmpfs size, such as (as root user):<br />
<br />
# mount -o remount,size=4G,noatime /tmp/<br />
<br />
This resizing must be done upon each reboot, and you should ensure that you have a swap partition also configured.<br />
<br />
<u>Release-specific issues</u><br />
<br />
* We do not support RHEL 6 or CentOS 6 anymore; nor do we support older versions of Fedora such as less than Fedora 30.<br />
<br />
* RHEL 7 (and CentOS 7) use an older version of gcc (4.8.5) that is no longer compatible with ns-3 releases. An upgrade of gcc is needed; see these instructions on installing a devtoolset (such as devtoolset-7) if you need to upgrade: http://blog.stevedoria.net/20180214/how-to-install-gcc-7-on-centos-7<br />
<br />
<u>Required and optional packages</u><br />
<br />
* '''minimal requirements for C++ (release):''' This is the minimal set of packages needed to run most of ns-3's C++ programs from a released tarball.<br />
<br />
dnf install gcc-c++ python3<br />
<br />
* '''minimal requirements for Python (release):''' This is the minimal set of packages needed to use Python bindings from a released tarball.<br />
<br />
dnf install gcc-c++ python3 python3-devel<br />
<br />
* Git is needed to work with ns-3 development repositories.<br />
<br />
dnf install git<br />
<br />
* An optional but recommended package (for improving some wireless model fidelity) is GNU scientific library:<br />
<br />
dnf install gsl gsl-devel<br />
<br />
* Support for netanim animator:<br />
<br />
dnf install qt5-devel<br />
<br />
* A GTK-based configuration system<br />
<br />
<u>Prior to ns-3.29, use GTK+ version 2:</u><br />
<br />
dnf install gtk2 gtk2-devel<br />
<br />
<u>Starting with ns-3.29, use GTK+ version 3:</u><br />
<br />
dnf install gtk3 gtk3-devel<br />
<br />
* Debugging:<br />
<br />
dnf install gdb valgrind <br />
<br />
* Doxygen and related inline documentation:<br />
<br />
dnf install doxygen graphviz ImageMagick<br />
<br />
* The ns-3 manual and tutorial are written in reStructuredText for Sphinx (doc/tutorial, doc/manual, doc/models), and figures typically in dia:<br />
<br />
dnf install python3-sphinx dia texlive texlive-latex texlive-fncychap texlive-capt-of texlive-tabulary texlive-eqparbox<br />
dnf install texlive-epstopdf texlive-titlesec texlive-framed texlive-dvipng texlive-threeparttable texlive-wrapfig texlive-tabulary<br />
dnf install texlive-multirow ImageMagick<br />
<br />
* To read pcap packet traces<br />
<br />
dnf install tcpdump<br />
<br />
* Database support for statistics framework<br />
<br />
dnf install sqlite sqlite-devel<br />
<br />
* Xml-based version of the config store (requires libxml2 >= version 2.7)<br />
<br />
dnf install libxml2 libxml2-devel<br />
<br />
* Support for utils/check-style.py style check program<br />
<br />
dnf install uncrustify<br />
<br />
* Support for MPI distributed simulations<br />
<br />
dnf install openmpi openmpi-devel environment-modules<br />
<br />
Steve Smith notes that the shell must be restarted after environment-modules package is installed, since environment-modules modifies the bash initialization scripts to enable the module command. Then, to find the programs mpic++ and mpiexec, one must do:<br />
<br />
$ module load mpi/openmpi-x86_64<br />
<br />
and then the commands should be found by the shell:<br />
<br />
$ which mpic++ mpiexec<br />
<br />
Steve Smith also noted problems with Fedora machines that do not have APX support, such as virtual machines: https://gitlab.com/nsnam/ns-3-dev/-/issues/397<br />
<br />
Solution for those machines is to switch to mpich:<br />
<br />
$ dnf install mpich mpich-devel environment-modules<br />
$ module load mpi/mpich-x86_64<br />
<br />
* Support for openflowswitch requires libxml2, if not installed above, and Boost development libraries<br />
<br />
dnf install libxml2 libxml2-devel boost-devel<br />
<br />
* Support for ns-3-pyviz visualizer (ns-3.28 release and earlier)<br />
<br />
dnf install redhat-rpm-config goocanvas-devel graphviz graphviz-devel python-setuptools python-kiwi pygoocanvas ipython<br />
easy_install pygraphviz<br />
<br />
* Support for ns-3 pyviz visualizer (ns-3.29 release and later)<br />
<br />
pygobject3-devel python3-gobject gobject-introspection-devel goocanvas2-devel graphviz-devel graphviz ipython<br />
easy_install pygraphviz<br />
<br />
* Support for generating modified python bindings<br />
<br />
dnf install cmake clang-devel llvm-devel llvm-static<br />
pip3 install --user cxxfilt<br />
<br />
and you will want to install castxml and pygccxml as per the instructions for python bindings (or through the ''bake'' build tool as described in the tutorial). If you plan to work with bindings or rescan them for any ns-3 C++ changes you might make, please read the [https://www.nsnam.org/docs/manual/html/python.html chapter in the manual] on this topic.<br />
<br />
* Support for bake tool:<br />
<br />
dnf install make patch autoconf cvs<br />
[[#Installation| <span class="mw-ui-button mw-ui-progressive" style ="margin:.1em">Jump to installation</span>]]<br />
<br />
=== macOS ===<br />
<br />
macOS installation of ns-3 relies on the Xcode command line tools provided by Apple, and the clang/llvm compiler used therein. A third-party package manager such as [https://brew.sh Homebrew] can be used for optional extensions to ns-3 such as libxml2.<br />
<br />
The current version of macOS is 'Catalina' (10.15) and the version of Xcode is 11.2, as of this writing. <br />
<br />
If you are having problems with ns-3.29 and macOS, please look at the [[Errata]] page for some hints, or consider to use the development version (ns-3-dev) of ns-3 which should work now. ns-3.30 is not know to have macOS issues.<br />
<br />
The main steps to follow to prepare your macOS machine for a base ns-3 install (Xcode tools, and Python) are as follows:<br />
<br />
# Download and install Xcode Command Line Tools (most recently tested version 11.2) from the App Store, or the full Xcode.<br />
## If you installed full Xcode, you still need to type `xcode-select --install` to obtain the command line tools.<br />
## You will also have to agree to Apple's license agreement to proceed; type 'sudo clang -v' in a terminal window to take this step.<br />
<br />
At this point, you will likely be able to compile the main C++ libraries. The current macOS Catalina release ships with a basic Python 3 interpreter (version 3.7.3) which is enough to run the Waf build system but not much else. To use Python bindings or other Python features, a fuller install of Python is recommended. Visit https://www.python.org/downloads/mac-osx/ to download a Python 3 release (recommended), or else, if you prefer, use Homebrew or some other package manager to install a Python development environment.<br />
<br />
At this point, you should be able to use ns-3 in C++ or Python programs. The following options are available to add some additional libraries for more ns-3 features. In general, a third-party installer like Homebrew or MacPorts is needed: <br />
# '''Recommended for Mojave users''' (for better Homebrew compatibility), install the legacy headers package found at: /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg. We are not sure whether this is available for Catalina (10.15).<br />
# If you wish to use the NetAnim animator, you must install Qt5 (although Qt4 version also works with current releases).<br />
# If you wish to use mercurial, you must install it. Follow the instruction in the [http://mercurial.selenic.com mercurial web site]. [https://www.macports.org/ MacPorts] and [http://brew.sh/ Homebrew] are possible package managers to accomplish this.<br />
# If you wish to use the GTK-based ConfigStore GUI, we recommend homebrew: if you install Gtk+3 using homebrew, you must install gtk+3. You must install also "adwaita-icon-theme" (not installed by default), or you'll miss elements in the Gtk views<br />
.<br />
'''Note to Anaconda users:''' If you have installed Anaconda, you may encounter a build problem such as:<br />
<br />
"../src/wifi/model/wifi-phy.cc:65:46: error: no matching constructor for initialization of 'WifiPhy::ChannelToFrequencyWidthMap' <br />
(aka 'map<pair<unsigned short, ns3::WifiPhyStandard>, pair<unsigned int, unsigned int> >')<br />
WifiPhy::ChannelToFrequencyWidthMap WifiPhy::m_channelToFrequencyWidth =<br />
^<br />
/usr/include/c++/4.2.1/bits/stl_map.h:188:9: note: candidate constructor template not viable: requires 2 arguments, but 79 were provided<br />
map(_InputIterator __first, _InputIterator __last)<br />
^<br />
This can be worked around by configuring Waf to use the system Python instead of the Python version provided by Anaconda. At the Waf configuration stage, try:<br />
<br />
./waf --python=/usr/bin/python configure ...<br />
<br />
When using build.py, the argument can be passed as follows:<br />
<br />
./build.py --enable-examples --enable-tests -- --python=/usr/bin/python<br />
<br />
See: [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2778 issue 2778] in the ns-3 tracker for more information.<br />
<br />
=== Windows ===<br />
<br />
For Windows 10, there are two main options. Both involve using a Linux environment from within Windows. ns-3 is not compatible with the Windows Visual Studio compiler and IDE (there have been a few efforts to add Visual Studio support, but they have been abandoned).<br />
<br />
#. Install a Linux virtual machine (e.g. using Hyper-V, VMware, etc.).<br />
#. Windows offers a [https://docs.microsoft.com/en-us/windows/wsl/install-win10 Windows subsystem for Linux], providing an Ubuntu-like environment. From within this environment, one can follow the Ubuntu installation guide and obtain most ns-3 features. <br />
<br />
Below is some other older (possibly out-of-date) information regarding Windows:<br />
<br />
* We provide HOWTO documents describing the process for installing Linux and getting ns-3 running using two popular virtualization products: VirtualBox ([[HOWTO use VirtualBox to run simulations on Windows machines]]) and VMware ([[HOWTO use VMware to set up virtual networks (Windows)]]).<br />
* There is an experimental project, [[Ns-3 on Visual Studio 2012 |Ns3 on Windows]], using Visual Studio 2012.<br />
<br />
== Installation ==<br />
<br />
=== Installation with Bake ===<br />
<br />
Bake is a new tool for installing, building and finding out the missing requirements for ns-3 in your own environment. <br />
<br />
To use Bake you need to have at least Python (2.7 or above) and Git in your machine (see the section Prerequisites above to see how to install these). <br />
<br />
First you need to download Bake using Git, go to where you want Bake to be installed and call<br />
<br />
git clone https://gitlab.com/nsnam/bake<br />
<br />
It is advisable to add bake to your path. <br />
<br />
export BAKE_HOME=`pwd`/bake <br />
export PATH=$PATH:$BAKE_HOME<br />
export PYTHONPATH=$PYTHONPATH:$BAKE_HOME<br />
<br />
After that you can use Bake to find the missing packages, download build and install ns-3 and its modules. <br />
<br />
To find out what is missing in your system and may be needed for installing ns-3 you can call bake check:<br />
<br />
bake.py check<br />
<br />
You should have seen something like: <br />
<br />
> Python - OK<br /> > GNU C++ compiler - OK<br /> > Mercurial - OK<br /> > CVS - OK<br /> > GIT - OK<br /> > Bazaar - OK<br /> > Tar tool - OK<br /> > Unzip tool - OK<br /> > Unrar tool - OK<br /> > 7z data compression utility - OK<br /> > XZ data compression utility - OK<br /> > Make - OK<br /> > cMake - OK<br /> > patch tool - OK<br /> > autoreconf tool - OK<br /> > Path searched for tools: /usr/lib64/qt-3.3/bin<br> /usr/lib64/ccache /usr/local/bin /usr/bin/bin/usr/local/sbin /usr/sbin<br> /sbin /user/dcamara/home/scripts/user/dcamara/home/INRIA/Programs/bin <br> /user/dcamara/home/INRIA/repos/llvm/build/Debug+Asserts/bin<br /><br />
<br />
Before downloading and building ns-3 you need to configure bake to inform it which are the modules you want added to ns-3, the standard distribution for example. <br />
<br />
bake.py configure -e ns-3.29<br />
<br />
Then to see the modules it has added, and the specific system requirements for this configuration, you can call bake show: <br />
<br />
<br />
bake.py show <br />
<br />
<br />
To download the modules, build and install you can call bake deploy<br />
<br />
<br />
bake.py deploy<br />
<br />
This will download the selected modules, all their dependencies and build ns-3 with all these independent modules. You can also perform this installation step by step, i.e. by calling download and build in different steps. <br />
<br />
<br />
bake.py download<br />
bake.py build<br />
<br />
=== Manual installation ===<br />
The ns-3 code is available in Mercurial repositories on the server http://code.nsnam.org (look for the latest release e.g., "ns-3.26"). You can download a tarball of the latest release at http://www.nsnam.org/releases or you can work with our repositories using Mercurial. We recommend using Mercurial unless there's a good reason not to (See the end of this section for instructions on how to get a tarball release).<br />
<br />
The simplest way to get started using Mercurial repositories is to use the '''ns-3-allinone''' environment. This is a set of scripts that manages the downloading and building of various subystems of ns-3 for you. We recommend that you begin your ns-3 adventures in this environment as it can really simplify your life at this point.<br />
<br />
==== Downloading ns-3 Using Git ====<br />
<br />
One practice is to create a directory called '''repos''' in one's home directory under which one can keep local Git repositories. If you adopt that approach, you can get a copy of ns-3-allinone by typing the following into your Linux shell (assuming you have installed Git):<br />
<br />
cd<br />
mkdir repos<br />
cd repos<br />
git clone https://gitlab.com/nsnam/ns-3-allinone.git<br />
<br />
As the git command executes, you should see something like the following displayed,<br />
<br />
Cloning into 'ns-3-allinone'...<br />
remote: Enumerating objects: 232, done.<br />
remote: Counting objects: 100% (232/232), done.<br />
remote: Compressing objects: 100% (121/121), done.<br />
remote: Total 232 (delta 135), reused 197 (delta 108)<br />
Receiving objects: 100% (232/232), 99.76 KiB | 513.00 KiB/s, done.<br />
Resolving deltas: 100% (135/135), done.<br />
<br />
After the clone command completes, you should have a directory called ns-3-allinone under your ~/repos directory, the contents of which should look something like the following:<br />
<br />
build.py* constants.py dist.py* download.py* README util.py<br />
<br />
Notice that you really just downloaded some Python scripts and not yet the C++ code. The next step will be to use those scripts to download and build the ns-3 distribution of your choice.<br />
<br />
If you go to the following link: https://gitlab.com/nsnam/ you will see a number of repositories. Many are the private repositories of the ns-3 development team. The repositories of interest to you will be prefixed with '''ns-3'''. Official releases of ns-3 will be numbered as ns-3.release.hotfix. For example, a second hotfix to a still hypothetical release nine of ns-3 would be numbered as ns-3.9.2 on this page.<br />
<br />
The current development snapshot (unreleased) of ns-3 may be found at https://gitlab.com/nsnam/ns-3-dev/. The developers attempt to keep these repository in consistent, working states but they are in a development area with unreleased code present, so you may want to consider staying with an official release if you do not need newly-introduced features.<br />
<br />
You can find the latest version of the code either by inspection of the repository list or by going to the ''Getting Started'' web page and looking for the latest release identifier.<br />
<br />
To download the most recent release (assuming it is ns-3.30 in this case), type the following into your shell (remember you can substitute the name of your chosen release number, or omit specifying it to download the tip of ns-3-dev)<br />
<br />
./download.py -n ns-3.30<br />
<br />
After download process completes, you should have several new directories under ~/repos/ns-3-allinone:<br />
<br />
bake constants.py download.py ns-3.30 __pycache__ util.py<br />
build.py dist.py netanim pybindgen README<br />
<br />
<br />
Go ahead and change into ns-3.30 under your ~/repos/ns-3-allinone directory. You should see something like the following there:<br />
<br />
AUTHORS CONTRIBUTING.md Makefile src utils.py waf-tools<br />
bindings doc README.md test.py VERSION wscript<br />
CHANGES.html examples RELEASE_NOTES testpy.supp waf wutils.py<br />
contrib LICENSE scratch utils waf.bat<br />
<br />
You are now ready to build the ns-3 distribution.<br />
<br />
==== Downloading ns-3 Using a Tarball ====<br />
<br />
The process for downloading ns-3 via tarball is simpler than the Mercurial process since all of the pieces are pre-packaged for you. You just have to pick a release, download it and decompress it.<br />
<br />
As mentioned above, one practice is to create a directory called '''repos''' in one's home directory under which one can keep local Mercurial repositories. One could also keep a tarballs directory. If you adopt the tarballs directory approach, you can get a copy of a release by typing the following into your Linux shell (substitute the appropriate version numbers, of course):<br />
<br />
cd<br />
mkdir tarballs<br />
cd tarballs<br />
wget http://www.nsnam.org/release/ns-allinone-3.30.tar.bz2<br />
tar xjf ns-allinone-3.30.tar.bz2<br />
<br />
If you change into the directory '''ns-allinone-3.30''' you should see a number of files:<br />
<br />
bake constants.py ns-3.30 README<br />
build.py netanim-3.108 pybindgen-0.20.0 util.py<br />
<br />
You are now ready to build the ns-3 distribution.<br />
<br />
== Building ns-3 with build.py ==<br />
<br />
The first time you build the ns-3 project you should build using the allinone environment. This will get the project configured for you<br />
in the most commonly useful way.<br />
<br />
Change into the directory you created in the download section above. If you downloaded using Mercurial you should have a directory called ns-3-allinone under your ~/repos directory. If you downloaded using a tarball you should have a directory called something like ns-allinone-3.13 under your ~/tarballs directory. Type the following:<br />
<br />
./build.py<br />
<br />
You will see lots of typical compiler output messages displayed as the build script builds the various pieces you downloaded. Eventually you should see the following magic words:<br />
<br />
Build finished successfully (00:02:37)<br />
Leaving directory `./ns-3-dev'<br />
<br />
Once the project has built you typically will not use ns-3-allinone scripts. You will now interact directly with Waf and we '''do it in the ns-3-dev directory and not in the ns-3-allinone directory'''.<br />
<br />
=== Configuration with Waf ===<br />
<br />
To see valid configure options, type ./waf --help. The most important option is -d <debug level>. Valid debug levels (which are listed in waf --help) are: "debug" or "optimized". It is also possible to change the flags used for compilation with (e.g.): <br />
<br />
CXXFLAGS="-O3" ./waf configure <br />
<br />
or, alternately, the gcc compiler<br />
<br />
CXX=g++-3.4 ./waf configure<br />
<br />
'''Note:''' Unlike some other build tools, to change the build target, the option must be supplied during the configure stage rather than the build stage (i.e., "./waf -d optimized" will not work; instead, do<br />
<br />
./waf -d optimized configure; ./waf <br />
<br />
The resulting binaries are placed in build/<debuglevel>/srcpath. For example, in a debug build you can find the executable for the first.cc example as build/examples/first. You can debug the executable directly by:<br />
<br />
./waf --shell<br />
cd build/debug/examples<br />
gdb ns-<version>-first-debug<br />
<br />
Of course, you can run gdb in emacs, or use your favorite debugger such as ddd or insight just as easily. In an optimized build you can find the executable for the first.cc example as build/examples/ns-<version>-first-optimized.<br />
<br />
In order to forcibly disable python bindings, you can provide the following option:<br />
<br />
./waf --disable-python configure<br />
<br />
In order to tell the build system to use the sudo program to set the suid bit if required, you can provide the following option:<br />
<br />
./waf --enable-sudo configure<br />
<br />
To start over a configuration from scratch, type:<br />
<br />
./waf distclean<br />
<br />
Or if you get stuck and all else fails:<br />
<br />
rm -rf build<br />
<br />
followed by changing back into ns-3-allinone and doing:<br />
<br />
./build.py<br />
<br />
will basically reset your build state.<br />
<br />
To see all waf options:<br />
<br />
./waf --help<br />
<br />
== Validating ==<br />
<br />
ns-3 has unit tests that can be run to verify the installation:<br />
<br />
./test.py<br />
<br />
which should produce output like:<br />
<pre><br />
PASS: TestSuite histogram<br />
PASS: TestSuite ns3-wifi-interference<br />
PASS: TestSuite ns3-tcp-cwnd<br />
PASS: TestSuite ns3-tcp-interoperability<br />
PASS: TestSuite sample<br />
...<br />
</pre><br />
<br />
== Using Python ==<br />
<br />
See [[NS-3 Python Bindings|this page]].<br />
<br />
== Troubleshooting ==<br />
<br />
See [[Troubleshooting|this page]].<br />
<br />
== Obsolete information ==<br />
Older versions of ns-3, prior to 3.15, supported using cygwin to run on Windows platform.<br />
<br />
=== Windows ===<br />
<br />
There are three basic options for Windows support:<br />
<br />
# We provide HOWTO documents describing the process for installing Linux support and getting ns-3 running using two popular virtualization products: VirtualBox ([[HOWTO use VirtualBox to run simulations on Windows machines]]) and VMware ([[HOWTO use VMware to set up virtual networks (Windows)]]).<br />
# There is an experimental project, [[Ns-3 on Visual Studio 2012 |Ns3 on Windows]], using Visual Studio 2012. For support on Visual Studio 2010 see [[HOWTO use ns-3 on Windows with Visual Studio 2010|ns-3 on Visual Studio 2010]]<br />
# [http://www.cygwin.com Cygwin] has been supported in the past: gcc 3.4.4 (debug only), gcc 4.3.2 (debug and optimized). Note, however, that there are limitations with regard to [[NS-3_Python_Bindings#Cygwin_limitation|Python bindings]], and that Real-time simulator, Emulated Net Device, Tap Bridge and Network simulation cradle are not supported.<br />
<br />
An alternative Windows platform is MinGW. There are maintainers who attempt to keep a subset of ns-3 running on MinGW, but it is not "officially" suppported. This means that bugs filed against MinGW will be addressed as time permits.<br />
<br />
Cygwin can sometimes be problematic due to the way it actually does its emulation, and sometimes interactions with other Windows software can cause problems. If you do use Cygwin or MinGW; and use Logitech products, we will save you quite a bit of heartburn right off the bat and encourage you to take a look at the [http://oldwiki.mingw.org/index.php/FAQ MinGW FAQ].<br />
<br />
Search for "Logitech" and read the FAQ entry, "why does make often crash creating a sh.exe.stackdump file when I try to compile my source code." Believe it or not, the ``Logitech Process Monitor`` insinuates itself into every DLL in the system when it is running. It can cause your Cygwin or MinGW DLLs to die in mysterious ways and often prevents debuggers from running. Beware of Logitech software when using Cygwin.</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022ApplicationTemplate&diff=12508GSOC2022ApplicationTemplate2022-04-17T16:43:19Z<p>Tommaso: </p>
<hr />
<div>{{TOC}}<br />
<br />
<blockquote style="padding: 2em "><br />
<br />
* [[GSOC2022StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''Zulip'' https://ns-3.zulipchat.com<br />
<br />
</blockquote><br />
<br />
= Student Application Template =<br />
<br />
The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google.<br />
<br />
== About You ==<br />
<br />
<blockquote><br />
=== Identity Information ===<br />
* ''Name''. Your name<br />
* ''Email''. Your contact email<br />
* ''Country''. Your country of citizenship<br />
* ''Institution''. Accredited institution where you are enrolled as student (college, university, master program, PhD program, undergraduate program, etc).<br />
* ''Advisor''. (if applicable). Is your research work supervised by a professor or research group? <br />
<br />
=== Patch Requirement ===<br />
Provide a URL to a repository (or pointer to publicly available commits or issues in the tracker) that satisfies your patch requirement for your application to ns-3. Completion of either the suggested patch assignment or a comparable code submission is *mandatory*.<br />
<br />
'''Note:''' If you opt to provide a patch to the problem described in the patch requirement, keep your solution private by pasting the link to your code in your application to Google, not posting it on the mailing list.<br />
<br />
=== Background ===<br />
<br />
==== Education ====<br />
Include your academic or professional background related to data networking, as well as any software experience with C++ and/or Python.<br/><br />
In which school program are you currently enrolled at and what is your specialty there?<br/><br />
When did you begin your current studies?<br />
<br />
==== Work ====<br />
Be sure to denote any work experience you have in relevant areas.<br/><br />
Your past work experience does not need to be a job where you got paid, you can mention any projects you have participated in.<br/><br />
<br />
==== Experience with ns-3 ====<br />
Do you have any experience with ns-3? Do you have any experience working on the ns-3 source code?<br />
<br />
==== Open-source experience ====<br />
Do you have any prior experience working on open-source software?<br />
<br />
==== Research ====<br />
Make sure to denote any research experience you have in relevant areas.<br />
<br />
=== Why you? ===<br />
Why are you the best candidate for the project you're applying for? Why are you interested in it? How does it align with your future plans?<br />
<br />
</blockquote><br />
<br />
== About The Project ==<br />
<br />
<blockquote><br />
=== Project Title, Size, and Summary ===<br />
<br />
Pick an appropriate project title, and try to summarize in one sentence what the project plans to accomplish.<br />
<br />
Highlight if you are applying for a medium sized project (175 hours) or a large project (350 hours).<br />
<br />
=== User-visible changes ===<br />
<br />
Explain what new or repaired capability will be available to users once the project is completed. Be as specific as possible, and describe in terms of what the user will see-- not how it will be implemented. Both a qualitative description of the enhancement and sample C++ or Python API that users would use would be appropriate here.<br/> <br />
What kind of working examples would be provided?<br/><br />
What documentation will need to be written?<br/><br />
<br />
=== Test plan ===<br />
<br />
How will any new code be tested?<br/><br />
What test cases could be written now that would fail (produce incorrect output) but would succeed at the completion of the project?<br/><br />
Are there any performance concerns that must be tested, and how?<br/><br />
How will you guard against user error (misconfiguration)?<br/><br />
How will you convince a skeptic that the implementation works correctly?<br />
<br />
=== Approach ===<br />
What is your technical plan for achieving the goals of the project?<br/><br />
What components and functionality will have to be developed, integrated etc.?<br/><br />
Which development methodology or strategy would you use?<br/><br />
<br />
=== Plan ===<br />
Provide a plan of how the project will be completed within the timeframe of GSoC (175 hours). It may be useful to break this down into three phases of roughly 60 hours each. Try to isolate the project's main features, group them into coherent units, and list them as 'milestones' or 'deliverables'. Make sure you consider the time you will need to document, test, write examples, respond to reviewers comments, and fix your code after every deliverable is finished.<br />
<br />
=== Commitments ===<br />
Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? <br />
</blockquote><br />
<br />
<br />
Of these, the Approach and Plan elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the ns-developers list or Zulip chat and open up a discussion with the ns-3 team or with one of the listed mentors to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. Also understand that the better you plan your project by discussing it on the list, the more clearer your path will seem through the summer. In all our previous editions of GSoC, our strongest and most successful proposals were those which had been discussed at length beforehand on the mailing list and on Zulip.<br />
<br />
In addition, once GSoC proposals have been accepted and reviewed, promising candidates may be invited to virtually meet some of the ns-3 team and discuss their project further in a chat or other online meeting.<br />
<br />
<br />
[[Category:GSoC]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022ContributorGuide&diff=12507GSOC2022ContributorGuide2022-04-17T16:42:27Z<p>Tommaso: /* How to apply */</p>
<hr />
<div>{{TOC}}<br />
<blockquote style="padding: 2em "><br />
<br />
* [[GSOC2022ContributorGuide |ns-3's GSoC contributor guide]]<br />
* [[GSOC2022Projects |GSoC 2022 project ideas page]]<br />
* [[GSOC2022ApplicationTemplate | GSoC contributor application template]]<br />
* [[Summer_Projects | List of past summer projects]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''Chat'' https://ns-3.zulipchat.com<br />
</blockquote><br />
<br />
= Guidelines =<br />
<br />
This webpage highlights the expectations and requirements for applicants for ns-3's Google Summer of Code (GSoC) 2022 effort.<br/><br />
<br />
== Changes for 2022 ==<br />
<br />
Google has announced some [https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html program changes for 2022]. One of the main changes has been opening up the program to non-students. Another one is the more flexible timeline and project size categories.<br />
<br />
In addition, the ns-3 project has clarified three of its own internal GSoC policies:<br />
<br />
1) No more than two students from the same academic institution will be selected.<br />
<br />
2) For student applicants, the primary mentor of a project may not be from the same academic institution as the student, nor otherwise serving in an academic supervisory role for the student. This rule is to avoid the use of GSoC as a means to further an already existing academic project (such projects may span multiple institutions), and to avoid conflicts of interest.<br />
<br />
3) Previous ns-3 GSoC participants may reapply for a second year of GSoC with ns-3; this is allowed by Google's rules. However, new applicants will be preferred over previous applicants, since a main purpose of GSoC is to help bring new participants into the project. Past GSoC participants are encouraged to become mentors rather than repeat contributors.<br />
<br />
== Project Expectations ==<br />
<br />
The ns-3 team is looking for three things from every successful GSoC project:<br />
* Developing code that can be incorporated back into the main codebase, useful to future users.<br />
* Mentoring contributors that will remain part of the team and contribute to the ns-3 effort even *after* GSoC ends. That is, we're looking for long-term contributors and maintainers for the project.<br />
* Providing GSOC contributors with experience and ideas that will be useful to them in their careers.<br />
<br />
== Contributor Expectations ==<br />
<br />
* At the beginning of the program, the contributor will be required to provide a detailed plan of work covering the duration of GSoC. This should be developed with the help of the mentor. Contributors will have to setup a wiki page for their project, and cover important aspects of their proposal's design, the strategy to implement it, a list of deliverables, and lastly, update the wiki page as and when each milestone is achieved. This page along with the code repository allows the community to keep track of the contributor's efforts.<br />
* The contributor will be expected to produce mergeable code (either merged completely at the end of the project, partially at the end of the project, or not merged yet but with no major roadblocks foreseen to merge shortly after the program ends).<br />
* The contributor will be expected to follow ns-3 design guidelines (follow coding style, write tests, documentation).<br />
* Contributors are required to submit weekly reports on the mailing list, covering the progress they've made or the obstacles they've run into. This will help the community keep track of the contributor's efforts, and help as needed.<br />
* The contributor will have his or her code reviewed by the ns-3 community. The reviews will be taken prior to the Google evaluations and will look at issues such as scope, public API, test plan, and open issues. All contributors will be briefed on a checklist of things to prepare for these reviews. Between these reviews, mentors will periodically (at least weekly) review the contributor's output and will provide guidance where needed, and track this progress in a public place such as a wiki entry or the mailing list.<br />
* If a contributor drops the project before the GSoC program ends, is under-performing, or isn't communicating enough with the mentor and development team, he or she will not be passed (will not receive final payment from Google).<br />
<br />
== Expected Background ==<br />
<br />
ns-3 development typically requires proficiency in C++ and a debugger such as gdb or ddd.<br />
It is also required that the contributor knows how to use GIT (at least forks, branches, merge requests), as ns-3 usses git for most of its development.<br />
The valgrind suite of tools, and a system profiler such as oprofile, are typically useful. Python may be necessary for some projects dealing with the build system or that involve using Python to integrate ns-3 with other programs, but is generally an optional component. Domain knowledge of the components pertaining to the project is also expected.<br />
<br />
== Application Development ==<br />
<br />
In years past, many prospective applicants have tried to work privately with a mentor to develop their applications, sending many private PMs and emails. This is understandable because GSoC is a competitive process, but by working this way, the rest of the mentors and the ns-3 community do not have an opportunity to learn about the applicant, and private communication can be considered as possibly an unfair advantage. In an open source project, it is more preferable to work in public as much as possible. Therefore, some mentors may decline to help applicants in private with their application, and only respond to requests in public forums such as Zulip chat or the developers mailing list.<br />
<br />
== The Selection Process ==<br />
<br />
Selection of contributors for GSoC will be competitive. Acceptance ratios are low (typically in the range of 10-25%) and the applications that are selected are very well developed. <br />
<br />
The contributors will be selected by a selection committee which will consist of the candidate mentors. Other mentors can participate in the application development phase and provide input to the final evaluations. Applications will be evaluated and scored according to the following criteria: <br/><br />
<br />
*1) Overall technical quality of application, including whether the project seems feasible and properly scoped, whether the contributor appears knowledgeable about ns-3, C++, the models that are being proposed, sample code submitted, and the project plan including proposed milestones.<br />
*2) Availability of a mentor for the suggested project.<br />
*3) Impact and relevance to future users of ns-3? (e.g. does the proposed project support an active field of research? Are results of the project broadly applicable? Does it bring unique capabilities to ns-3?)<br />
*4) Participation and involvement in the community and with prospective mentors.<br />
<br />
High scoring applicants may be asked to discuss their project details over email or chat. When the evaluation process concludes, the organization administrator will determine the highest ranking applicants and if there are close rankings or concerns, hold a meeting among selection committee members to resolve tiebreakers.<br />
<br />
== Where to begin ==<br />
<br />
Contributors are expected to have worked through [https://www.nsnam.org/docs/release/3.35/tutorial/html/index.html the ns-3 tutorial] and to have read through and executed the code in their areas of interest.<br />
<br />
If you need help with ns-3, you can contact the ns-3 community (either through the mail or Zulip). You can, and indeed you are encouraged to, interact with the ns-3 community as soon as you can, even before the GSoC period,<br />
<br />
The [[GSOC2022Projects | project ideas]] that we list are starting points for contributors to develop further, with help from mentors, but we are not going to provide a specific checklist or plan; that is for applicants to develop. We are also open to ideas not found on the list; if you are excited to work on something specific, let us know and we will give you some feedback on it, and check whether there is someone available to mentor the project.<br />
<br />
The best applications are provided by contributors who have a desire to accomplish specific goals in the project (usually aligned with their own research or interests outside of GSoC), who can articulate an understanding of the issues involved, who get involved with mentors during the application process to help refine the application, and who provide some evidence that they have a reasonable plan and the coding skills to make progress on the goals.<br />
<br />
After you decide which ideas you would like to explore, join the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] or enter the ns-3 room on Zulip chat to discuss ideas with us.<br />
<br />
You are more likely to get help if you ask specific questions that demonstrate that you have tried to make progress on a topic. A question such as "I am interested in ns-3; can you tell me how to begin?", or one that just asks generically about a project idea (e.g. "I am interested in the project idea 'DSR RFC compliance' on the wiki; can you please guide me as to how to begin?") is not likely to generate helpful guidance. A better example of a question more likely to generate good feedback would be something like: "I have read the code in the DSR module, and run the examples, and I have reviewed the RFC. It seems to me that sections X, Y, and Z of the RFC are not aligned with the ns-3 model, and I also found some comments in the code that state that something is not supported yet. Can you give me some feedback about which of these features might be the most useful to prioritize?"<br />
<br />
Please note that all first-time posters to the ns-developers list are moderated to filter out inappropriate posts, so don't be alarmed if your email does not immediately post to the list; it will within 24 hours.<br />
<br />
== How to apply ==<br />
<br />
Contributors apply directly to Google; for more information on how to apply, please look at the [https://summerofcode.withgoogle.com/ Google program site].<br />
<br />
While contributors are encouraged to discuss their technical plans with potential mentors on the ns-developers list, they are under no obligation to share their application details on the list.<br />
<br />
The application format is not fixed. However, we warmly suggest to follow this [https://www.nsnam.org/wiki/GSOC2022ApplicationTemplate Application Template], as it will make it easier to evaluate your proposals.<br />
<br />
== Contributor benefits ==<br />
* GSoC is an excellent opportunity to gain experience working on an open source project.<br />
* Working with the ns-3 project will allow you to improve your networking knowledge, C++ skills and to be in contact with a highly skilled team of developers and user group.<br />
* This is a great opportunity to contribute to our open source community.<br />
<br />
== A piece of advice ==<br />
<br />
Based on the ns-3 team's experiences in the previous Google Summer of Code programmes, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the [http://mailman.isi.edu/mailman/listinfo/ns-developers mailing list] and initiating a discussion of your ideas, it is unlikely that your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, this will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every contributor is expected to communicate regularly with their mentor, announce weekly updates of their projects and participate on the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] and discuss their work over chat.<br />
<br />
= Contributor guidelines =<br />
<br />
These guidelines are for contributors working on ns-3 summer of code projects.<br />
<br />
== Goals ==<br />
<br />
This is a program for you to develop and merge code to ns-3. Your mentors will help guide you through the many steps required to position yourself for a successful final review and merge. While writing code is the main activity, it must be supported by good documentation, good examples, tests, and good communications with the rest of the project.<br />
<br />
== Guidelines for accepted contributors ==<br />
<br />
Here is a brief checklist of things you should try to familiarize yourself with.<br />
<br />
* '''ns-3-users forum.''' Please plan to read this list daily during your project. Please also try, from time to time, to answer questions that you feel comfortable answering. Soon you will have more expertise than many of the people posting questions to this list, and you can start to help share the load of answering questions for new users.<br />
* '''ns-developers mailing list.''' Please plan to read this list daily during your project. This will be the list where you communicate with the developers to get your code reviewed and merged.<br />
* '''wiki.''' Please read through the wiki. Contributions and edits are welcome, to fix stale information or to create new topics.<br />
* '''Test framework.''' Do you know how the test framework works? Can you write your own test code? Please read [http://www.nsnam.org/docs/release/3.35/manual/html/tests.html this documentation].<br />
* '''gdb and valgrind.''' Can you run your code through gdb and valgrind? Can you run your tests through that?<br />
* '''Coding style.''' Do you know how to format your code properly? Do you know how to run the auto-formatting program check-style.py? Have you added Doxygen properly? Please read [http://www.nsnam.org/developers/contributing-code/coding-style/ here].<br />
* '''Code reviews.''' [http://www.nsnam.org/developers/contributing-code/code-reviews/ How to survive ns-3 code reviews].<br />
* '''Emulation.''' Did you know that you can test your code against real implementations (if applicable to your project)? [http://www.nsnam.org/docs/models/html/emulation-overview.html Read more here].<br />
<br />
== Planning ==<br />
<br />
Some advice:<br />
* Refine your plan of what you want to accomplish. The plan should start out slow with some low-risk, easy to accomplish milestones, and work towards harder milestones. It is really important to think and revisit these three issues:<br />
** '''Scope.''' What use cases should your code support, and what is specifically out of scope, when you are done with your project?<br />
** '''Usability.''' How do you expect users to use your code? What kind of API would users find the most natural and easiest to work with? Is it extensible by future developers?<br />
** '''Testing.''' How can you test that your code works as expected? What tests should your code pass when it is done? <br />
* Decompose your project into small mergeable chunks. A good workflow would be to code something new, test it, document it, post for review, and iterate. If you don't accomplish all of your technical goals because you run out of time, make sure that what you have done is mergeable (i.e. it is better to accomplish 50% of your goals, with documentation and testing completed, than 80% or 100% of your goals that does not have good documentation and testing. The latter will not be merged.)<br />
* Commit early, commit often. This will make it easier for your mentors to track your progress.<br />
<br />
[[Category:GSoC]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022ApplicationTemplate&diff=12505GSOC2022ApplicationTemplate2022-04-17T16:41:37Z<p>Tommaso: Tommaso moved page GSOC2022StudentApplicationTemplate to GSOC2022ApplicationTemplate</p>
<hr />
<div>{{TOC}}<br />
<br />
<blockquote style="padding: 2em "><br />
<br />
* [[GSOC2022StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2022StudentApplicationTemplate |GSoC Student application template]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''Zulip'' https://ns-3.zulipchat.com<br />
<br />
</blockquote><br />
<br />
= Student Application Template =<br />
<br />
The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google.<br />
<br />
== About You ==<br />
<br />
<blockquote><br />
=== Identity Information ===<br />
* ''Name''. Your name<br />
* ''Email''. Your contact email<br />
* ''Country''. Your country of citizenship<br />
* ''Institution''. Accredited institution where you are enrolled as student (college, university, master program, PhD program, undergraduate program, etc).<br />
* ''Advisor''. (if applicable). Is your research work supervised by a professor or research group? <br />
<br />
=== Patch Requirement ===<br />
Provide a URL to a repository (or pointer to publicly available commits or issues in the tracker) that satisfies your patch requirement for your application to ns-3. Completion of either the suggested patch assignment or a comparable code submission is *mandatory*.<br />
<br />
'''Note:''' If you opt to provide a patch to the problem described in the patch requirement, keep your solution private by pasting the link to your code in your application to Google, not posting it on the mailing list.<br />
<br />
=== Background ===<br />
<br />
==== Education ====<br />
Include your academic or professional background related to data networking, as well as any software experience with C++ and/or Python.<br/><br />
In which school program are you currently enrolled at and what is your specialty there?<br/><br />
When did you begin your current studies?<br />
<br />
==== Work ====<br />
Be sure to denote any work experience you have in relevant areas.<br/><br />
Your past work experience does not need to be a job where you got paid, you can mention any projects you have participated in.<br/><br />
<br />
==== Experience with ns-3 ====<br />
Do you have any experience with ns-3? Do you have any experience working on the ns-3 source code?<br />
<br />
==== Open-source experience ====<br />
Do you have any prior experience working on open-source software?<br />
<br />
==== Research ====<br />
Make sure to denote any research experience you have in relevant areas.<br />
<br />
=== Why you? ===<br />
Why are you the best candidate for the project you're applying for? Why are you interested in it? How does it align with your future plans?<br />
<br />
</blockquote><br />
<br />
== About The Project ==<br />
<br />
<blockquote><br />
=== Project Title, Size, and Summary ===<br />
<br />
Pick an appropriate project title, and try to summarize in one sentence what the project plans to accomplish.<br />
<br />
Highlight if you are applying for a medium sized project (175 hours) or a large project (350 hours).<br />
<br />
=== User-visible changes ===<br />
<br />
Explain what new or repaired capability will be available to users once the project is completed. Be as specific as possible, and describe in terms of what the user will see-- not how it will be implemented. Both a qualitative description of the enhancement and sample C++ or Python API that users would use would be appropriate here.<br/> <br />
What kind of working examples would be provided?<br/><br />
What documentation will need to be written?<br/><br />
<br />
=== Test plan ===<br />
<br />
How will any new code be tested?<br/><br />
What test cases could be written now that would fail (produce incorrect output) but would succeed at the completion of the project?<br/><br />
Are there any performance concerns that must be tested, and how?<br/><br />
How will you guard against user error (misconfiguration)?<br/><br />
How will you convince a skeptic that the implementation works correctly?<br />
<br />
=== Approach ===<br />
What is your technical plan for achieving the goals of the project?<br/><br />
What components and functionality will have to be developed, integrated etc.?<br/><br />
Which development methodology or strategy would you use?<br/><br />
<br />
=== Plan ===<br />
Provide a plan of how the project will be completed within the timeframe of GSoC (175 hours). It may be useful to break this down into three phases of roughly 60 hours each. Try to isolate the project's main features, group them into coherent units, and list them as 'milestones' or 'deliverables'. Make sure you consider the time you will need to document, test, write examples, respond to reviewers comments, and fix your code after every deliverable is finished.<br />
<br />
=== Commitments ===<br />
Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? <br />
</blockquote><br />
<br />
<br />
Of these, the Approach and Plan elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the ns-developers list or Zulip chat and open up a discussion with the ns-3 team or with one of the listed mentors to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. Also understand that the better you plan your project by discussing it on the list, the more clearer your path will seem through the summer. In all our previous editions of GSoC, our strongest and most successful proposals were those which had been discussed at length beforehand on the mailing list and on Zulip.<br />
<br />
In addition, once GSoC proposals have been accepted and reviewed, promising candidates may be invited to virtually meet some of the ns-3 team and discuss their project further in a chat or other online meeting.<br />
<br />
<br />
[[Category:GSoC]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022StudentApplicationTemplate&diff=12506GSOC2022StudentApplicationTemplate2022-04-17T16:41:37Z<p>Tommaso: Tommaso moved page GSOC2022StudentApplicationTemplate to GSOC2022ApplicationTemplate</p>
<hr />
<div>#REDIRECT [[GSOC2022ApplicationTemplate]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022ApplicationTemplate&diff=12504GSOC2022ApplicationTemplate2022-04-17T09:26:56Z<p>Tommaso: Created page with "{{TOC}} <blockquote style="padding: 2em "> * ns-3's GSoC Student guide * ns-3's GSoC Mentor guide * GSOC2022StudentApplicat..."</p>
<hr />
<div>{{TOC}}<br />
<br />
<blockquote style="padding: 2em "><br />
<br />
* [[GSOC2022StudentGuide |ns-3's GSoC Student guide]]<br />
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br />
* [[GSOC2022StudentApplicationTemplate |GSoC Student application template]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''Zulip'' https://ns-3.zulipchat.com<br />
<br />
</blockquote><br />
<br />
= Student Application Template =<br />
<br />
The following are specific items that the ns-3 team requests GSoC applicants to include in their proposal that is submitted to Google.<br />
<br />
== About You ==<br />
<br />
<blockquote><br />
=== Identity Information ===<br />
* ''Name''. Your name<br />
* ''Email''. Your contact email<br />
* ''Country''. Your country of citizenship<br />
* ''Institution''. Accredited institution where you are enrolled as student (college, university, master program, PhD program, undergraduate program, etc).<br />
* ''Advisor''. (if applicable). Is your research work supervised by a professor or research group? <br />
<br />
=== Patch Requirement ===<br />
Provide a URL to a repository (or pointer to publicly available commits or issues in the tracker) that satisfies your patch requirement for your application to ns-3. Completion of either the suggested patch assignment or a comparable code submission is *mandatory*.<br />
<br />
'''Note:''' If you opt to provide a patch to the problem described in the patch requirement, keep your solution private by pasting the link to your code in your application to Google, not posting it on the mailing list.<br />
<br />
=== Background ===<br />
<br />
==== Education ====<br />
Include your academic or professional background related to data networking, as well as any software experience with C++ and/or Python.<br/><br />
In which school program are you currently enrolled at and what is your specialty there?<br/><br />
When did you begin your current studies?<br />
<br />
==== Work ====<br />
Be sure to denote any work experience you have in relevant areas.<br/><br />
Your past work experience does not need to be a job where you got paid, you can mention any projects you have participated in.<br/><br />
<br />
==== Experience with ns-3 ====<br />
Do you have any experience with ns-3? Do you have any experience working on the ns-3 source code?<br />
<br />
==== Open-source experience ====<br />
Do you have any prior experience working on open-source software?<br />
<br />
==== Research ====<br />
Make sure to denote any research experience you have in relevant areas.<br />
<br />
=== Why you? ===<br />
Why are you the best candidate for the project you're applying for? Why are you interested in it? How does it align with your future plans?<br />
<br />
</blockquote><br />
<br />
== About The Project ==<br />
<br />
<blockquote><br />
=== Project Title, Size, and Summary ===<br />
<br />
Pick an appropriate project title, and try to summarize in one sentence what the project plans to accomplish.<br />
<br />
Highlight if you are applying for a medium sized project (175 hours) or a large project (350 hours).<br />
<br />
=== User-visible changes ===<br />
<br />
Explain what new or repaired capability will be available to users once the project is completed. Be as specific as possible, and describe in terms of what the user will see-- not how it will be implemented. Both a qualitative description of the enhancement and sample C++ or Python API that users would use would be appropriate here.<br/> <br />
What kind of working examples would be provided?<br/><br />
What documentation will need to be written?<br/><br />
<br />
=== Test plan ===<br />
<br />
How will any new code be tested?<br/><br />
What test cases could be written now that would fail (produce incorrect output) but would succeed at the completion of the project?<br/><br />
Are there any performance concerns that must be tested, and how?<br/><br />
How will you guard against user error (misconfiguration)?<br/><br />
How will you convince a skeptic that the implementation works correctly?<br />
<br />
=== Approach ===<br />
What is your technical plan for achieving the goals of the project?<br/><br />
What components and functionality will have to be developed, integrated etc.?<br/><br />
Which development methodology or strategy would you use?<br/><br />
<br />
=== Plan ===<br />
Provide a plan of how the project will be completed within the timeframe of GSoC (175 hours). It may be useful to break this down into three phases of roughly 60 hours each. Try to isolate the project's main features, group them into coherent units, and list them as 'milestones' or 'deliverables'. Make sure you consider the time you will need to document, test, write examples, respond to reviewers comments, and fix your code after every deliverable is finished.<br />
<br />
=== Commitments ===<br />
Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? <br />
</blockquote><br />
<br />
<br />
Of these, the Approach and Plan elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the ns-developers list or Zulip chat and open up a discussion with the ns-3 team or with one of the listed mentors to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. Also understand that the better you plan your project by discussing it on the list, the more clearer your path will seem through the summer. In all our previous editions of GSoC, our strongest and most successful proposals were those which had been discussed at length beforehand on the mailing list and on Zulip.<br />
<br />
In addition, once GSoC proposals have been accepted and reviewed, promising candidates may be invited to virtually meet some of the ns-3 team and discuss their project further in a chat or other online meeting.<br />
<br />
<br />
[[Category:GSoC]]</div>Tommasohttps://www.nsnam.org/mediawiki/index.php?title=GSOC2022ContributorGuide&diff=12503GSOC2022ContributorGuide2022-04-17T09:23:22Z<p>Tommaso: /* How to apply */</p>
<hr />
<div>{{TOC}}<br />
<blockquote style="padding: 2em "><br />
<br />
* [[GSOC2022ContributorGuide |ns-3's GSoC contributor guide]]<br />
* [[GSOC2022Projects |GSoC 2022 project ideas page]]<br />
* [[GSOC2022ApplicationTemplate | GSoC contributor application template]]<br />
* [[Summer_Projects | List of past summer projects]]<br />
* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''Chat'' https://ns-3.zulipchat.com<br />
</blockquote><br />
<br />
= Guidelines =<br />
<br />
This webpage highlights the expectations and requirements for applicants for ns-3's Google Summer of Code (GSoC) 2022 effort.<br/><br />
<br />
== Changes for 2022 ==<br />
<br />
Google has announced some [https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html program changes for 2022]. One of the main changes has been opening up the program to non-students. Another one is the more flexible timeline and project size categories.<br />
<br />
In addition, the ns-3 project has clarified three of its own internal GSoC policies:<br />
<br />
1) No more than two students from the same academic institution will be selected.<br />
<br />
2) For student applicants, the primary mentor of a project may not be from the same academic institution as the student, nor otherwise serving in an academic supervisory role for the student. This rule is to avoid the use of GSoC as a means to further an already existing academic project (such projects may span multiple institutions), and to avoid conflicts of interest.<br />
<br />
3) Previous ns-3 GSoC participants may reapply for a second year of GSoC with ns-3; this is allowed by Google's rules. However, new applicants will be preferred over previous applicants, since a main purpose of GSoC is to help bring new participants into the project. Past GSoC participants are encouraged to become mentors rather than repeat contributors.<br />
<br />
== Project Expectations ==<br />
<br />
The ns-3 team is looking for three things from every successful GSoC project:<br />
* Developing code that can be incorporated back into the main codebase, useful to future users.<br />
* Mentoring contributors that will remain part of the team and contribute to the ns-3 effort even *after* GSoC ends. That is, we're looking for long-term contributors and maintainers for the project.<br />
* Providing GSOC contributors with experience and ideas that will be useful to them in their careers.<br />
<br />
== Contributor Expectations ==<br />
<br />
* At the beginning of the program, the contributor will be required to provide a detailed plan of work covering the duration of GSoC. This should be developed with the help of the mentor. Contributors will have to setup a wiki page for their project, and cover important aspects of their proposal's design, the strategy to implement it, a list of deliverables, and lastly, update the wiki page as and when each milestone is achieved. This page along with the code repository allows the community to keep track of the contributor's efforts.<br />
* The contributor will be expected to produce mergeable code (either merged completely at the end of the project, partially at the end of the project, or not merged yet but with no major roadblocks foreseen to merge shortly after the program ends).<br />
* The contributor will be expected to follow ns-3 design guidelines (follow coding style, write tests, documentation).<br />
* Contributors are required to submit weekly reports on the mailing list, covering the progress they've made or the obstacles they've run into. This will help the community keep track of the contributor's efforts, and help as needed.<br />
* The contributor will have his or her code reviewed by the ns-3 community. The reviews will be taken prior to the Google evaluations and will look at issues such as scope, public API, test plan, and open issues. All contributors will be briefed on a checklist of things to prepare for these reviews. Between these reviews, mentors will periodically (at least weekly) review the contributor's output and will provide guidance where needed, and track this progress in a public place such as a wiki entry or the mailing list.<br />
* If a contributor drops the project before the GSoC program ends, is under-performing, or isn't communicating enough with the mentor and development team, he or she will not be passed (will not receive final payment from Google).<br />
<br />
== Expected Background ==<br />
<br />
ns-3 development typically requires proficiency in C++ and a debugger such as gdb or ddd.<br />
It is also required that the contributor knows how to use GIT (at least forks, branches, merge requests), as ns-3 usses git for most of its development.<br />
The valgrind suite of tools, and a system profiler such as oprofile, are typically useful. Python may be necessary for some projects dealing with the build system or that involve using Python to integrate ns-3 with other programs, but is generally an optional component. Domain knowledge of the components pertaining to the project is also expected.<br />
<br />
== Application Development ==<br />
<br />
In years past, many prospective applicants have tried to work privately with a mentor to develop their applications, sending many private PMs and emails. This is understandable because GSoC is a competitive process, but by working this way, the rest of the mentors and the ns-3 community do not have an opportunity to learn about the applicant, and private communication can be considered as possibly an unfair advantage. In an open source project, it is more preferable to work in public as much as possible. Therefore, some mentors may decline to help applicants in private with their application, and only respond to requests in public forums such as Zulip chat or the developers mailing list.<br />
<br />
== The Selection Process ==<br />
<br />
Selection of contributors for GSoC will be competitive. Acceptance ratios are low (typically in the range of 10-25%) and the applications that are selected are very well developed. <br />
<br />
The contributors will be selected by a selection committee which will consist of the candidate mentors. Other mentors can participate in the application development phase and provide input to the final evaluations. Applications will be evaluated and scored according to the following criteria: <br/><br />
<br />
*1) Overall technical quality of application, including whether the project seems feasible and properly scoped, whether the contributor appears knowledgeable about ns-3, C++, the models that are being proposed, sample code submitted, and the project plan including proposed milestones.<br />
*2) Availability of a mentor for the suggested project.<br />
*3) Impact and relevance to future users of ns-3? (e.g. does the proposed project support an active field of research? Are results of the project broadly applicable? Does it bring unique capabilities to ns-3?)<br />
*4) Participation and involvement in the community and with prospective mentors.<br />
<br />
High scoring applicants may be asked to discuss their project details over email or chat. When the evaluation process concludes, the organization administrator will determine the highest ranking applicants and if there are close rankings or concerns, hold a meeting among selection committee members to resolve tiebreakers.<br />
<br />
== Where to begin ==<br />
<br />
Contributors are expected to have worked through [https://www.nsnam.org/docs/release/3.35/tutorial/html/index.html the ns-3 tutorial] and to have read through and executed the code in their areas of interest.<br />
<br />
If you need help with ns-3, you can contact the ns-3 community (either through the mail or Zulip). You can, and indeed you are encouraged to, interact with the ns-3 community as soon as you can, even before the GSoC period,<br />
<br />
The [[GSOC2022Projects | project ideas]] that we list are starting points for contributors to develop further, with help from mentors, but we are not going to provide a specific checklist or plan; that is for applicants to develop. We are also open to ideas not found on the list; if you are excited to work on something specific, let us know and we will give you some feedback on it, and check whether there is someone available to mentor the project.<br />
<br />
The best applications are provided by contributors who have a desire to accomplish specific goals in the project (usually aligned with their own research or interests outside of GSoC), who can articulate an understanding of the issues involved, who get involved with mentors during the application process to help refine the application, and who provide some evidence that they have a reasonable plan and the coding skills to make progress on the goals.<br />
<br />
After you decide which ideas you would like to explore, join the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] or enter the ns-3 room on Zulip chat to discuss ideas with us.<br />
<br />
You are more likely to get help if you ask specific questions that demonstrate that you have tried to make progress on a topic. A question such as "I am interested in ns-3; can you tell me how to begin?", or one that just asks generically about a project idea (e.g. "I am interested in the project idea 'DSR RFC compliance' on the wiki; can you please guide me as to how to begin?") is not likely to generate helpful guidance. A better example of a question more likely to generate good feedback would be something like: "I have read the code in the DSR module, and run the examples, and I have reviewed the RFC. It seems to me that sections X, Y, and Z of the RFC are not aligned with the ns-3 model, and I also found some comments in the code that state that something is not supported yet. Can you give me some feedback about which of these features might be the most useful to prioritize?"<br />
<br />
Please note that all first-time posters to the ns-developers list are moderated to filter out inappropriate posts, so don't be alarmed if your email does not immediately post to the list; it will within 24 hours.<br />
<br />
== How to apply ==<br />
<br />
Contributors apply directly to Google; for more information on how to apply, please look at the [https://summerofcode.withgoogle.com/ Google program site].<br />
<br />
While contributors are encouraged to discuss their technical plans with potential mentors on the ns-developers list, they are under no obligation to share their application details on the list.<br />
<br />
The application format is not fixed. However, we warmly suggest to follow this [https://www.nsnam.org/wiki/GSOC2022StudentApplicationTemplate Application Template], as it will make it easier to evaluate your proposals.<br />
<br />
== Contributor benefits ==<br />
* GSoC is an excellent opportunity to gain experience working on an open source project.<br />
* Working with the ns-3 project will allow you to improve your networking knowledge, C++ skills and to be in contact with a highly skilled team of developers and user group.<br />
* This is a great opportunity to contribute to our open source community.<br />
<br />
== A piece of advice ==<br />
<br />
Based on the ns-3 team's experiences in the previous Google Summer of Code programmes, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the [http://mailman.isi.edu/mailman/listinfo/ns-developers mailing list] and initiating a discussion of your ideas, it is unlikely that your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, this will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every contributor is expected to communicate regularly with their mentor, announce weekly updates of their projects and participate on the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] and discuss their work over chat.<br />
<br />
= Contributor guidelines =<br />
<br />
These guidelines are for contributors working on ns-3 summer of code projects.<br />
<br />
== Goals ==<br />
<br />
This is a program for you to develop and merge code to ns-3. Your mentors will help guide you through the many steps required to position yourself for a successful final review and merge. While writing code is the main activity, it must be supported by good documentation, good examples, tests, and good communications with the rest of the project.<br />
<br />
== Guidelines for accepted contributors ==<br />
<br />
Here is a brief checklist of things you should try to familiarize yourself with.<br />
<br />
* '''ns-3-users forum.''' Please plan to read this list daily during your project. Please also try, from time to time, to answer questions that you feel comfortable answering. Soon you will have more expertise than many of the people posting questions to this list, and you can start to help share the load of answering questions for new users.<br />
* '''ns-developers mailing list.''' Please plan to read this list daily during your project. This will be the list where you communicate with the developers to get your code reviewed and merged.<br />
* '''wiki.''' Please read through the wiki. Contributions and edits are welcome, to fix stale information or to create new topics.<br />
* '''Test framework.''' Do you know how the test framework works? Can you write your own test code? Please read [http://www.nsnam.org/docs/release/3.35/manual/html/tests.html this documentation].<br />
* '''gdb and valgrind.''' Can you run your code through gdb and valgrind? Can you run your tests through that?<br />
* '''Coding style.''' Do you know how to format your code properly? Do you know how to run the auto-formatting program check-style.py? Have you added Doxygen properly? Please read [http://www.nsnam.org/developers/contributing-code/coding-style/ here].<br />
* '''Code reviews.''' [http://www.nsnam.org/developers/contributing-code/code-reviews/ How to survive ns-3 code reviews].<br />
* '''Emulation.''' Did you know that you can test your code against real implementations (if applicable to your project)? [http://www.nsnam.org/docs/models/html/emulation-overview.html Read more here].<br />
<br />
== Planning ==<br />
<br />
Some advice:<br />
* Refine your plan of what you want to accomplish. The plan should start out slow with some low-risk, easy to accomplish milestones, and work towards harder milestones. It is really important to think and revisit these three issues:<br />
** '''Scope.''' What use cases should your code support, and what is specifically out of scope, when you are done with your project?<br />
** '''Usability.''' How do you expect users to use your code? What kind of API would users find the most natural and easiest to work with? Is it extensible by future developers?<br />
** '''Testing.''' How can you test that your code works as expected? What tests should your code pass when it is done? <br />
* Decompose your project into small mergeable chunks. A good workflow would be to code something new, test it, document it, post for review, and iterate. If you don't accomplish all of your technical goals because you run out of time, make sure that what you have done is mergeable (i.e. it is better to accomplish 50% of your goals, with documentation and testing completed, than 80% or 100% of your goals that does not have good documentation and testing. The latter will not be merged.)<br />
* Commit early, commit often. This will make it easier for your mentors to track your progress.<br />
<br />
[[Category:GSoC]]</div>Tommaso