Stroboscope: Declarative Network Monitoring on a Budget

Stroboscope
Declarative Network Monitoring on a Budget

Stroboscope enables fine-grained monitoring of any traffic flow by instructing routers to mirror millisecond-long traffic slices in a programmatic way. Stroboscope takes as input high-level monitoring queries together with a budget and automatically determines which flows to mirror, where to place the mirroring rules and when to schedule these rules to maximize coverage while meeting the input budget.

Overview

Stroboscope compiles operator-specific queries to produce multiple thin slices of mirrored traffic. As an example, we assume that an operator would like to monitor the flow towards 1.2.3.0/24 in the network on the right. She would like to confirm that the traffic is following the expected path:

Stroboscope takes as input multiple queries from the operator

Using Stroboscope's SQL-like language, an operator can ask MIRROR or CONFINE queries. Mirror queries provide network-wide path tracing and confine queries are useful to detect unwanted forwarding behavior. In addition, operators can specify the maximum rate of mirrored traffic (USING), the duration of the measurement campaign (DURING) and the frequency at which the measurements is run (EVERY).
Stroboscope performs a three-staged compilation process

Stage 1: Resolve the high-level queries (what?)

Stroboscope estimates per-prefix traffic volumes and forwarding paths using measurements from previous monitoring campaigns and optional information from the network.

Stage 2: Optimize the mirroring locations (where?)

Stroboscope uses two provably correct algorithms to optimize the mirroring locations in the network. Fewer mirroring rules will automatically reduce the amount of generated mirrored traffic.

Stage 3: Compute the measurement campaigns (when?)

Stroboscope schedules mirroring rules over time. The schedules use the estimated traffic amount to meet the operator-defined budget, while including as many measurements as possible to increase the monitoring accuracy.
Stroboscope executes the measurement campaign to output a stream of collected packets

In the end, Stroboscope carries out the measurement campaign by instructing routers to mirror query-defined traffic flows for a specific amount of time. Stroboscope outputs a stream of collected packets with their meta-data meant to be processed by the operator or external applications.
During the measurement campaign, Stroboscope always compares the amount of mirrored traffic with the estimated traffic volume. If it detects a budget violation, the campaign is prematurely terminated within a few milliseconds.

Use Cases

Stroboscope's output stream of mirrored packets can be used in arbitrary ways. In the following, we present three use cases that we implemented and tested. The code is available on GitHub.

Estimating loss rates

To estimate losses over a path, an operator can combine mirror and confine queries. The mirrored traffic slices from the ingress and egress of the path can be used to detect lost packets. The confine query guarantees, that no packet left the expected path.
Estimating load-balancing ratios

It is known that hash function polarization can cause suboptimal network usages. Normally, such problems are hard to detect. However, Stroboscope's mirrored traffic slices can be used to detect these problems by computing a load-balancing ratio. We can compare the packets observed on one of the load-balanced paths with a traffic slice from before the load-balancing point.
Estimating one-way delays

Stroboscope can also estimate one-way delays. For that, it first estimates router-to-collector latencies using probes and pre-installed mirroring rules on each router. A one way delay is then estimated by: (i) identifying matching packets in slices from different routers; (ii) reconstructing the router traversal times using the router-to-collector latencies; and (iii) computing the difference between traversal times.

Publications