Author: pasquimp

Here the final report! In this project, we introduced throughput estimation strategies in OLSRv2 based networks. Basically we follow two strategies, the first one which relies on iperf3 and a second one which relies on packet timestamping.

We prototyped the iperf3 strategy in PRINCE. The basic idea is that each node has an iperf3 server and a node can estimate the neighbor throughput by running an iperf3 evaluation.

We set up an emulation environment in CORE, then we tested PRINCE with iperf client/server in CORE. We built a simple three nodes topology (n1, n2, n3) where n1 is directly connected (in the wireless coverage) to n2 and n2 is directly connected to n3. n1 is connected to n3 through OLSR. The neighbor estimated throughput at IP level is of about 43 Mbps on a physical link of 54 Mbps (in the figure the throughput estimated from n2 towards n1).

In order to introduce a lightweight measure strategy (without a further server process), we worked on a OONF plugin to throughput estimation based on packets timestamp. The basic idea is that the plugin sends a couple o probe packets towards each neighbor. A neighbor can estimate the throughput starting from the time difference between the time of reception of the second probe minus the time of reception of the first probe (probe-size / (t2 – t1)).

We tested the plugin in our environment in CORE. Unfortunately, the time of reception of packets probe in the plugin doesn’t fit our needs since the couple of probe packets has a time difference close to 20 us (and then overestimated throughput close to Gbps on a 54 Mbps link).

We experimented by taking socket timestamps in the reception phase (required several changes in the OONF socket code). However, the results are mainly unchanged. Then an approach entirely based on oonf_rfc5444 (which is the messaging system used in the plugin) is not accurate due to possible delay or messages manipulation in the sending phase. Then, this approach requires a different messaging system, probably in both transmission and reception phases, to keep a reliable procedure in OONF.

The code is available at https://github.com/pasquimp/prince/tree/iperf, https://github.com/pasquimp/OONF/tree/neighbor-throughput.

Thank you for the opportunity and thank in particular to my mentors for the suggestions!

In the phase 2 period, we set up an emulation environment in CORE, then we tested PRINCE with iperf client/server (https://github.com/pasquimp/prince/tree/iperf) in CORE. We built a simple three nodes topology (n1, n2, n3) where n1 is directly connected (in the wireless coverage) to n2 and n2 is directly connected to n3. n1 is connected to n3 through OLSR. The neighbor estimated throughput at IP level is of about 43 Mbps on a physical link of 54 Mbps (in the figure the throughput estimated from n2 towards n1).

We tested in CORE the initial version of the OONF plugin too (https://github.com/pasquimp/OONF/tree/neighbor-throughput). So, the plugin now is able to send a couple of probe packets towards each neighbor and is able to read the time of reception of packets. I’m now exploring a problem in the reception of the probe.

In the next weeks, we will perform other tests with PRINCE with iperf and with the OONF plugin to resolve the problems in the reception phase and then we will perform timestamp based throughput estimation in order to compare the results obtained with PRINCE with iperf and OONF with the plugin. We will update you in the coming weeks!

In the phase 1 period, we designed and prototyped a throughput estimation client/server in PRINCE based on iperf3 library. The basic idea is that each node has an iperf3 server and a node can estimate the neighbor throughput by running an iperf3 evaluation. The code is available at https://github.com/pasquimp/prince/tree/iperf.

In order to keep the throughput estimation in OONF, we are evaluating the best strategy among forwarding the estimation from PRINCE to OONF or introduce a new plugin in OONF to perform throughput evaluation. A possible prototype of a new plugin in OONF is available at https://github.com/pasquimp/OONF/tree/neighbor-throughput.

In the next weeks, we will decide on the best strategy in order to keel reliable neighbor throughput estimation and keep aware OONF about the estimation. We will update you in the coming weeks!

This project aims to develop a module for the throughput estimation in OLSRv2 based networks. The basic idea is to evaluate the throughput of 1-hop and 2-hop network paths and to expose the measures to the user by visualizing them on the netjson graph.

The community bonding period had the goals to improve my knowledge of OLSRv2, to study OONF and its basic modules, then start approaching netjson. Now we are designing how to realize the throughput measures between the nodes. Basically, we are considering two approaches: the implementation of probe-based measure in OONF by using its reader/writer objects, or an alternative approach that realizes a daemon which reuses iperf based measures.