Pith. sign in

REVIEW 4 major objections 7 minor 60 references

Model-Based Diagnosis: Automating End-to-End Diagnosis of Network Failures

T0 review · 4 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Model-based network diagnosis can automatically trace an end-to-end failure report to the faulty switch or link, through data and control plane interactions.

desk verdict Genuinely new paradigm for automated network fault diagnosis with a serious evaluation, but the headline 'seconds instead of hours' is extrapolated, not measured. read the letter →

arxiv 2506.23083 v2 pith:H2GNN6XS submitted 2025-06-29 cs.NI

Changrong Wu , Yiyao Yu , Myungjin Lee , Jayanth Srinivasa , Ennan Zhai , George Varghese , Yuval Tamir This is my paper · ORCID
classification cs.NI
keywords model-basednetworkdiagnosisNetDxrootcauseanalysisfaultmodeldataplaneandcontrolinjectionverificationBGP
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is trying to establish that a network operator does not need to manually trace through traceroutes and routing logs to find the cause of a failure: a system can do it automatically, starting from an end-to-end 'host A cannot reach host B' report and ending with the specific faulty switch or link. The core move is to write down a formal model of what a fault-free switch does at its interfaces, then obtain a fault model by negating that behavior. The paper's NetDx implementation instantiates this model for IPv4/BGP networks, collects low-overhead observations from switches, and follows systematically derived procedures that trace from the packet drop back through data plane and control plane interactions to the root cause. If right, this would turn a multi-hour expert task into a sub-minute automated one for the class of permanent or high-frequency faults that show up as packet drops or corruption.

What carries the argument

The machinery is the switch functional and fault model plus the recursive diagnosis procedure built on it. The paper defines seven functionality categories: packet forwarding, packet transformation, data plane table generation, route table generation, route advertisement reception, route advertisement generation, and interaction with external entities. For each category it writes the fault-free behavior formally, then derives faulty behavior by negation. NetDx compares live observations, including trace-bit counters, drop counters, FIB and RIB retrieval, header logs, and control-plane packet capture, against the predictions of a configuration analysis tool; when a drop is found, the procedure asks whether the drop was the correct local action, and if so, shifts suspicion to the neighbor that forwarded the packet or to the switch that supplied routing information, recursively until the switch or link deviating from the model is found.

What would settle it

Inject a switch fault that is within the stated scope, such as a software data race that corrupts a single FIB entry for a few milliseconds during diagnosis, and run NetDx on the resulting failure report; if NetDx returns no diagnosis or names the wrong switch, the completeness of the negation-derived fault model is disproved, while a correct diagnosis supports the model's boundary.

Watch

Extended reading notes

Core claim

The paper claims that model-based network diagnosis is a new paradigm in which the root cause of a network failure is identified by comparing observed switch behavior against a formal end-to-end model of packet forwarding and routing, and that this paradigm handles data plane and distributed control plane faults in one unified procedure. The central claim, demonstrated by NetDx, is that from a failure report specifying affected flows, the system can identify the faulty switch or link even when the failure involves a chain of symptoms: for example, a faulty switch advertises a bad route, a fault-free switch forwards packets the wrong way, and another fault-free switch drops them. The paper reports 100% correct diagnoses in an automated fault injection campaign covering all ten fault types derived from the seven-category fault model, and 30 of 33 collected provider faults within the model's scope diagnosed in seconds instead of hours, with three intermittent faults conservatively counted as failures.

Load-bearing premise

The assumption that carries the whole result is that negating the seven fault-free switch behaviors listed in the paper gives a complete list of the faults that matter: permanent or high-frequency intermittent faults that show up as packet drops or corruption, and if a real fault falls outside those categories, NetDx will not diagnose it.

Editorial extensions

