A module for OLSRv2 to throughput estimation of 2-hop wireless links

Hi to community members!

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!

Leave a Reply

Your email address will not be published. Required fields are marked *