Fed4Fire+ Experiments

Librecast: IoT Software Updates over IPv6 Multicast

Experiment to compare unicast vs multicast

Our experiment with Fed4fire was Librecast: IoT Software Updates over IPv6 Multicast. The experiment was run on IMECs Virtual Wall 1. Librecast aimed to create a simple experiment to compare unicast versus multicast for the simple use case of software updates. The experiment aimed to measure and compare the load on servers and demonstrate the different properties of multicast.

Normally with unicast, servers and other devices deliberately stagger requests and provision of software updates. Multicast on the other hand, due to its publication/subscription model, accepts all of the requests at once. There is no need to stagger server requests and the load remains the same.

Experiment Setup

All software requires updates for bugs/security updates
Currently these are served via unicast with massive infrastructure to serve millions+ nodes
IPv6 Multicast would be a more efficient way of updating any device
The experiment series aimed to compare Unicast v Multicast
Demonstrate how different the properties of Unicast and Multicast are
Bonus: Give a usecase of multicast that isn't streaming

Experiment Detail

In addition to testing the IoT Updater, for the udp/unicast comparison parts of our experiment series, we created unisync, which was designed to mimic the same functionality as our IOTUPD tool, however, instead of using multicast as its transport method, it uses unicast.

We run the simulated software updates in a variety of network configurations and with a variety of file sizes to simulate the impact of different types of updates; in each case, we measure network use, server load, client load, and speed of update for each combination of update mechanism and scheduling strategy.

The experiment sets compared the following methods of providing updates:

tcp Traditional unicast using a TCP-based service: a server listens to TCP requests to send a copy of the software update, and each client requests the update from the server: this is the mechanism used by the vast majority of current services.
scp Traditional unicast using a TCP-based service: a server listens to TCP requests to send a copy of the software update, and each client requests the update from the server: this is the mechanism used by the vast majority of current services.
udp Unicast using a UDP-based service: this is similar to the TCP case, it uses datagrams instead of virtual circuits: this mechanism was utilized because multicast is by necessity based on datagrams: there is no feedback from the receiver to sender, and we wanted to help determine which differences may be caused by unicast vs multicast, and which ones by virtual circuits vs datagrams.

Independently of the method selected, there are three client scheduling strategies:

immediate All clients request updates at approximately the same time.
random Each client waits for a random time, up to the duration of the corresponding experiment using the "immediate" strategy.
random2 Each client waits a random time, up to twice the duration of the corresponding experiment using the "immediate" strategy.

Example Topologies

LAN 8 Clients

Diagram showing experiment setup for 8 clients

Two LANS: Network with 8 Clients, 1 Router

Diagram showing experiment setup for Network with 8 Clients, 1 Router

Network with 8 Clients, 4 Clients per LAN, 3 Routers

Diagram showing experiment setup for 8 Clients, 4 Clients per LAN, 3 Routers

Network with 8 Clients, 4 clients per LAN 7 Routers

Diagram showing experiment setup for 8 Clients, 4 Clients per LAN, 7 Routers

Results and Conclusions

Multicast is unaffected by number of client requests
Multicast performs better without random scheduling compared to unicast.
Multicast requires fewer server resources for the same number of clients, which could lead to financial and environmental benefits.
Multicast appears to be more scalable
MLD Snooping can be used in server implementations to trigger software downloads.

The results from the experiment demonstrated, that for the load on a server across the network, the load remains the same for multicast. Unicast was starting to show a large increase in load. Librecast would like a larger scale experiment to confirm these findings, by a higher magnitude than tens of nodes. In future experimentation, Librecast aims to recreate these simple comparison experiments on a testbed on a scale of thousands.

Future Research

We would like to have a larger-scale experiment in the future as we believe that multicast will save business costs as more pressure in the form of carbon taxes is brought to bear in the EU. A future experiment with more metrics would demonstrate the potential power and cost savings.

This research needs to be carried out at a larger scale.

Funding

This Project was funded by Fed4Fire Plus which has received funding from the European Union’s Horizon 2020 research and innovation programme, which is co-funded by the European Commission and the Swiss State Secretariat for Education, Research and Innovation, under grant agreement No 732638.