If this is right

  • If correct, an operator can replace hours of manual ping, traceroute, and log analysis with a script that pinpoints the faulty switch or link, cutting diagnosis from a median of 4.5 hours to seconds for in-scope faults.
  • Data plane and control plane interaction cases, such as a faulty switch generating a bad route that makes fault-free switches drop packets, are diagnosable automatically rather than only locating the switch where the drop visibly happens.
  • The diagnosis procedures depend on protocols, topology, and configuration rather than switch internals, so they are reusable across switch implementations; only support for additional protocols requires new script work.
  • The seven-category fault model is itself a reusable artifact: other diagnosis systems can be checked against the same negation-derived fault categories.
  • The fault injection campaign, including double-fault runs, produced correct diagnoses in every run, so the approach can tolerate rare simultaneous faults despite being designed for a single fault at a time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • My inference: the same 'negate the fault-free model' recipe should transfer to overlay networks and performance faults if a formal correct-behavior model for those features is written; the paper identifies these as future work, and the recipe does not depend on IPv4/BGP specifics.
  • My inference: the boundary of the claim is the boundary of the fault model, since 19 of the 52 collected real faults involving overlays, delays, transient effects, congestion, and configuration errors are outside NetDx's scope, so the practical win depends on permanent drop and corruption faults remaining the dominant production failure mode.
  • My inference: the three out of 33 conservatively counted failures were intermittent faults with unknown frequency, so a testable extension is to measure the frequency threshold at which the sliding-window counters and double-run diagnosis reliably catch intermittent in-scope faults.
  • My inference: the system inherits any blind spots of the configuration analysis tool used to predict correct behavior, because an incorrect or outdated configuration model would make a fault-free network look faulty and could send the procedure to the wrong switch.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper proposes model-based network diagnosis (MBND), a paradigm in which a functional model of fault-free switches is used to derive a switch fault model by negation; diagnosis procedures are then systematically derived from this model, using a configuration analysis tool (Batfish) to compute expected behavior and comparing it with data collected from the operational network. The authors implement MBND in NetDx for IPv4/BGP networks, with P4-based data plane primitives, a switch agent, and a diagnosis manager. They evaluate NetDx on Podnet, an emulator using the P4 behavioral model and FRR routing software, through an automated fault injection campaign (10 fault types, 100 single-fault and 100 double-fault runs) and on 33 fault scenarios collected from a large cloud provider. The paper reports 100% correct diagnosis in the injection campaign, 30 of 33 real-world scenarios diagnosed, and a comparison with manual diagnosis by three PhD students. The central performance claim is that diagnosis takes seconds instead of hours, but this is based on an extrapolation from primitive counts rather than a measured end-to-end latency on a real network.

Significance. The systematic top-down derivation of diagnosis procedures from a formal switch model is a genuine conceptual contribution that distinguishes this work from bottom-up debugging primitives. The paper is unusually complete: it provides the fault model (Table II), the derivation of primitives and procedures, a full implementation (over 5,000 lines of P4/Python), a network emulator, an automated fault injection harness, and a real-world fault dataset. If the performance and coverage claims are properly bounded, MBND/NetDx could be a valuable step toward automated root-cause diagnosis of enterprise network failures, and the fault model itself is reusable by others. The main weaknesses are that the primary fault-injection campaign injects faults derived from the same model that generated the diagnosis procedures, and that the real-world dataset is processed through emulation rather than a real deployment; the paper acknowledges these limitations in Sections IX-C and X, but the abstract and introduction present the results in a more unqualified way.

major comments (4)
  1. [§IX-C2, §IX-B, §VI-C] The headline claim that NetDx reduces diagnosis from hours to seconds is not supported by any measurement on a real network. The only measured end-to-end figure is 1:38 on Podnet, which the paper itself describes as 'extremely slow' (§IX-B). The 'seconds' estimate in §IX-C2 is an extrapolation: each primitive is assumed to cost one network RTT plus local processing, using the primitive counts in Table VI. This assumption is unvalidated for Batfish queries, which may involve control-plane state computation and can take far longer than an RTT, and it does not account for the repeated-run stabilization described in §VI-C ('run each diagnosis at least twice with a short delay between runs'). Moreover, §IX-A states that the 33 real-cloud faults were reproduced in the emulator, so the '30 are efficiently diagnosed in seconds' statement in the abstract is also not a measurement on the provider's network. Please provide either a measured end-to-end latency on a real or near-real testbed, or a defensible upper bound with per-primitive latency measurements and an explicit treatment of Batfish, convergence, and stabilization delays. Absent that, the 'seconds instead of hours' claim should be removed or heavily qualified.
  2. [Abstract, §IX-A, §IX-C] The abstract's '100% of faults were diagnosed correctly' and '30 are efficiently diagnosed in seconds' are not qualified. The 100% figure comes from the automated fault injection campaign, where faults are injected from the same model used to derive the diagnosis procedures; Section IX-C explicitly acknowledges this circularity. The 30/33 figure refers to real faults from a cloud provider that were reproduced in Podnet and diagnosed there, not diagnosed on the provider's network, and three of the 33 are conservatively counted as failures because their intermittency could not be assessed. Please make these distinctions in the abstract and introduction, for example: '100% of faults injected from the model' and '30 of 33 emulated reproductions of real faults.' Without such qualification, the abstract overstates the independence and scope of the validation.
  3. [Table II] In the Packet Forwarding category, the second faulty behavior is formalized as EgressPort(C_forward, *)=p', p'∈P. Since a fault-free switch also forwards to a port in Q⊂P, this formal definition includes the fault-free case and is therefore not a valid negation of the fault-free behavior. The informal text ('incorrect egress interface') suggests the intended condition is p'∉Q (or p'∈P\Q). The same issue appears in Table VII. Because Table II is the foundation from which the diagnosis primitives and procedures are derived (§III–§V), this inconsistency should be corrected before the derivation can be regarded as formally sound.
  4. [§IX-B] The comparison with manual diagnosis uses three computer science PhD students, not experienced network operators. The authors acknowledge this limitation, but the introduction and conclusion state that NetDx 'replaces and dramatically accelerates diagnosis by an experienced human operator' and 'improving failure response times from hours to seconds.' The manual-baseline evidence does not support the 'experienced operator' part of the claim. Please either temper the claim to the actual baseline (knowledgeable non-experts) or provide evidence from experienced operators, even if only qualitatively.
