Difference between revisions of "GSOC2021NixVectorFinalReport"

From Nsnam
Jump to: navigation, search
m
Line 52: Line 52:
 
=== Pre-coding phase setup ===
 
=== Pre-coding phase setup ===
  
For refactoring the existing IPv4 Nix-Vector routing code, an initial set of tests is required to make sure that we don’t change the existing behavior of the current (working) IPv4 code. There was no test suite written for IPv4 Nix routing, so we decided to write one before the start of the Coding Phase.
+
For refactoring the existing IPv4 Nix-Vector routing code, an initial set of tests was required to make sure that we don’t change the existing behavior of the working IPv4 code. There was no test suite written for IPv4 Nix routing, so we decided to write one before the start of the Coding Phase.
  
 
Nix Tests Merge Request: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/640 [4]]
 
Nix Tests Merge Request: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/640 [4]]

Revision as of 18:08, 19 August 2021

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

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

Back to GSoC 2021 projects

Project Overview

The project is about implementing an IPv6 Nix-Vector routing protocol with minimal code duplication. The project involved coming up with a strategy to refactor and reuse the existing IPv4 Nix-Vector routing code. Nix routing is not a “real” routing protocol but is fast and helpful while working with huge topologies. This work also forms a basis for adding the support for other IPv4 routing protocols in ns-3, especially Global routing, as it is similar to Nix-Vector routing in some aspects.

Merge Requests, Commits, and Project Details

We maintained a single branch for all the GSoC work, named gsoc-21.

Project Wiki Page: GSOC2021NixVector

Proposal: link

To create a Merge Request, I picked the particular set of related commits from gsoc-21, applied them on another master-derived branch, and then made an MR.

Merge Requests
No. Name Status Commit
[1] internet: Make similar functions in IPv4 and IPv6 consistent with naming Merged 3294de14
[2] nix-vector-routing: template-based Nix-Vector Routing - IPv4 and IPv6 compliant. Merged a80d4c95
[3] nix-vector-routing: Update doc on IPv6, examples and usage Merged ec05adaa
[4] nix-vector-routing: tests Merged 972413ce
[5] nix-vector-routing: Update CHANGES.html and RELEASE_NOTES Open
[6] nix-vector-routing: Handle Multiple Wifi connections with same channel object Open

Community Bonding Period

Discuss the plan and actions

During this period, we had decided on how to work on the project. Below are some of the things we did for this:

  • Fix a weekly video call meeting for discussions and doubts.
  • Discuss the ideas mentioned in the proposal and how they should be organized into different Merge Requests.
  • Maintain a single gsoc-21 for all the work to be done during the Coding period.
  • Plan a weekly project update, sent to the ns-developers mailing list.
  • Layout a Design Documentation for the project.

Pre-coding phase setup

For refactoring the existing IPv4 Nix-Vector routing code, an initial set of tests was required to make sure that we don’t change the existing behavior of the working IPv4 code. There was no test suite written for IPv4 Nix routing, so we decided to write one before the start of the Coding Phase.

Nix Tests Merge Request: [4]

The above MR was created during the Community Bonding Period itself. The IPv4 Nix-Vector routing test suite was added during this period. Later, we decided to use the same MR for even the IPv6 tests.

Another thing was that the proposal made heavy usage of C++ templates, aliases, and some constructs from C++11 and14. So, a concern was if the Python Bindings will be generated without any issues. So, I did the Python Bindings setup for rescanning nix-vector-routing in this period itself.

Phase 1

I started refactoring the IPv4 and added the initial template code to the existing code during this period. Later, we initialized the template classes with the corresponding IPv6 class parameters and started making suitable changes for IPv6. We faced some routing issues during this period, but they got resolved in a week or two. Apart from that, we also modified the existing example topology for IPv6 Nix-Vector routing and updated the documentation for Nix.

MRs submitted during this phase: [1], [2], [3] and [4].

Phase 2 (Final Phase)

During Phase 2, I worked on all the comments and suggestions provided by the mentors and reviewers on the first 4 MRs. Along with this, we started working on a new feature i.e., add support for Nix-Vector routing with topologies having more than one WiFi network using the same WiFi channel object.

MRs submitted during this phase: [5] and [6]

Proposal vs. Actual Work

We followed the GSoC proposal mainly throughout the project. We made a few changes with respect to code optimization, consistency, code maintainability, documentation, etc. These changes were made as we carried out the implementation. But overall, the idea proposed in the GSoC proposal remained the same.

The proposal kept some room for changes and potential blockers to the proposed implementation. For example, we didn’t know if the proposed modifications will work with the Python Bindings Generator, and when Tom Henderson pointed it out, I made a note of it in the proposal. However, the ideas mentioned worked out, and we didn’t have to change our implementation strategy.

We completed the proposed work before the timeline and moved on to a new feature.

My Experience

Acknowledgment

I would like to thank all the mentors and ns-3 developers for helping me with my doubts and difficulties and for giving me this opportunity to be a part of GSoC’21 under ns-3. I had a great experience working on this project. I learned a lot of new concepts while working on this project. Our weekly discussions were very exciting - Apart from me giving the project updates, we used to have some good discussions on different topics and scenarios. A lot of times, we also dug into the code to identify and resolve the issues. This experience has taught me a lot, and it will definitely help me in the days to come. I would also like to thank Google for providing such a great opportunity.

Any difficulties faced? How did we overcome it?

In general, most of the proposal ideas worked out. But sometimes, I have been stuck debugging the code for different issues. It took me around a week to resolve some of them each. The mentors were a great help during this process. Whenever it took more time to debug, I reached out to the mentors on our Zulip group to help me identify the issue. Even if the issue wasn’t resolved, we had gotten close to identifying and/or fixing it. And soon, the problem got resolved.

Any Suggestions for Future Students?

  • Use the Community Bonding Period well!
    • Run through your timeline, discuss the idea with the mentors and identify any potential blockers.
    • Get familiar with the code and gain confidence before you start working on the project.
  • Reach out to the mentors or ns-3 community for help, suggestions, and updates.
    • If you are stuck on something, don’t waste time till the next meeting. Give it a good try and reach out to your mentors soon!
    • Keep communicating with your mentors throughout the week to keep them updated.
  • Plan the GSoC project foreseeing your other future commitments.
    • If you have any other commitments during the GSoC period, inform your mentors and plan your activities accordingly. If possible, please foresee this while writing your proposal itself.
  • Make the most out of it!
    • These ten weeks will be full of fun and learning experiences. Remember that you are getting a mentorship, and it’s an excellent opportunity for you.