File delivery over multicast: UFTP vs. Filoop
In our previous post Efficient multicast of updates to satellite connected devices we talked about how multicast using erasure coding provides an efficient way of ensuring a reliable, scalable, and efficient over-the-air file delivery solution. In this post we will compare two solutions to the file update problem.
As a quick recap; erasure coding is a technique whereby we encode the input data as linear equations, each equation describes the data (e.g. a file), and a receiver now only needs to collect enough equations rather than specific packets. Two receivers missing different packets may now benefit from the same linear equation, since they can both solve for their specific unknown.
First solution: UFTP
The first solution UFTP uses traditional UDP multicast to send the file. To ensure reliability, clients will send NAKs (Negative Acknowledgments) back to the server describing the data they are still missing. The server can then retransmit these missing pieces until all clients have the file.
Second solution: Filoop
The second solution called Filoop, developed by us, is also based on UDP multicast. However, to make the data delivery more efficient we use erasure coding. Our solution does not use any feedback from the clients, the erasure code ensures (with high probability) that every packet received is useful. This way we don’t need to keep track of the current state of the different receivers. We call this mode “blind”, we are planning to add a “managed” mode which will allow us to track when clients finish.
Test setup
To conduct the test we use a tool called Mininet, which allows you to setup a network topology with multiple hosts and emulated links. Using this we are able to see how the two solutions perform under different network conditions. For this comparison we selected the following parameters:
Bandwidth: 10 Mbps
Delay 100 ms (in each direction i.e. 200 ms RTT)
Packet loss varying from 0-5%
1 server and 20 clients
The transmitted file from server to the clients was 100 MB.
Results
We initially measured two things: time and use of the feedback channel. We also wanted to measure the data channel usage, however since we did not implement any feedback in the Filoop solution we have no way of stopping the server once all clients are complete at the moment (we are adding support for this mode).
Time
Time, measured as how long it took for all clients to receive the file, increases for both solutions as packet loss increases - however uftp suffers significantly more. This is expected since UFTP will have to retransmit more packets, as each client may lose different pieces of the data. We also expect that increasing the number of clients will degrade the performance of UFTP further - whereas Filoop is much more agnostic to the number of clients.
Feedback channel
A similar trend for UFTP can be seen for the use of the upload / feedback. As packet loss increases more information needs to be sent from clients to the server. Since Filoop does not require any feedback (blind mode) performance does not suffer. As mentioned we do plan to add some minimal feedback in Filoop, a few packets at the end of the transmission, to be able to stop the server once all client downloads are complete.
Conclusion
As shown by the initial results here, our solution Filoop (using erasure coding) looks very promising compared to the more traditional UFTP solution. If you have questions or you would like to try Filoop and experiment with erasure codes don’t hesitate to get in touch at contact@steinwurf.com.