minor comments (7)
  1. [Table II, Table VII] The label 'FLTY' is used in several rows of the fault model tables but is not defined in the Table III notation key; please define it or replace it with 'FAULTY'.
  2. [Appendix D] In the Packet Transformation row, the condition '𝑇𝑇𝐿′ ≠ 𝑇𝑇𝐿𝑖𝑛 − 1.5' appears to be a typo; the intended condition is presumably 𝑇𝑇𝐿′ ≠ 𝑇𝑇𝐿𝑖𝑛 − 1.
  3. [Figure 2] Figure 2 contains garbled word spacing, e.g., 'configure netw or kentr ypoints to markp ackets of interest', 'packetd rops', and 'classification packetd rops cause'. Please correct the pseudocode rendering.
  4. [References] References [13] and [14] are duplicates (both are the SIGCOMM '17 paper by Beckett, Gupta, Mahajan, and Walker); please remove one.
  5. [§IX-A] The text says 'In all eight cases, the diagnosis script executed by NetDx identified the fault,' referring to eight equivalence classes, but the reader may expect per-fault results for the 33 faults; please clarify whether each of the 33 faults or each class was run through NetDx.
  6. [§V-A, §IX-C] The terms 'FoIs packets' and 'traced packets' are used interchangeably; please use consistent terminology, since the trace bit mechanism (§V-A) defines 'traced packets' as the operational concept.
  7. [§V-A, §X] The claim of 'essentially no overhead in terms of network bandwidth' should be qualified, since silent-drop marker packets and packet injection do add control traffic; if the overhead is negligible, state the measured or bounded amount.

Circularity Check

1 steps flagged · score 4.0 of 10

Fault-injection campaign is self-referential, but the central claim retains independent grounding from the real-world fault set.

  1. other [§IX-C and §IX-C2 (Fault Injection Campaign), Table VI]
    "While it may appear that nothing can be gained by injecting faults from the fault model used to derive the diagnosis procedures, this was invaluable for enhancing some of the diagnosis procedures (§VI-C), identifying and correcting bugs in our implementation, and estimating the latency of diagnosis (§IX-C2)."

    The derivation chain is: functional switch model (Table II) → fault model obtained by negation of the fault-free functionality (§III) → diagnosis primitives and procedures derived from those fault categories (Figure 1, §V). The automated campaign then injects 'ten fault types that cover all the categories in the fault model' (§IX-C2) and reports 100% correct diagnosis. Because the injected faults are exactly the same logical deviations that the procedures were built to detect, the 100% result is largely a self-consistency or implementation-correctness check, not independent evidence that the fault model covers real network faults.

full rationale

The paper's derivation of the fault model by negating the fault-free functional model is a legitimate logical construction, and the diagnosis procedures are systematically derived forward from that model. The main circular element is the fault-injection evaluation: the injected faults are drawn from the same fault model used to derive the procedures, so the reported 100% diagnosis success in the automated campaign is partly by construction. The paper itself acknowledges this in §IX-C, noting the campaign's value for debugging and implementation fixes rather than for independent validation. The central claim is not fully circular: the real-world 33-fault dataset provides an external sanity check (30 of 33 diagnosed), and the Batfish-based expected-behavior oracle is from an independent configuration-analysis tool. The 'seconds instead of hours' latency claim is an extrapolation from assumed per-primitive RTT costs, which is an unsupported measurement assumption but not a reduction of the diagnosis result to its inputs and therefore not a circularity issue. No load-bearing self-citation or imported-uniqueness pattern is present; prior work is cited for context, not to force the model choice. Overall, the evaluation has a genuine self-referential component, but the central contribution has independent empirical content, yielding a score of 4.

Assumptions & free parameters 2 free parameters · 5 assumptions · 2 invented entities

The central claim rests on the completeness of the fault model, the correctness of the configuration analysis tool, the trustworthiness of switch-collected data, and the single-fault assumption. The hand-chosen thresholds affect fault report triggering but are secondary to the diagnosis logic. No new physical entities are postulated; the new mechanisms are implemented only in the emulator.

free parameters (2)
  • Fault report trigger thresholds = not specified
    Section VI-A: a fault report is triggered only if the ratio of dropped traced packets to all arriving traced packets exceeds a threshold and the number of traced packets in the window exceeds another threshold. The threshold values are not reported and are hand-chosen; they determine whether the drop location is identified proactively.
  • Sliding window durations = not specified
    Section VI-A: counters and header logs use sliding windows 'restricted to recent packets'. Window sizes are not specified and affect drop detection and fault report triggering.
assumptions (5)
  • domain assumption A switch's externally visible behavior is fully determined by its configuration and standard network protocols.
    Section III states this as the basis of the functional model; if false, the model cannot be used to derive correct behavior.
  • domain assumption The switch fault model, obtained by negating fault-free functionality, is a complete characterization of the in-scope faults (permanent or high-frequency intermittent faults that cause packet drops or corruption).
    Section III derives the fault model by negation; completeness is assumed. Real faults outside the model are not diagnosed, and 19 of 52 collected faults are out of scope.
  • domain assumption At most one switch or link is faulty at a time (simultaneous faults are highly unlikely).
    Section IV: 'If only a single switch in the network may be faulty at any time, potential diagnosis ambiguities can be resolved.' The two-fault experiment repairs one fault before diagnosing the second.
  • domain assumption The configuration analysis tool Batfish returns a correct representation of the expected network behavior.
    Requirement R2 in Section IV relies on configuration analysis tools; if Batfish's model is wrong, comparisons mislead diagnosis.
  • domain assumption The diagnostic information collected from switches (counters, tables, logs) is sufficiently accurate and consistent to compare against the model.
    Section V-A introduces consistent snapshots and virtual clocks; the diagnosis depends on this collected data being trustworthy.
invented entities (2)
  • Egress virtual clock for consistent counter snapshots
    purpose: Enables silent drop detection inside a switch by reconciling ingress and egress traced packet counts.
    Introduced in Section VI-A; validated only in the Podnet emulator, not independently.
  • Marker packet for link silent drop detection
    purpose: Detects packet drops on a link by carrying traced packet counts between adjacent switches.
    Section VI-A; a new mechanism, not independently evaluated outside this paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Model-Based Diagnosis: Automating End-to-End Diagnosis of Network Failures." pith.science (2026). https://pith.science/paper/H2GNN6XS

@misc{pith2026250623083,
  author       = {Pith},
  title        = {Pith review of: Model-Based Diagnosis: Automating End-to-End Diagnosis of Network Failures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H2GNN6XS}},
  note         = {Machine review of arXiv:2506.23083}
}
read the original abstract

