Title: OmniPath Ping: Active Network Measurement in the Era of Packet Spraying
Authors: Kaicheng Yang, Zongwei Lv, Peijun Huang, Kaitai Zhang, Qiuheng Yin, Yaoming Li, Feiyu Wang, Zhuochen Fan (Peking University); Yikai Zhao, Chen Sun, Xia Zhu (Huawei Technologies); Tong Yang (Peking University)
Reviewer: Liu Yipeng (first-year master’s student, SNG)
Introduction
Ping and traceroute are fundamental tools for monitoring datacenter networks and locating failures. Traditional methods are built on flow-level load balancing such as ECMP: all packets of the same flow follow a fixed path, so the mapping between TTL and a specific switch is approximately one-to-one. However, packet spraying in next-generation datacenters spreads packets from the same flow across multiple equal-cost paths, which creates two problems. A fixed TTL now corresponds to only a set of candidate switches, so it can no longer pinpoint where packet loss occurs; and to explore all paths, hosts must send roughly O(n log n) probe packets, which becomes too expensive when the number of paths is large.
OmniPath Ping (OPP) is a switch-host co-design that uses the forwarding facts already known by switches to record paths and control probe exploration. It targets service tracing and aims to provide full path coverage, hop-by-hop fault localization, and scalable network-level concurrency control under packet spraying.
Core Idea and Contributions
The core idea of this paper is to move path recording and path exploration into the network itself in packet-spraying environments. Because switches know the actual path each packet takes, a probe can have hop-by-hop information written into it as it passes through switches. When more equivalent paths need to be covered, the switch can replicate the probe inside the network and deduplicate it later at convergence points. The host reads these records after receiving the ACK and reconstructs the real path, without relying on the assumption that “a certain TTL must correspond to a certain switch.”
The contribution of the paper is a set of three coordinated mechanisms: an OmniPath cache in the switch data plane that stores hop-by-hop port and time information; in-network replication and deduplication so that one host probe can cover multiple equivalent paths; and topology-aware concurrency control, which schedules probing tasks according to the cache capacity of switches at different levels and uses USM to handle anomalies such as loops. With these mechanisms, OPP serves as a unified service-tracing primitive for diagnosing ACL drops, forwarding loops, link flapping, and congestion.
Experimental Evaluation
The paper evaluates OPP through large-scale NS-3 simulation and a real-switch testbed, covering Fat-tree, Leaf-spine, 2D torus, and 3D torus topologies, with service flows from distributed training and inference as workloads.
Across all tested topologies, OPP achieves full path coverage with about one probe per probing task. Compared with packet-spraying adaptations R-Pingmesh and RD-Probe, the latter two need more than 1,024 probes to reach 99% coverage in a 64-ary Fat-tree, and more than 256 probes in a 6 × 6 × 6 3D torus. When the baselines are pushed beyond 99% path coverage, OPP reduces host probing overhead by up to about 99.90%, and the number of probes and ACKs in the network is also far lower than the baselines. The gain comes from moving replication and path exploration from the host CPU to the switch ASIC. OPP provides 10 ms-level service tracing in datacenter-scale networks, and the paper reports that the switch cache needs only about 181 KB. The real testbed uses 100 Gbps links to validate the cache and probe-handling logic, and it evaluates the load on recirculation ports. Experiments on ACL drops, forwarding loops, link flapping, and congestion show that OPP can use hop-by-hop telemetry to locate fault positions; USM helps the system avoid infinite recirculation and preserve localization ability in loop scenarios.
Q&A
Q1: Did you consider a situation where two routing planes coexist? Why is packet spraying suitable for ECMP? Is your failure ping-pong mechanism only executed on the ECMP routing plane?
A1: This paper mainly targets in-network replication and deduplication under ECMP, and the current evaluation does not consider highly complex hybrid routing scenarios. If you are referring to two routing planes coexisting, one using packet spraying and the other using ECMP, then a more complicated mechanism may be needed, because packet spraying has different characteristics.
Personal View
I think the main contribution of OPP is that it redraws the boundary of active measurement responsibilities: the host expresses which service flow to measure, while the switch records the real path and actively explores equivalent paths. This matches the hardware reality of packet spraying very well and avoids piling yet more traceroute-style probing onto the host side. A practical deployment would still need attention to data-plane cache consistency, recirculation resource isolation, and switch programmability; in addition, the paper mainly validates the design under controlled topologies and failure models, so its behavior under complex policy routing, congestion feedback, and cross-domain networks still deserves further study.