You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our proposal uses the adaptative hello interval to dynamically adjust the time between hello interests: between 1s and 60s. When a node stays some time without learning new neighbors, we consider the network is quite stable and increment the hello interval. Thus, the hello interval becomes a relation between being too short and rapidly detect changes with the price of increasing the overhead.
So far so good. However, when we have a highly dynamic environment and the node stays for a quite long time without adjacency nodes (e.g., moving away from anyone else), the hello increases, and maybe when someone comes to its neighborhood, we lose the adjacency detection window.
A way to solve this would be to take advantage of information from the underlayer protocols. In 802.11, for example, the beacon exchange gives us the "association list" that could help to set up the proper hello interval.
For now, we reduced the maximum hello interface to the average association time of the scenario (e.g., 5s - it depends on the scenario).
The text was updated successfully, but these errors were encountered:
- Change the syncData parameter from boolean to integer (number of
rounds to generate data);
- using a random interval (uniform dist 10ms - 15ms) to request
data upon learning a new prefix;
- changing the max hello interval from 60s to 5s (Issue #4);
- Setting up a retransmission of data when the interest returns
timeout (the producer node may had moved away);
- many adjustments on the scenario/ndncomm2020-exp1.cpp
Our proposal uses the adaptative hello interval to dynamically adjust the time between hello interests: between 1s and 60s. When a node stays some time without learning new neighbors, we consider the network is quite stable and increment the hello interval. Thus, the hello interval becomes a relation between being too short and rapidly detect changes with the price of increasing the overhead.
So far so good. However, when we have a highly dynamic environment and the node stays for a quite long time without adjacency nodes (e.g., moving away from anyone else), the hello increases, and maybe when someone comes to its neighborhood, we lose the adjacency detection window.
A way to solve this would be to take advantage of information from the underlayer protocols. In 802.11, for example, the beacon exchange gives us the "association list" that could help to set up the proper hello interval.
For now, we reduced the maximum hello interface to the average association time of the scenario (e.g., 5s - it depends on the scenario).
The text was updated successfully, but these errors were encountered: