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.


Stroboscope compiler
Sample network
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 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.


Stroboscope: Declarative Network Monitoring on a Budget

Olivier Tilmans, Tobias Bühler, Ingmar Poese, Stefano Vissicchio, Laurent Vanbever
USENIX NSDI 2018. Renton, WA, USA (April 2018)
@inproceedings {211289, author = {Olivier Tilmans and Tobias B{\"u}hler and Ingmar Poese and Stefano Vissicchio and Laurent Vanbever}, title = {{Stroboscope: Declarative Network Monitoring on a Budget}}, booktitle = {15th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 18)}, year = {2018}, isbn = {978-1-931971-43-0}, address = {Renton, WA}, pages = {467--482}, url = {}, publisher = {{USENIX} Association}, }

Mille-Feuille: Putting ISP traffic under the scalpel

Olivier Tilmans, Tobias Bühler, Stefano Vissicchio, Laurent Vanbever
ACM HotNets 2016. Atlanta, GA, USA (November 2016)
@inproceedings {tilmans-mille-feuille, author = {Olivier Tilmans and Tobias B{\"u}hler and Stefano Vissicchio and Laurent Vanbever}, title = {{Mille-Feuille: Putting ISP Traffic Under the Scalpel}}, booktitle = {Proceedings of the 15th ACM Workshop on Hot Topics in Networks}, series = {HotNets '16}, year = {2016}, isbn = {978-1-4503-4661-0}, location = {Atlanta, GA, USA}, pages = {113--119}, numpages = {7}, url = {}, acmid = {3005762}, publisher = {ACM}, }


Olivier Tilmans (*)
Université catholique de Louvain
Tobias Bühler (§)
ETH Zürich
Ingmar Poese
Stefano Vissicchio
University College London
Laurent Vanbever
ETH Zürich