Difference between revisions of "GSOC2022NeighborCacheFinalReport"

From Nsnam
Jump to: navigation, search
(Project Overview)
Line 9: Line 9:
 
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana  
 
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana  
  
The project aims to implement a “Perfect” version of ARP and NDP which produce caches that contain all needed IP address–MAC address mapping. ARP and NDP are sometimes intrusive in high-level testing, it will introduce unexpected noise to the simulation (unwanted delays, packet drops, etc.). The new method generates all needed ARP/NDP caches before simulation start to avoid the delay and message overhead of address resolution in simulations that are focused on other performance aspects.
+
The project aims to implement a “Perfect” version of ARP and NDP which produce caches that contain all needed IP address–MAC address mapping. ARP and NDP are sometimes intrusive in high-level testing, it will introduce unexpected noise to the simulation (unwanted delays, packet drops, etc.). The new method generates all needed ARP/NDP caches before simulation start to avoid the delay and message overhead of address resolution in simulations that are focused on other performance aspects. With the help of the example provided, ns-3 users can enable auto-generated neighbor cache in different scopes.  Documentation was added to help users to understand and unit test cases were added to verify the fundamental behavior. The project was divided into 2 phases, and the phase-wise work is available below.
 
+
 
== Merge Requests, Commits, and Project Details ==
 
== Merge Requests, Commits, and Project Details ==
  
Line 52: Line 51:
  
 
We completed the proposed work with a method different from the proposal. That method was raised during the community bonding period and was discussed and decided during phase 1. The method we chose functionally achieves our goals with neater modification.
 
We completed the proposed work with a method different from the proposal. That method was raised during the community bonding period and was discussed and decided during phase 1. The method we chose functionally achieves our goals with neater modification.
 +
 +
==Future Work==
 +
 +
During phase 2, when modifying neighbor cache NUD_STATE, I found the related code in <em> ReceiveLLA </em> and <em> HandleNA </em> has an improper structure and have multiple logical mistakes, I planned to refactor the code. For this task, I already opened up an [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

Revision as of 05:38, 10 September 2022

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 2022 projects

Project Overview

  • Project Name: Perfect ARP and NDP
  • Student: Zhiheng Dong
  • Mentors: Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana

The project aims to implement a “Perfect” version of ARP and NDP which produce caches that contain all needed IP address–MAC address mapping. ARP and NDP are sometimes intrusive in high-level testing, it will introduce unexpected noise to the simulation (unwanted delays, packet drops, etc.). The new method generates all needed ARP/NDP caches before simulation start to avoid the delay and message overhead of address resolution in simulations that are focused on other performance aspects. With the help of the example provided, ns-3 users can enable auto-generated neighbor cache in different scopes. Documentation was added to help users to understand and unit test cases were added to verify the fundamental behavior. The project was divided into 2 phases, and the phase-wise work is available below.

Merge Requests, Commits, and Project Details

Project Wiki Page: GSOC2022PerfectArp

Project Plan: link

Merge Requests
No. Name Status Commit
[1] Internet: GSoC-22 generate ARP/NDISC cache automatically Merged link
[2] internet: GSoC-22 dynamic neighbor cache Reviewing link

Community Bonding Period

During the community bonding period, we did some preparation work:

  • Create a wiki page that will be maintained as the GSoC project evolves.
  • Set a weekly meeting with my mentors for reports and discussions.
  • Discuss the details about how to implement the ideas mentioned in the proposal and some other new ideas.
  • Layout a project plan.

Phase 1

During phase 1, I did parallel jobs for the two methods we discussed during the community bonding period.

The first method is to create a locally shared neighbor cache per network. In this approach, we create a new data structure for the locally shared neighbor cache, which is a map of map: std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache, the key is the network address and the value is the pointer to normal neighbor caches in that network, (the new data structure for perfect cache is necessary to deal with the scenario that one interface has multiple IP addresses which are from different network address). We created child classes PerfectArpL3Protocol and PerfectArpCache from ArpL3Protocol and ArpCache , override functions CreateCache , Flush , CreateCache , Lookup , Add to deal with the new data structure of neighbor cache, make it shared among devices in same networks and update dynamically with IP address added/removed. We made this method work but finally didn't choose it, the prototype can be found in my GSoC branch: link.

The second method, which is also the final chosen one, is adding a helper to automatically generate neighbor caches. Users could use the helper after IP addresses are assigned, and the helper will iterate devices in the scope chosen by users to fill up neighbor caches properly by auto-generated entries. We choose this method because it's can achieve the same effect with much neater modification. It doesn't need the new data structure for shared neighbor cache and new child class. We completed a static neighbor cache generating helper and corresponding example and test during phase 1, which is included in this MR: link.

Phase 2

During Phase 2, we worked on a dynamic neighbor cache, which makes the auto-generated neighbor cache update by IP addresses added/removed, and an example is along with this feature. I also worked on documentation and all the comments and suggestions provided by my mentors and the reviewers.

MR submitted during this phase: link

Proposal vs. Actual Work

We completed the proposed work with a method different from the proposal. That method was raised during the community bonding period and was discussed and decided during phase 1. The method we chose functionally achieves our goals with neater modification.

Future Work

During phase 2, when modifying neighbor cache NUD_STATE, I found the related code in ReceiveLLA and HandleNA has an improper structure and have multiple logical mistakes, I planned to refactor the code. For this task, I already opened up an MR.