Difference between revisions of "GSOC2020Projects"

From Nsnam
Jump to: navigation, search
(Project Ideas)
(TCP Prague model for ns-3)
 
(22 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
 
This page contains 2020 Google Summer of Code project ideas for ns-3.  
 
This page contains 2020 Google Summer of Code project ideas for ns-3.  
 
'''Note:''' ns-3 will apply to Google Summer of Code on February 5 and will be notified about acceptance on February 20.'''
 
  
  
 
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
 
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]
* [[GSOC2019StudentGuide |ns-3's 2019 GSoC Student guide]] (will update to 2020 if we are selected)
+
* [[GSOC2020StudentGuide |ns-3's 2020 GSoC Student guide]]
 
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
 
* [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]
* [[GSOC2019StudentApplicationTemplate |2020 GSoC Student application template]] (will update for 2020 if we are selected)
+
* [[GSOC2020StudentApplicationTemplate |2020 GSoC Student application template]]
 
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
 
* [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]
 
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
 
* [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]
Line 97: Line 95:
 
* ''For more information:'' https://www.nsnam.org/docs/dce/manual-quagga/html/getting-started.html
 
* ''For more information:'' https://www.nsnam.org/docs/dce/manual-quagga/html/getting-started.html
  
==== Migrate contributed code to apps ====
+
==== LTE module RRC improvements ====
 +
 
 +
Mentors: [mailto:zali@cttc.es Zoraze Ali], [mailto:tomh@tomh.org Tom Henderson]
 +
 
 +
Fraunhofer ESK previously published extensions to ns-3 LTE, called [https://mailman.isi.edu/pipermail/ns-developers/2018-December/014629.html ELENA], for RRC improvements around radio link failure (RLF) and IDLE mode models.  A portion of this work (the RLF model) was improved and merged to ns-3.30 release by Zoraze Ali, but several features were not included in the mainline; the five missing features are listed in this [https://mailman.isi.edu/pipermail/ns-developers/2019-February/014668.html email to ns-developers list].  Meanwhile, the Fraunhofer team has released [https://gitlab.cc-asp.fraunhofer.de/elena-ns3-lte/elena version 1.1 of ELENA].  This GSoC project will continue to add features from ELENA to ns-3, in the order suggested by Zoraze (and also tracking ELENA 1.1 changes).
 +
 
 +
'' LTE RRC challenge project''
 +
 
 +
As part of the application, an applying student should consider attempting the following exercise.  Currently, the UE PHY layer for RLF detection sends an out-of-sync indication to the UE RRC if it is unable to decode 20 consecutive frames. We suggest trying to generate a patch with the following changes:
 +
 
 +
* Extend the code such that the UE PHY sends an intermediate notification to UE RRC. That is, the UE PHY should send a notification to UE RRC if it is unable to decode 10 consecutive frames.
 +
* The UE RRC, upon receiving this intermediate notification, should send an ideal RRC message to the eNB RRC by including its IMSI. This should work for both Ideal and Real RRC protocol.
 +
* The eNB RRC, upon receiving this notification should fire a new trace, i.e., a new trace source, which would have IMSI as its parameter. The student is free to choose any name for this trace source, e.g., “MidOutOfSync”.
 +
* Implement a trace sink for the above new trace in lena-radio-link-failure.cc example.
 +
 
 +
Hint: Check the Radio link failure section in LTE design documentation.
 +
 
 +
To confirm that it works, write a test, which simulates an LTE EPC scenario with one eNB and one UE. The UE at 0.5 sec jumps 7000 meters away from the eNB (we assume that UE was successfully attached to the eNB). This would trigger the RLF. The goal of the test is to check that at the end of the simulation the “PhySyncDetection” trace with type “Notify out of sync” at UE RRC is triggered exactly after 100 ms (i.e., 10 consecutive frames) of new “MidOutOfSync” trace at the eNB.  The parameters are:
 +
* eNB initial position = 0, 0, 30
 +
* eNB TX power = 43 dBm
 +
* UE initial position = 10, 0, 1.5
 +
* UE TX power = 23 dBm
 +
* Pathloss model = LogDistancePropagationLossModel
 +
** Exponent = 3.9
 +
** Reference Loss = 38.7 dB
 +
** Reference distance = 1 m
 +
* N310 = 1
 +
* N311 = 1
 +
* T310 = 1 sec
 +
* One UDP downlink application with the data rate = 18.6Mbps
 +
     
 +
Hint: See the radio link failure test suite
 +
 
 +
==== App Store improvements ====
 +
 
 +
Mentors: [mailto:abhijithabhayam@gmail.com Abhijith Anilkumar], [mailto:adadeepak8@gmail.com Ankit Deepak]
 +
 
 +
The [https://apps.nsnam.org ns-3 App Store] is a platform to advertise the availability of third-party contributed modules to ns-3.  The maintainers of the app store propose some next steps in its evolution that would be suitable for a GSoC project.
 +
 
 +
1. Develop a CI/CD server that can run tests integrating a new module based on the Bakefile. This will involve checking all dependencies and running the tests and mailing out results.  [https://ns-buildmaster.ee.washington.edu:8010/ Jenkins] is a candidate system for this; we would need this project to develop the scripts and the ability for users to make use of something like Jenkins.  Another candidate system is to reuse GitLab.com CI/CD.
 +
 
 +
2. Have a new Django module in the AppStore that lets developers upload their new apps (can be a Bakefile with link to repository or a Bakefile with tar file). Another feature that we can use is that the developers can be asked to tag a release in GitLab/GitHub so that the corresponding repository can be picked up easily. From here, we trigger the testing on the dedicated server that is present, and fetch the results. From the AppStore side, we display the results and let them know if there are any issues. Once this is done, the developer can "Publish" the module adding necessary documentation. Basically, this remove the manual intervention of verifying whether the module is ready to be published.  Making the AppStore aware of CI/CD lets us have something similar to https://pkg.julialang.org/docs/, where we can showcase the build status and dependencies instead of relying on manual update.
 +
 
 +
3.  A comprehensive app users guide and app developers guide are still to be written; they could be part of this project.
 +
 
 +
4. The AppStore should be made aware of new releases of the mainline, and it can run the Apps against the new versions automatically and see if the module successfully compiles. If it does, it can notify the developer to update the module if necessary. If not, developer can be notified of the current status as well. (Mozilla does this for their add-ons whenever a new version of Firefox is released).
 +
 
 +
* Required Experience: Python, Django
 +
* Bonus Experience: C++
 +
 
 +
==== Migrate contributed code to App Store ====
  
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
Line 105: Line 153:
 
* 802.11ah
 
* 802.11ah
 
* WiGig
 
* WiGig
 +
* Switched Etherent model
 +
* Compound TCP
 
* Others TBD
 
* Others TBD
  
Line 115: Line 165:
 
* How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]
 
* How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]
 
* Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&rep=rep1&type=pdf Yavista]
 
* Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&rep=rep1&type=pdf Yavista]
 +
 +
Students interested in usability, data visualization, and Python should have a close look at the next project idea from Davide Magrin!
 +
 +
==== Improving SEM, a Simulation Execution Manager for ns-3 ====
 +
 +
Mentor: [mailto:magrinda@uw.edu Davide Magrin]
 +
 +
SEM is a Simulation Execution Manager for ns-3 that was developed
 +
during the 2018 Google Summer of Code. The main aim of the software
 +
is to allow users to perform multiple ns-3 simulations, collect
 +
their results and easily plot them. Besides this, SEM also provides
 +
an interface with a popular Sensitivity Analysis library so that
 +
users can gain confidence in the correct behavior of their code, and
 +
has initial (and very experimental) support for the visualization
 +
and exploration of logs. The goal of this project is to expand the
 +
SEM codebase in the latter direction, adding features that will help
 +
users with simulation testing, validation and exploration.
 +
 +
* Required Experience: Python, ns-3
 +
* Bonus Experience: Plotly Dash
 +
* Interests: Simulation best practices, data visualization, databases
 +
* Difficulty: Medium
 +
* Recommended reading:
 +
** SEM presentation paper: https://dl.acm.org/doi/pdf/10.1145/3345768.3355942
 +
** SEM documentation: https://simulationexecutionmanager.rtfd.io
 +
** SEM repository: https://github.com/signetlabdei/sem
  
 
==== User-friendly internet-apps ====
 
==== User-friendly internet-apps ====
Line 139: Line 215:
 
** the links listed above
 
** the links listed above
  
==== NetAnim Python and examples ====
+
==== NetAnim improvements and examples/documentation ====
  
 
Mentors:  [mailto:tomh@tomh.org Tom Henderson]
 
Mentors:  [mailto:tomh@tomh.org Tom Henderson]
  
[[NetAnim]] is an optional animator for ns-3.  It has not been actively developed for a few years.  It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation.  NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use.  Python bindings for the animator are also not supported.  We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim.
+
[[NetAnim]] is an optional animator for ns-3.  It has not been actively developed for a few years.  It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation.  NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use.  We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim.  Beyond documenting and working on new examples, the following ideas could be explored:  1) replace XML traces with JSON traces, for more compact traces, 2) add a mode in which NetAnim received input data from a named pipe during simulation runtime, rather than having to later open and read a trace file.
 +
 
 +
This project idea is a bit loosely defined.  As a result, we have received inquiries seeking more guidance on how to proceed.  Here are some ideas of what we would like to see from an application if it were to be competitive for selection in GSoC 2020.
 +
 
 +
''1) Netanim challenge project''
 +
 
 +
Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so.  For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020).  This type of animation can be created in ns-3 with netanim.  If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee.  The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean).  The animation would show the nodes changing color from healthy to sick to recovered.  Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.
 +
 
 +
[[File:Wash-post.png|500px]] [[File:Netanim-virus.gif]]
 +
 
 +
Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.
 +
 
 +
''2) Open issues''
 +
 
 +
Applicant should review the open issues on our legacy Bugzilla tracker: https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=netanim&query_format=specific
 +
 
 +
and comment on whether the issue might be addressed in the GSoC project.  Applicant can open any new issues discovered on the gitlab.com/nsnam/netanim.git project.
 +
 
 +
Another recently discovered issue is how to allow NetAnim to support the new Wifi physical layer:  https://gitlab.com/nsnam/ns-3-dev/-/issues/127
 +
 
 +
''3) Documentation and examples''
 +
 
 +
The existing netanim documentation is here:  https://www.nsnam.org/docs/release/3.30/models/html/animation.html  and also on wiki pages (https://www.nsnam.org/wiki ; search for the term 'Netanim').  If we were to include a new standalone netanim document, such as we already do for the ns-3 tutorial, what structure/outline would it take?  What parts of netanim presently lack much documentation?
 +
 
 +
Planning also to extend the existing ns-3 tutorial with netanim examples would also be a worthwhile part of a project plan.
 +
 
 +
''4) Enhancements''
 +
 
 +
Applicant can propose to work on some of the above suggested enhancements (like conversion from XML to JSON format).  Explain how Netanim might support parsing of JSON-formatted traces.
  
 
* ''Required Experience:''C++
 
* ''Required Experience:''C++
* ''Recommended Experience:'' Python, Qt
+
* ''Recommended Experience:'' Qt
 
* ''Interests:'' Network visualization/animation
 
* ''Interests:'' Network visualization/animation
 
* ''Difficulty:'' Medium
 
* ''Difficulty:'' Medium
Line 152: Line 256:
 
** https://www.nsnam.org/wiki/NetAnim
 
** https://www.nsnam.org/wiki/NetAnim
 
** https://www.qt.io/what-is-qt/
 
** https://www.qt.io/what-is-qt/
** https://www.nsnam.org/docs/release/3.29/manual/html/python.html#working-with-python-bindings
 
 
==== BPF support ====
 
 
Mentors: [mailto:tomh@tomh.org Tom Henderson]
 
 
[https://lwn.net/ml/netdev/20191214004753.1653075-1-kafai@fb.com/ BPF] is a current networking implementation trend.  What would it take to support BPF programs in ns-3?  What are the use cases of interest?
 
 
* ''Required Experience:''C++, C
 
* ''Recommended Experience:'' BPF, Linux kernel
 
* ''Interests:'' protocol implementation
 
* ''Difficulty:'' Medium to hard?
 
* ''Recommended reading:''
 
** https://lwn.net/Articles/740157/
 
  
 
==== Wi-Fi code refactoring to facilitate integration of other 802.11 based standards  ====
 
==== Wi-Fi code refactoring to facilitate integration of other 802.11 based standards  ====
Line 183: Line 273:
 
802.11ah: https://github.com/imec-idlab/IEEE-802.11ah-ns-3
 
802.11ah: https://github.com/imec-idlab/IEEE-802.11ah-ns-3
  
==== SCE codepoint for ns-3 TCP and Queue Disciplines ====
+
==== SCE AQMs and TCP ====
  
 
Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]
 
Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]
  
Some Congestion Experienced (SCE) is a recently proposed codepoint for Explicit Congestion Notification (ECN). The purpose of SCE codepoint is to deliver an early notification of congestion that is building up in the network devices, prior to delivering Congestion Experienced (CE) codepoint. This project idea is about implementing, testing and documenting SCE codepoint support in ns-3. It requires modifications to TCP model and queue disciplines in ns-3. ECN is already supported in ns-3, so implementing SCE does not require major architectural changes to ns-3 codebase.
+
[https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 Some Congestion Experienced (SCE)] is a recently proposed use of the ECT(1) codepoint for Explicit Congestion Notification (ECN) to deliver earlier notification of congestion than a Congestion Experienced (CE) mark.  This approach is an alternative to using ECT(1) to signal the use of [https://www.ietf.org/id/draft-ietf-tsvwg-l4s-arch-06.txt L4S-based congestion controls].  Simulation models [https://gitlab.com/tomhend/modules/l4s-evaluation already exist] for many of the L4S components. This project idea is about implementing, testing and documenting models to experiment with SCE in ns-3. ECN, CoDel AQM, and FQ-CoDel AQM are already supported in ns-3, so implementing SCE does not require major architectural changes to the ns-3 codebase.  What will be needed are 1) models for an AQM that supports SCE in a shared queue; specifically, [https://tools.ietf.org/html/draft-morton-tsvwg-codel-approx-fair-01 CodelAF], 2) a TCP that responds appropriately to SCE feedback, such as [https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-01 TCP-SCE], and 3) scripts to reproduce comparisons with L4S, such as being able to reproduce results [https://github.com/heistp/sce-l4s-bakeoff found here].
 
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
 
* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
* ''Bonus Experience:'' Familiarity with SCE codepoint.
+
* ''Bonus Experience:'' Familiarity with SCE or L4S.
 
* ''Interests:'' Active Queue Management, Explicit Congestion Notification and TCP.
 
* ''Interests:'' Active Queue Management, Explicit Congestion Notification and TCP.
 
* ''Difficulty:'' Medium to Hard.
 
* ''Difficulty:'' Medium to Hard.
 
* ''Recommended Reading:''
 
* ''Recommended Reading:''
[https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 Internet draft on Some Congestion Experienced]
+
** [https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 Internet draft on Some Congestion Experienced]
[https://github.com/chromi/sce/commits/sce Linux implementation of SCE]
+
** [https://github.com/chromi/sce/commits/sce Linux implementation of SCE]
[https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN implementation in ns-3]
+
** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN implementation in ns-3]
 +
** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-ce-ambiguity-issues.pdf IETF issues list]
 +
** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-some-congestion-experienced.pdf Recent SCE presentation]
 +
** [https://tools.ietf.org/html/draft-morton-tsvwg-codel-approx-fair-01 CNQ-CoDelAF]
 +
** [https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Lightweight FQ]
  
==== Cheap Nasty Queuing (CNQ) and Lightweight Fair Queueing (LFQ) models for ns-3 ====
+
==== TCP Prague model for ns-3 ====
  
Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]
+
Mentor: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]
  
Cheap Nasty Queuing (CNQ) and Lightweight Fair Queueing (LFQ) are recently proposed Internet drafts in IETF. CNQ provides a single-instance Active Queue Management (AQM) and basic sparse-flow prioritisation whereas LFQ is expected to provide throughput fairness, sparse flow prioritization and ordering guarantees while maintaining a small code footprint, low memory requirements, no multiply operations, only two physical queues, and only one set of AQM state. This project idea is about implementing, testing and documenting CNQ and LFQ in ns-3. These algorithms can be combined with Controlled Delay (CoDel) or CoDel BLUE Alternate (COBALT) to verify the correctness of the implementation.
+
TCP Prague is being developed as part of the L4S project. TCP Prague is designed to provide both high throughput and low latency, using more fine-grained congestion control feedback, and it has to coexist with legacy TCP congestion controllers such as TCP Cubic.  Although ns-3 has models for the [https://gitlab.com/tomhend/modules/l4s-evaluation L4S components], to date, we have mostly been using DCTCP as a surrogate.  There are still many research questions for TCP Prague, including whether it can do [https://arxiv.org/abs/1911.00710 RFC 3168 queue detection and fallback], [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-tcp-prague-update.pdf RTT independence], how to [https://github.com/JoakimMisund/PacedChirping pace out packets], integrating [https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 TCP RACK] with it, how it may respond to packet aggregation in the network, and how it can perform across a range of coexistence scenarios.  Joakim Misund has already started a [https://gitlab.com/JoakimMisund/l4s-evaluation/tree/tcp-prague TCP Prague implementation for ns-3]. This GSoC project would work to develop TCP Prague further and compare it against the Linux implementation, implementing the features that are not yet done such as RFC 3168 queue detection.
* ''Required Experience:'' Familiarity with queue disciplines and C++ programming.
+
* ''Required Experience:'' Familiarity with C++ and TCP
* ''Bonus Experience:'' Familiarity with CNQ and LFQ.
+
* ''Bonus Experience:'' Familiarity with L4S.
* ''Interests:'' Packet Scheduling algorithms
+
 
* ''Difficulty:'' Medium to Hard.
 
* ''Difficulty:'' Medium to Hard.
* ''Recommended Reading:''
+
* ''Recommended Reading:'' see the inline links above, plus:
[https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-01 Internet draft on CNQ]
+
** NetDev 0x13 talk on [https://www.youtube.com/watch?v=GyXwvRKW0QE TCP Prague requirements]
[https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Internet draft on LFQ]
+
** NetDev 0x13 talk on [https://www.youtube.com/watch?v=UCUtudQ33Pc Paced Chirping]
[https://github.com/chromi/sce/commits/sce Linux implementation of CNQ]
+
** The Linux implementation is maintained at:  https://github.com/L4STeam/linux
[https://github.com/chromi/sce/commits/sce Linux implementation of LFQ]
+
** This recent talk at the IETF contains latest status:  https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-tcp-prague-update.pdf
[https://www.nsnam.org/docs/models/html/queue-discs.html Queue Disciplines in ns-3]
+
  
==== Google’s BBRv2 congestion control algorithm for ns-3 TCP ====
+
==== NetDevice up/down consistency and event chain ====
  
Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]
+
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], Manoj Kumar Rana
  
BBRv2 is an enhanced version of BBR (Bottleneck Bandwidth and RTT), both developed at Google. BBRv2 overcomes the limitations of BBR, such as: no response to packet loss, no response to ECN (Explicit Congestion Notification) and unfairness while coexisting with traditional TCP variants (e.g., CUBIC). A BBR model has been developed for ns-3 but is currently out of the mainline. This project is about merging the available implementation of BBR and subsequently implementing, testing and documenting BBRv2 in ns-3.
+
There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost).
* ''Required Experience:'' Familiarity with BBR and BBRv2
+
This prevents some "normal" behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc.
* ''Bonus Experience:'' Familiarity with CNQ and LFQ.
+
As a matter offact, one should expect that an IP interface would be declared as "down" when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way.  
* ''Interests:'' TCP Congestion Control
+
* ''Required Experience:'' C++, NetDevices, Interface behavior
* ''Difficulty:'' Medium to Hard.
+
* ''Bonus Experience:'' NetDevice and IP behavior
* ''Recommended Reading:''
+
* ''Interests:'' NetDevice and IP behavior
[https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-01 Internet draft on BBR]
+
* ''Difficulty:'' medium
[https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-an-update-on-bbr-00 IETF Presentation about BBRv2]
+
 
[https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr.c Linux implementation of BBR]
+
==== 802.15.4 Bootstrap ====
[https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c Linux implementation of BBRv2]
+
 
[https://www.nsnam.org/docs/models/html/tcp.html TCP models in ns-3]
+
Mentors: [mailto:shattered.feelings@gmail.com Alberto Gallegos Ramonet], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
[https://github.com/Vivek-anand-jain/Reproduce-TCP-BBR-in-ns-3 BBR implementation in ns-3]
+
 
 +
The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.
 +
* ''Required Experience:'' C++, WSN
 +
* ''Bonus Experience:'' 802.15.4 standard
 +
* ''Interests:'' WSN
 +
* ''Difficulty:'' medium
 +
* ''Recommended reading:''
 +
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 +
 
 +
==== 802.15.4 Beacon-enabled mode ====
 +
 
 +
Mentors: [mailto:shattered.feelings@gmail.com Alberto Gallegos Ramonet], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 +
 
 +
The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module.
 +
* ''Required Experience:'' C++, WSN
 +
* ''Bonus Experience:'' 802.15.4 standard
 +
* ''Interests:'' WSN
 +
* ''Difficulty:'' medium/hard
 +
* ''Recommended reading:''
 +
** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]
 +
 
 +
==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====
 +
 
 +
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]
 +
 
 +
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 and DSR. 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.
 +
An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.
 +
Note:  Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address.  The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007).  Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'
 +
 
 +
* ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.
 +
* ''Bonus Experience:'' Familiarity with AODV and DSR implementations in ns-3
 +
* ''Interests:'' Ad hoc routing
 +
* ''Difficulty:'' Medium.
 +
* ''Recommended reading:''
 +
** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]
 +
** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]
 +
** [https://www.nsnam.org/docs/models/html/dsr.html DSR model in ns-3]
 +
** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]
 +
 
 +
==== IoT and WSN devices: RPL implementation ====
 +
 
 +
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 +
 
 +
The RPL protocol is ''the'' routing protocol for Wireless Sensor Networks using low-power, contained, multi-hop devices. It is based on IPv6 and, more than a protocol, it could be classified as a routing protocol framework. The actual protocol is defined through a series of RFC that can be found at the [https://datatracker.ietf.org/wg/roll/documents/ ROLL IETF Working Group].
 +
 
 +
The actual RPL implementation is quite outdated, and suffers from a number of questionable assumptions that, over the time, have shown their limits. This implementation is not public, but it have been used by a restricted number of testers.
 +
 
 +
The goal of this project is to analyze the current RPL implementation code, and:
 +
#  Remove some limitations of the actual implementation
 +
# Write the documentation
 +
# Develop the unit test and examples
 +
# Merge the code.
 +
 
 +
A welcome, albeit not strictly necessary, thing would be to implement the recently approved RFC extensions to RPL.
 +
 
 +
* ''Required Experience:'' Familiarity with routing and IPv6.
 +
* ''Bonus Experience:'' Familiarity RPL.
 +
* ''Difficulty:'' Medium-Hard
 +
 
 +
==== Path MTU Discovery (PMTUD) implementation and TCP/UDP adaptive packet size ====
 +
 
 +
Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]
 +
 
 +
Right now ns-3 does not have a "full" implementation of PMTUD. IPv6 does implement it through ICMPs, but IPv4 is lacking it altogether.
 +
This causes several inconveniences in complex network setups, where each link can have different MTUs. Practically speaking, packets could be either fragmented (in IPv4) or dropped (in IPv6).
 +
 
 +
The goal of this project is to implement RFC 1191 and (optionally) RFC 4821. Once the necessary APIs are available, the project should focus on:
 +
# Provide an UDP API to "inform" the application layer of PMTU changes, and
 +
# Modify the actual TCP implementation so to use dynamic segment sizes.
 +
 
 +
Note that, while the UDP changes are relatively straightforward, the TCP changes might be challenging.
 +
 
 +
* ''Required Experience:'' Familiarity with IPv4 and IPv6, and in particular with fragmentation.
 +
* ''Bonus Experience:'' Familiarity RPL.
 +
* ''Difficulty:'' Medium
 +
* ''Recommended reading:''
 +
** [https://en.wikipedia.org/wiki/Path_MTU_Discovery Wikipedia: Path MTU Discovery]
 +
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2064 UdpSocket::GetMtu() needed]
 +
** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1751 TCP should react to MTU changes]
 +
** [https://tools.ietf.org/html/rfc1191 RFC 1191]
 +
** [https://tools.ietf.org/html/rfc4821 RFC 4821]
  
 
[[Category:GSoC]]
 
[[Category:GSoC]]

Latest revision as of 20:45, 24 March 2020

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

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

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


About the ns-3 project

ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.

Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.

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

Org admins

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

Mentors

Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2020, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.

The current list of prospective mentors for 2020 is below:

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

Students: how to participate

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

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

Below is a list of #Project Ideas proposed by the ns-3 team for Google Summer of Code 2020. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the ns-developers list if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the ns-developers list. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.

Each project idea within a particular priority has been tagged with the following properties:

  • Required Experience: Languages, concepts, or packages with which applicants must be familiar.
  • Bonus Experience: Other experience or familiarity which would be greatly helpful to applicants for this project.
  • Interests: Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
  • Difficulty: easy, medium or difficult
  • Recommended reading: pointers to documentation, papers, specific bugs, etc.

Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard. A few projects are more Python-centric.

Mentors: how to participate

The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:

  • The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.
  • The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.
  • There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.

Project Ideas

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

Direct Code Execution upgrade

Mentor: Tom Henderson, others TBD

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

DCE quagga improvements

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

Mentor: Tom Henderson

LTE module RRC improvements

Mentors: Zoraze Ali, Tom Henderson

Fraunhofer ESK previously published extensions to ns-3 LTE, called ELENA, for RRC improvements around radio link failure (RLF) and IDLE mode models. A portion of this work (the RLF model) was improved and merged to ns-3.30 release by Zoraze Ali, but several features were not included in the mainline; the five missing features are listed in this email to ns-developers list. Meanwhile, the Fraunhofer team has released version 1.1 of ELENA. This GSoC project will continue to add features from ELENA to ns-3, in the order suggested by Zoraze (and also tracking ELENA 1.1 changes).

LTE RRC challenge project

As part of the application, an applying student should consider attempting the following exercise. Currently, the UE PHY layer for RLF detection sends an out-of-sync indication to the UE RRC if it is unable to decode 20 consecutive frames. We suggest trying to generate a patch with the following changes:

  • Extend the code such that the UE PHY sends an intermediate notification to UE RRC. That is, the UE PHY should send a notification to UE RRC if it is unable to decode 10 consecutive frames.
  • The UE RRC, upon receiving this intermediate notification, should send an ideal RRC message to the eNB RRC by including its IMSI. This should work for both Ideal and Real RRC protocol.
  • The eNB RRC, upon receiving this notification should fire a new trace, i.e., a new trace source, which would have IMSI as its parameter. The student is free to choose any name for this trace source, e.g., “MidOutOfSync”.
  • Implement a trace sink for the above new trace in lena-radio-link-failure.cc example.

Hint: Check the Radio link failure section in LTE design documentation.

To confirm that it works, write a test, which simulates an LTE EPC scenario with one eNB and one UE. The UE at 0.5 sec jumps 7000 meters away from the eNB (we assume that UE was successfully attached to the eNB). This would trigger the RLF. The goal of the test is to check that at the end of the simulation the “PhySyncDetection” trace with type “Notify out of sync” at UE RRC is triggered exactly after 100 ms (i.e., 10 consecutive frames) of new “MidOutOfSync” trace at the eNB. The parameters are:

  • eNB initial position = 0, 0, 30
  • eNB TX power = 43 dBm
  • UE initial position = 10, 0, 1.5
  • UE TX power = 23 dBm
  • Pathloss model = LogDistancePropagationLossModel
    • Exponent = 3.9
    • Reference Loss = 38.7 dB
    • Reference distance = 1 m
  • N310 = 1
  • N311 = 1
  • T310 = 1 sec
  • One UDP downlink application with the data rate = 18.6Mbps

Hint: See the radio link failure test suite

App Store improvements

Mentors: Abhijith Anilkumar, Ankit Deepak

The ns-3 App Store is a platform to advertise the availability of third-party contributed modules to ns-3. The maintainers of the app store propose some next steps in its evolution that would be suitable for a GSoC project.

1. Develop a CI/CD server that can run tests integrating a new module based on the Bakefile. This will involve checking all dependencies and running the tests and mailing out results. Jenkins is a candidate system for this; we would need this project to develop the scripts and the ability for users to make use of something like Jenkins. Another candidate system is to reuse GitLab.com CI/CD.

2. Have a new Django module in the AppStore that lets developers upload their new apps (can be a Bakefile with link to repository or a Bakefile with tar file). Another feature that we can use is that the developers can be asked to tag a release in GitLab/GitHub so that the corresponding repository can be picked up easily. From here, we trigger the testing on the dedicated server that is present, and fetch the results. From the AppStore side, we display the results and let them know if there are any issues. Once this is done, the developer can "Publish" the module adding necessary documentation. Basically, this remove the manual intervention of verifying whether the module is ready to be published. Making the AppStore aware of CI/CD lets us have something similar to https://pkg.julialang.org/docs/, where we can showcase the build status and dependencies instead of relying on manual update.

3. A comprehensive app users guide and app developers guide are still to be written; they could be part of this project.

4. The AppStore should be made aware of new releases of the mainline, and it can run the Apps against the new versions automatically and see if the module successfully compiles. If it does, it can notify the developer to update the module if necessary. If not, developer can be notified of the current status as well. (Mozilla does this for their add-ons whenever a new version of Firefox is released).

  • Required Experience: Python, Django
  • Bonus Experience: C++

Migrate contributed code to App Store

Mentors: Tom Henderson

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

  • Simple wireless
  • 802.11ah
  • WiGig
  • Switched Etherent model
  • Compound TCP
  • Others TBD

Usability improvements

Mentors: Tom Henderson, others TBD

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

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

Students interested in usability, data visualization, and Python should have a close look at the next project idea from Davide Magrin!

Improving SEM, a Simulation Execution Manager for ns-3

Mentor: Davide Magrin

SEM is a Simulation Execution Manager for ns-3 that was developed during the 2018 Google Summer of Code. The main aim of the software is to allow users to perform multiple ns-3 simulations, collect their results and easily plot them. Besides this, SEM also provides an interface with a popular Sensitivity Analysis library so that users can gain confidence in the correct behavior of their code, and has initial (and very experimental) support for the visualization and exploration of logs. The goal of this project is to expand the SEM codebase in the latter direction, adding features that will help users with simulation testing, validation and exploration.

User-friendly internet-apps

Mentors: Tom Henderson

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

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

nam upgrade and support for ns-3

Mentors: Tom Henderson

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

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

NetAnim improvements and examples/documentation

Mentors: Tom Henderson

NetAnim is an optional animator for ns-3. It has not been actively developed for a few years. It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation. NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use. We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim. Beyond documenting and working on new examples, the following ideas could be explored: 1) replace XML traces with JSON traces, for more compact traces, 2) add a mode in which NetAnim received input data from a named pipe during simulation runtime, rather than having to later open and read a trace file.

This project idea is a bit loosely defined. As a result, we have received inquiries seeking more guidance on how to proceed. Here are some ideas of what we would like to see from an application if it were to be competitive for selection in GSoC 2020.

1) Netanim challenge project

Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.

Wash-post.png Netanim-virus.gif

Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.

2) Open issues

Applicant should review the open issues on our legacy Bugzilla tracker: https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=netanim&query_format=specific

and comment on whether the issue might be addressed in the GSoC project. Applicant can open any new issues discovered on the gitlab.com/nsnam/netanim.git project.

Another recently discovered issue is how to allow NetAnim to support the new Wifi physical layer: https://gitlab.com/nsnam/ns-3-dev/-/issues/127

3) Documentation and examples

The existing netanim documentation is here: https://www.nsnam.org/docs/release/3.30/models/html/animation.html and also on wiki pages (https://www.nsnam.org/wiki ; search for the term 'Netanim'). If we were to include a new standalone netanim document, such as we already do for the ns-3 tutorial, what structure/outline would it take? What parts of netanim presently lack much documentation?

Planning also to extend the existing ns-3 tutorial with netanim examples would also be a worthwhile part of a project plan.

4) Enhancements

Applicant can propose to work on some of the above suggested enhancements (like conversion from XML to JSON format). Explain how Netanim might support parsing of JSON-formatted traces.

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

Mentors: Sébastien Deronne Hany Assasa

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

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

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

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

SCE AQMs and TCP

Mentor: Mohit P. Tahiliani, Tom Henderson

Some Congestion Experienced (SCE) is a recently proposed use of the ECT(1) codepoint for Explicit Congestion Notification (ECN) to deliver earlier notification of congestion than a Congestion Experienced (CE) mark. This approach is an alternative to using ECT(1) to signal the use of L4S-based congestion controls. Simulation models already exist for many of the L4S components. This project idea is about implementing, testing and documenting models to experiment with SCE in ns-3. ECN, CoDel AQM, and FQ-CoDel AQM are already supported in ns-3, so implementing SCE does not require major architectural changes to the ns-3 codebase. What will be needed are 1) models for an AQM that supports SCE in a shared queue; specifically, CodelAF, 2) a TCP that responds appropriately to SCE feedback, such as TCP-SCE, and 3) scripts to reproduce comparisons with L4S, such as being able to reproduce results found here.

TCP Prague model for ns-3

Mentor: Tom Henderson, Mohit P. Tahiliani

TCP Prague is being developed as part of the L4S project. TCP Prague is designed to provide both high throughput and low latency, using more fine-grained congestion control feedback, and it has to coexist with legacy TCP congestion controllers such as TCP Cubic. Although ns-3 has models for the L4S components, to date, we have mostly been using DCTCP as a surrogate. There are still many research questions for TCP Prague, including whether it can do RFC 3168 queue detection and fallback, RTT independence, how to pace out packets, integrating TCP RACK with it, how it may respond to packet aggregation in the network, and how it can perform across a range of coexistence scenarios. Joakim Misund has already started a TCP Prague implementation for ns-3. This GSoC project would work to develop TCP Prague further and compare it against the Linux implementation, implementing the features that are not yet done such as RFC 3168 queue detection.

NetDevice up/down consistency and event chain

Mentors: Tommaso Pecorella, Manoj Kumar Rana

There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost). This prevents some "normal" behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc. As a matter offact, one should expect that an IP interface would be declared as "down" when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way.

  • Required Experience: C++, NetDevices, Interface behavior
  • Bonus Experience: NetDevice and IP behavior
  • Interests: NetDevice and IP behavior
  • Difficulty: medium

802.15.4 Bootstrap

Mentors: Alberto Gallegos Ramonet, Tommaso Pecorella

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

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

802.15.4 Beacon-enabled mode

Mentors: Alberto Gallegos Ramonet, Tommaso Pecorella

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

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

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

Mentors: Tommaso Pecorella, Mohit P. Tahiliani

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 and DSR. 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. An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts. Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'

IoT and WSN devices: RPL implementation

Mentors: Tommaso Pecorella

The RPL protocol is the routing protocol for Wireless Sensor Networks using low-power, contained, multi-hop devices. It is based on IPv6 and, more than a protocol, it could be classified as a routing protocol framework. The actual protocol is defined through a series of RFC that can be found at the ROLL IETF Working Group.

The actual RPL implementation is quite outdated, and suffers from a number of questionable assumptions that, over the time, have shown their limits. This implementation is not public, but it have been used by a restricted number of testers.

The goal of this project is to analyze the current RPL implementation code, and:

  1. Remove some limitations of the actual implementation
  2.  Write the documentation
  3.  Develop the unit test and examples
  4. Merge the code.

A welcome, albeit not strictly necessary, thing would be to implement the recently approved RFC extensions to RPL.

  • Required Experience: Familiarity with routing and IPv6.
  • Bonus Experience: Familiarity RPL.
  • Difficulty: Medium-Hard

Path MTU Discovery (PMTUD) implementation and TCP/UDP adaptive packet size

Mentors: Tommaso Pecorella

Right now ns-3 does not have a "full" implementation of PMTUD. IPv6 does implement it through ICMPs, but IPv4 is lacking it altogether. This causes several inconveniences in complex network setups, where each link can have different MTUs. Practically speaking, packets could be either fragmented (in IPv4) or dropped (in IPv6).

The goal of this project is to implement RFC 1191 and (optionally) RFC 4821. Once the necessary APIs are available, the project should focus on:

  1. Provide an UDP API to "inform" the application layer of PMTU changes, and
  2. Modify the actual TCP implementation so to use dynamic segment sizes.

Note that, while the UDP changes are relatively straightforward, the TCP changes might be challenging.