Fast diagnosis and repair of enterprise network failures is critically important since disruptions cause major business impacts. Prior works focused on diagnosis primitives or procedures limited to a subset of the problem, such as only data plane or only control plane faults. This paper proposes a new paradigm, model-based network diagnosis, that provides a systematic way to derive automated procedures for identifying the root cause of network failures, based on reports of end-to-end user-level symptoms. The diagnosis procedures are systematically derived from a model of packet forwarding and routing, covering hardware, firmware, and software faults in both the data plane and distributed control plane. These automated procedures replace and dramatically accelerate diagnosis by an experienced human operator. Model-based diagnosis is inspired by, leverages, and is complementary to recent work on network verification. We have built NetDx, a proof-of-concept implementation of model-based network diagnosis. We deployed NetDx on a new emulator of networks consisting of P4 switches with distributed routing software. We validated the robustness and coverage of NetDx with an automated fault injection campaign, in which 100% of faults were diagnosed correctly. Furthermore, on a data set of 33 faults from a large cloud provider that are within the domain targeted by NetDx, 30 are efficiently diagnosed in seconds instead of hours.

Figures

Figures reproduced from arXiv: 2506.23083 by the authors.

Figure 1
Figure 1. Derivation of NetDx’s diagnosis primitives. DP: data plane. CP: control plane. V. NetDx’s PRIMITIVES & PROCEDURES NetDx is a proof-of-concept implementation of model-based diagnosis instantiated for IPv4/BGP networks. This section describes the instantiation of efficient diagnosis primitives and procedures for this network type. Implementation details are provided in §VI. A. NetDx’s Diagnosis Primitives Since packet… view at source ↗
Figure 2
Figure 2. NetDx’s diagnosis procedure. CAT: Configuration Analysis Tool. guide how diagnosis proceeds. For example, ACL deny drops in switch S1 of packets forwarded by switch S2 cause the diagnosis manager to query Batfish whether the traced packets should ever be forwarded by S2 to S1. A positive answer indicates that the problem (fault or configuration error) is on S1. A negative answer shifts the diagnosis focus to switch … view at source ↗
Figure 3
Figure 3. NetDx architecture. diagnosis manager from the configuration analysis tool. The diagnosis scripts are written manually, requiring an understanding of switch functionality, network protocols, and NetDx’s diagnosis primitives, Hence, the development of scripts involves significant human effort. However, this is a one-time cost; once the scripts are written, diagnosis of net￾work failures is automated. For example, App… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Topology of the network used in §VIII and §IX. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Diagnosis of packet drops due to no matching forwarding entry. SUT: Switch Under Test; FoI: Flow of Interest; PNSUT: Physical Neighbor of the [PITH_FULL_IMAGE:figures/full_fig_p014_5.png]
Figure 6
Figure 6. Figure 6: The architecture of an emulated switch. iptables. Thus, these packets are forwarded by the P4 simulator to the next hop. The FRR routing software running on the switch container installs routes into the routing table of the Linux kernel. FRR does this by sending a Netl…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 59 canonical work pages

  1. [1]

    https://www.cisco.com/c/en/us/products/ ios-nx-os-software/ios-netflow/index.html, Sept

    Cisco ios-netflow. https://www.cisco.com/c/en/us/products/ ios-nx-os-software/ios-netflow/index.html, Sept. 2022. Accessed: 2022- 9-21

    work page 2022

  2. [2]

    https://frrouting.org/, Sept

    Frrouting project. https://frrouting.org/, Sept. 2022. Accessed: 2022-9- 21

    work page 2022

  3. [3]

    https://p4.org/p4-spec/docs/INT v2 1.pdf, Sept

    In-band network telemetry. https://p4.org/p4-spec/docs/INT v2 1.pdf, Sept. 2022. Accessed: 2022-9-21

    work page 2022

  4. [4]

    https: //www.intel.com/content/www/us/en/products/network-io/ programmable-ethernet-switch/network-analytics/deep-insight.html, Sept

    Intel® deep insight network analytics software. https: //www.intel.com/content/www/us/en/products/network-io/ programmable-ethernet-switch/network-analytics/deep-insight.html, Sept. 2022. Accessed: 2022-9-21. 15 TABLE VII AN INSTANTIATED FUNCTIONAL MODEL OF FAULT -FREE AND FAULTY SWITCHES IMPLEMENTING IPV4 AND BGP PROTOCOLS . Packet Forwarding 𝐶𝑓𝑜𝑟𝑤𝑎𝑟𝑑 = ...

    work page 2022

  5. [5]

    https://man7.org/linux/man-pages/man7/netlink.7

    Manual of netlink. https://man7.org/linux/man-pages/man7/netlink.7. html, Sept. 2022. Accessed: 2022-9-21

    work page 2022

  6. [6]

    https://www.nsnam.org/, Sept

    Network simulator ns-3. https://www.nsnam.org/, Sept. 2022. Accessed: 2022-9-21

    work page 2022

  7. [7]

    https://github.com/p4lang/behavioral-model, Sept

    P4 behavioral model. https://github.com/p4lang/behavioral-model, Sept

    work page

  8. [8]

    https://p4.org/, Sept

    P4 programming language. https://p4.org/, Sept. 2022. Accessed: 2022- 9-21

    work page 2022

