'Ruru' is a TCP latency monitoring application that helps understanding wide area TCP traffic in real time. It utilises Intel DPDK for high speed packet processing (up to 40Gbit/s) and a Node.JS web frontend to present results.
Ruru at RIPE 75: https://ripe75.ripe.net/archives/video/92/
Ruru was featured in a PacketPushers podcast: http://packetpushers.net/podcast/podcasts/pq-142-tcp-latency-monitoring-ruru/
Ruru has been published in SIGCOMM 2017. Our paper is:
 Cziva, R., Lorier, C. and Pezaros, D. P. (2017) Ruru: High-speed, Flow-level Latency Measurement and Visualization of Live Internet Traffic. In: SIGCOMM 2017, Los Angeles, CA, USA, 21-25 Aug 2017
The system componses of three parts:
Communication between components uses sockets (zmq and websockets). The high-level architecture is shown below.
Installation consists of the following steps:
Ruru is an owl from New Zealand. The bird has been selected to symbolise our software's 'intelligence' and 'clarity in the darkness'. In Māori tradition the ruru was seen as a watchful guardian. You can learn more here.
Ruru is free to deploy and use. The software is provided using a BSD licence that you can find in the LICENSE file.
It measures TCP handshakes for each individual flow: the time it takes to set up a TCP connection. It looks at TCP flags (SYN, SYN-ACK, first ACK) of the TCP packets (and nothing else).
Ruru uses the IP2Location.com databases for IP->ASN, IP->geolocation and IP->proxy information mapping (these are 3 different databases from IP2Location).
The core of Ruru (that measures the latency for each flow) is based on DPDK, therefore it can cope with up to 40Gbit/s traffic. Geo-localising each source and destination IP address takes a lot of CPU cycles, therefore it mostly depends on how powerful your host machine is. We have deployed Ruru tapping a 10Gbit/s link.
All DPDK supported NICs can be used for Ruru. All supported NICs can be found here: http://dpdk.org/doc/nics. We used Intel X520 NICs at REANNZ.
In case of any other questions, please contact Richard Cziva ([email protected])