Show all 60 references
  1. [9]

    https://docs.aws.amazon.com/wellarchitected/latest/ reliability-pillar/availability.html/, 2023

    Availability in aws. https://docs.aws.amazon.com/wellarchitected/latest/ reliability-pillar/availability.html/, 2023. Accessed: 2023-2-2

    2023

  2. [10]

    https://podman.io/, 2023

    The pod manager tool. https://podman.io/, 2023. Accessed: 2023-2-2

    2023

  3. [11]

    Jean Arlat, Yves Crouzet, Johan Karlsson, Peter Folkesson, Emmerich Fuchs, and Gunther H. Leber. Comparison of physical and software- implemented fault injection techniques. IEEE Transactions on Comput- ers, 52(9):1115–1133, September 2003

    2003

  4. [12]

    Ns4: Enabling programmable data plane simulation

    Jiasong Bai, Jun Bi, Peng Kuang, Chengze Fan, Yu Zhou, and Cheng Zhang. Ns4: Enabling programmable data plane simulation. In SOSR ’18, pages 1–7, August 2018

    2018

  5. [13]

    A general approach to network configuration verification

    Ryan Beckett, Aarti Gupta, Ratul Mahajan, and David Walker. A general approach to network configuration verification. In SIGCOMM ’17, pages 155–168, August 2017

    2017

  6. [14]

    A General Approach to Network Configuration Verification

    Ryan Beckett, Aarti Gupta, Ratul Mahajan, and David Walker. A General Approach to Network Configuration Verification. In SIGCOMM ’17, SIGCOMM ’17, pages 155–168, August 2017

    2017

  7. [15]

    PINT: Probabilistic in- band network telemetry

    Ran Ben Basat, Sivaramakrishnan Ramanathan, Yuliang Li, Gianni An- tichi, Minian Yu, and Michael Mitzenmacher. PINT: Probabilistic in- band network telemetry. In SIGCOMM ’20 , pages 662–680, August 2020

    2020

  8. [16]

    BGP-Inspect - Extracting Information from Raw BGP Data

    Dionysus Blazakis, Manish Karir, and John S Baras. BGP-Inspect - Extracting Information from Raw BGP Data. In IEEE/IFIP NOMS 2006, pages 174–185, April 2006

    2006

  9. [17]

    P4: Programming Protocol-Independent Packet Processors

    Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. P4: Programming Protocol-Independent Packet Processors. Computer Communication Review, 44(3):88–95, July 2014

    2014

  10. [18]

    Mani Chandy and Leslie Lamport

    K. Mani Chandy and Leslie Lamport. Distributed Snapshots: Deter- mining Global States of Distributed Systems. ACM Transactions on Computer Systems, 3(1):63–75, February 1985

    1985

  11. [19]

    Chang, Eric Manning, and Gernot Metze

    Herbert Y . Chang, Eric Manning, and Gernot Metze. Fault Diagnosis of Digital Systems . Wiley-Interscience, New York, 1970

    1970

  12. [20]

    Automatic root cause analysis via large language models for cloud incidents

    Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, et al. Automatic root cause analysis via large language models for cloud incidents. arXiv preprint arXiv:2305.15778 [cs.SE] , 2024. 16

    2024 arXiv

  13. [21]

    Measuring and visualizing interdomain routing dynamics with BGPATH

    Luca Cittadini, Tiziana Refice, Alessio Campisano, Giuseppe Di Battista, and Claudio Sasso. Measuring and visualizing interdomain routing dynamics with BGPATH. In 2008 IEEE Symposium on Computers and Communications, pages 780–787, July 2008

    2008

  14. [22]

    Visualizing Interdomain Routing with BGPlay

    Lorenzo Colitti, Giuseppe Di Battista, Federico Mariani, Maurizio Pa- trignani, and Maurizio Pizzonia. Visualizing Interdomain Routing with BGPlay. Journal on Graph Algorithms and Applications , 9(1):117–148, 2005

    2005

  15. [23]

    Model-based diagnosis under real-world constraints

    Adnan Darwiche. Model-based diagnosis under real-world constraints. AI magazine, 21(2):57–57, 2000

    2000

  16. [24]

    Model based diagnosis for network communication faults

    Leliane Nunes de Barros, Marilza Lemos, V olnys Bernal, and Jacques Wainer. Model based diagnosis for network communication faults. In Proceedings of International Workshop on Artificial Intelligence for Distributed Information Networking (AIDIN’99) , 1999

    1999

  17. [25]

    Fundamentals of model-based diag- nosis

    Johan De Kleer and James Kurien. Fundamentals of model-based diag- nosis. IFAC Proceedings Volumes, 36(5):25–36, 2003

    2003

  18. [26]

    Ns4: A p4-driven network simulator

    Chengze Fan, Jun Bi, Yu Zhou, Cheng Zhang, and Haisu Yu. Ns4: A p4-driven network simulator. In SIGCOMM Posters and Demos ’17 , pages 105–107. August 2017

    2017

  19. [27]

    Fayaz, Tushar Sharma, Ari Fogel, Ratul Mahajan, Todd Mill- stein, Vyas Sekar, and George Varghese

    Seyed K. Fayaz, Tushar Sharma, Ari Fogel, Ratul Mahajan, Todd Mill- stein, Vyas Sekar, and George Varghese. Efficient Network Reachabil- ity Analysis using a Succinct Control Plane Representation. In 12th USENIX Symposium on Operating Systems Design and Implementation , pages ...

    2016

  20. [28]

    A General Approach to Network Configuration Analysis

    Ari Fogel, Stanley Fung, Luis Pedrosa, Meg Walraed-Sullivan, Ramesh Govindan, Ratul Mahajan, and Todd Millstein. A General Approach to Network Configuration Analysis. In NSDI ’15 , pages 469–483, May 2015

    2015

  21. [29]

    X- Trace: A Pervasive Network Tracing Framework

    Rodrigo Fonseca, George Porter, Randy H Katz, and Scott Shenker. X- Trace: A Pervasive Network Tracing Framework. In NSDI ’07 , April 2007

    2007

  22. [30]

    Dapper: Data plane performance diagnosis of TCP

    Mojgan Ghasemi, Theophilus Benson, and Jennifer Rexford. Dapper: Data plane performance diagnosis of TCP. In SOSR ’17, pages 61–74, April 2017

    2017

  23. [31]

    Why Do Computers Stop and What Can Be Done About It

    Jim Gray. Why Do Computers Stop and What Can Be Done About It. In 5th Symposium on Reliability in Distributed Software and Database Systems, pages 3–12, Los Angeles, CA, January 1986

    1986

  24. [32]

    Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis

    Chuanxiong Guo, Lihua Yuan, Dong Xiang, Yingnong Dang, Ray Huang, Dave Maltz, Zhaoyi Liu, Vin Wang, Bin Pang, Hua Chen, Zhi- Wei Lin, and Varugis Kurien. Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis. In SIGCOMM ’15, pages 139–152, August 2015

    2015

  25. [33]

    Sonata: Query-driven streaming network telemetry

    Arpit Gupta, Rob Harrison, Marco Canini, Nick Feamster, Jennifer Rexford, and Walter Willinger. Sonata: Query-driven streaming network telemetry. In SIGCOMM ’18, pages 357–371, August 2018

    2018

  26. [34]

    NetReview: Detecting when interdomain routing goes wrong

    Andreas Haeberlen, Ioannis Avramopoulos, Jennifer Rexford, and Peter Druschel. NetReview: Detecting when interdomain routing goes wrong. In NSDI ’09, pages 437–452, April 2009

    2009

  27. [35]

    Where is the debugger for my software- defined network? In HotSDN ’12, pages 55–60, August 2012

    Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, David Mazi´eres, and Nick McKeown. Where is the debugger for my software- defined network? In HotSDN ’12, pages 55–60, August 2012

    2012

  28. [36]

    I know what your packet did last hop: Using packet histories to troubleshoot networks

    Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, David Mazi`eres, and Nick McKeown. I know what your packet did last hop: Using packet histories to troubleshoot networks. In NSDI ’14 , pages 71–85, April 2014

    2014

  29. [37]

    Millions of little minions: Using packets for low latency network programming and visibility

    Vimalkumar Jeyakumar, Mohammad Alizadeh, Yilong Geng, Changhoon Kim, and David Mazi `eres. Millions of little minions: Using packets for low latency network programming and visibility. In SIGCOMM ’14, pages 3–14, August 2014

    2014

  30. [38]

    Barry W. Johnson. Design and Analysis of Fault-Tolerant Digital Sys- tems. Addison-Wesley, 1989

    1989

  31. [39]

    Header Space Analysis: Static Checking For Networks

    Peyman Kazemian, George Varghese, and Nick McKeown. Header Space Analysis: Static Checking For Networks. In 9th USENIX Sym- posium on Networked Systems Design and Implementation , pages 113– 126, San Jose, CA, April 2012

    2012

  32. [40]

    Lad, Lixia Zhang, and D

    M. Lad, Lixia Zhang, and D. Massey. Link-rank: A graphical tool for capturing bgp routing dynamics. In IEEE/IFIP NOMS 2004 , volume 1, pages 627–640, April 2004

    2004

  33. [41]

    A Network in a Laptop: Rapid Prototyping for Software-Defined Networks

    Bob Lantz, Brandon Heller, and Nick McKeown. A Network in a Laptop: Rapid Prototyping for Software-Defined Networks. In 9th ACM SIGCOMM Workshop on Hot Topics in Networks, pages 1–6, Monterey, CA, October 2010

    2010

  34. [42]

    FlowRadar: A Better NetFlow for Data Centers

    Yuliang Li, Rui Miao, Changhoon Kim, and Minlan Yu. FlowRadar: A Better NetFlow for Data Centers. In NSDI ’16, pages 311–324, March 2016

    2016

  35. [43]

    Lopes, Nikolaj Bjørner, Patrice Godefroid, Karthick Jayaraman, and George Varghese

    Nuno P. Lopes, Nikolaj Bjørner, Patrice Godefroid, Karthick Jayaraman, and George Varghese. Checking Beliefs in Dynamic Networks. In 12th USENIX Symposium on Networked Systems Design and Implementation, pages 499–512, Oakland, CA, May 2015

    2015

  36. [44]

    Brighten Godfrey, and Samuel Talmadge King

    Haohui Mai, Ahmed Khurshid, Rachit Agarwal, Matthew Caesar, P. Brighten Godfrey, and Samuel Talmadge King. Debugging the Data Plane with Anteater. In SIGCOMM ’11, pages 290–301, August 2011

    2011

  37. [45]

    Trumpet: Timely and precise triggers in data centers

    Masoud Moshref, Minlan Yu, Ramesh Govindan, and Amin Vahdat. Trumpet: Timely and precise triggers in data centers. In SIGCOMM ’16, pages 129–143, August 2016

    2016

  38. [46]

    Language-directed hardware design for network per- formance monitoring

    Srinivas Narayana, Anirudh Sivaraman, Vikram Nathan, Prateesh Goyal, Venkat Arun, Mohammad Alizadeh, Vimalkumar Jeyakumar, and Changhoon Kim. Language-directed hardware design for network per- formance monitoring. In SIGCOMM ’17, pages 85–98, August 2017

    2017

  39. [47]

    Ng and Peter M

    Wee T. Ng and Peter M. Chen. The systematic improvement of fault tolerance in the rio file cache. In 29th Fault-Tolerant Computing Sym- posium, pages 76–83, Madison, WI, June 1999

    1999

  40. [48]

    Medicine: Rapid prototyping of production-ready network services in multi-pop environ- ments

    Manuel Peuster, Holger Karl, and Steven Van Rossem. Medicine: Rapid prototyping of production-ready network services in multi-pop environ- ments. In 2016 IEEE NFV-SDN , pages 148–153, Nov 2016

    2016

  41. [49]

    Simplifying Datacenter Network Debugging with PathDump

    Praveen Tammana, Rachit Agarwal, and Myungjin Lee. Simplifying Datacenter Network Debugging with PathDump. In OSDI ’16 , pages 233–248, November 2016

    2016

  42. [50]

    Distributed Network Monitoring and Debugging with SwitchPointer

    Praveen Tammana, Rachit Agarwal, and Myungjin Lee. Distributed Network Monitoring and Debugging with SwitchPointer. In NSDI ’18, pages 453–456, April 2018

    2018

  43. [51]

    NetBouncer: Active Device and Link Failure Localization in Data Center Networks

    Cheng Tan, Ze Jin, Chuanxiong Guo, Tianrong Zhang, Haitao Wu, Karl Deng, Dongming Bi, and Dong Xiang. NetBouncer: Active Device and Link Failure Localization in Data Center Networks. In 16th USENIX Symposium on Networked Systems Design and Implementation , pages 599–614, February 2019

    2019

  44. [52]

    Thatte and Jacob A

    Satish M. Thatte and Jacob A. Abraham. A methodology for functional level testing of microprocessors. In 8th Fault-Tolerant Computing Sym- posium, pages 90–95, Toulouse, France, June 1978

    1978

  45. [53]

    Bingchuan Tian, Xinyi Zhang, Ennan Zhai, Hongqiang Harry Liu, Qiaobo Ye, Chunsheng Wang, Xin Wu, Zhiming Ji, Yihong Sang, Ming Zhang, Da Yu, Chen Tian, Haitao Zheng, and Ben Y . Zhao. Safely and Automatically Updating In-Network ACL Configurations with Intent Language. In SIGC...

    2019

  46. [54]

    NetAssistant: Dialogue based network diagnosis in data center networks

    Haopei Wang, Anubhavnidhi Abhashkumar, Changyu Lin, Tianrong Zhang, Xiaoming Gu, Ning Ma, Chang Wu, Songlin Liu, Wei Zhou, Yongbin Dong, Weirong Jiang, and Yi Wang. NetAssistant: Dialogue based network diagnosis in data center networks. In 21st USENIX Sym- posium on Networked ...

    2011

  47. [55]

    Closed-loop Network Performance Monitoring and Diagnosis with SpiderMon

    Weitao Wang, Xinyu Crystal Wu, Praveen Tammana, Ang Chen, and TS Eugene Ng. Closed-loop Network Performance Monitoring and Diagnosis with SpiderMon. In NSDI ’22, pages 267–285, April 2022

    2022

  48. [56]

    Synchronized Network Snapshots

    Nofel Yaseen, John Sonchack, and Vincent Liu. Synchronized Network Snapshots. SIGCOMM ’18, pages 402–416, August 2018

    2018

  49. [57]

    Accuracy, Scalability, Coverage: A Practi- cal Configuration Verifier on a Global W AN

    Fangdan Ye, Da Yu, Ennan Zhai, Hongqiang Harry Liu, Bingchuan Tian, Qiaobo Ye, Chunsheng Wang, Xin Wu, Tianchen Guo, Cheng Jin, Duncheng She, Qing Ma, Biao Cheng, Hui Xu, Ming Zhang, Zhiliang Wang, and Rodrigo Fonseca. Accuracy, Scalability, Coverage: A Practi- cal Configurati...

    2020

  50. [58]

    dShark: A General, Easy to Program and Scalable Framework for Analyzing In-network Packet Traces

    Da Yu, Yibo Zhu, Behnaz Arzani, Rodrigo Fonseca, Tianrong Zhang, Karl Deng, and Lihua Yuan. dShark: A General, Easy to Program and Scalable Framework for Analyzing In-network Packet Traces. In 16th USENIX Symposium on Networked Systems Design and Implementation, pages 207–220,...

    2019

  51. [59]

    Automatic Test Packet Generation

    Hongyi Zeng, Peyman Kazemian, George Varghese, and Nick McKe- own. Automatic Test Packet Generation. In 8th International Conference on Emerging Networking Experiments and Technologies , pages 241– 252, Nice, France, December 2012

    2012

  52. [60]

    Packet-level telemetry in large datacenter networks

    Yibo Zhu, Nanxi Kang, Jiaxin Cao, Albert Greenberg, Guohan Lu, Ratul Mahajan, Dave Maltz, Lihua Yuan, Ming Zhang, Ben Y Zhao, et al. Packet-level telemetry in large datacenter networks. In SIGCOMM ’15, pages 479–491, August 2015

    2015

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.