Papers
Topics
Authors
Recent
Search
2000 character limit reached

Araucaria: Simplifying INC Fault Tolerance with High-Level Intents

Published 17 Apr 2024 in cs.NI and cs.DC | (2404.11728v1)

Abstract: Network programmability allows modification of fine-grain data plane functionality. The performance benefits of data plane programmability have motivated many researchers to offload computation that previously operated only on servers to the network, creating the notion of in-network computing (INC). Because failures can occur in the data plane, fault tolerance mechanisms are essential for INC. However, INC operators and developers must manually set fault tolerance requirements using domain knowledge to change the source code. These manually set requirements may take time and lead to errors in case of misconfiguration. In this work, we present Araucaria, a system that aims to simplify the definition and implementation of fault tolerance requirements for INC. The system allows requirements specification using an intent language, which enables the expression of consistency and availability requirements in a constrained natural language. A refinement process translates the intent and incorporates the essential building blocks and configurations into the INC code. We present a prototype of Araucaria and analyze the end-to-end system behavior. Experiments demonstrate that the refinement scales to multiple intents and that the system provides fault tolerance with negligible overhead in failure scenarios.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (48)
  1. Supporting diverse dynamic intent-based policies using janus. In Proceedings of the 13th International Conference on Emerging Networking EXperiments and Technologies, CoNEXT ’17, page 296–309, New York, NY, USA, 2017. Association for Computing Machinery.
  2. Sdn heading north: Towards a declarative intent-based northbound interface. In 2020 16th International Conference on Network and Service Management (CNSM), pages 1–5. IEEE, 2020.
  3. Reducing p4 language’s voluminosity using higher-level constructs. In Proceedings of the 5th International Workshop on P4 in Europe, pages 19–25, 2022.
  4. Nlp4: An architecture for intent-driven data plane programmability. In 2022 IEEE 8th International Conference on Network Softwarization (NetSoft), pages 25–30. IEEE, 2022.
  5. Cheetah: A high-speed programmable load-balancer framework with guaranteed per-connection-consistency. IEEE/ACM Transactions on Networking, 30(1):354–367, 2021.
  6. P4: Programming protocol-independent packet processors. SIGCOMM Comput. Commun. Rev., 44(3):87–95, July 2014.
  7. New directions in cloud programming. In 11th Conference on Innovative Data Systems Research (CIDR’ 21), 2021.
  8. Intent-Based Networking - Concepts and Definitions. RFC 9315, October 2022.
  9. The ponder policy specification language. In International Workshop on Policies for Distributed Systems and Networks, pages 18–38. Springer, 2001.
  10. Charting an intent driven network. In 2017 13th International Conference on Network and Service Management (CNSM), pages 1–5. IEEE, 2017.
  11. A behavior-driven approach to intent specification for software-defined infrastructure management. In 2018 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), pages 1–6, Nov 2018.
  12. P4 weaver: Supporting modular and incremental programming in p4. In Proceedings of the ACM SIGCOMM Symposium on SDN Research (SOSR), pages 54–65, 2021.
  13. Simplification of the design, deployment, and testing of 5g vertical services. In NOMS 2020-2020 IEEE/IFIP Network Operations and Management Symposium, pages 1–7. IEEE, 2020.
  14. Lyra: A cross-platform language and compiler for data plane programming on heterogeneous asics. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 435–450, 2020.
  15. Towards executing computer vision functionality on programmable network devices. In Proceedings of the 1st ACM CoNEXT Workshop on Emerging in-Network Computing Paradigms, pages 15–20, 2019.
  16. Intent-driven composition of resource-management sdn applications. CoNEXT ’18, page 86–97, New York, NY, USA, 2018. Association for Computing Machinery.
  17. Linearizability: A correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems (TOPLAS), 12(3):463–492, 1990.
  18. Modular switch programming under resource constraints. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 193–207, 2022.
  19. Hypersfp: Fault-tolerant service function chain provision on programmable switches in data centers. In NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, pages 1–9. IEEE, 2022.
  20. Refining network intents for self-driving networks. In Proceedings of the Afternoon Workshop on Self-Driving Networks, SelfDN 2018, page 15–21, New York, NY, USA, 2018. Association for Computing Machinery.
  21. Netchain: Scale-free sub-rtt coordination. In 15th {normal-{\{{USENIX}normal-}\}} Symposium on Networked Systems Design and Implementation ({normal-{\{{NSDI}normal-}\}} 18), pages 35–49, 2018.
  22. Redplane: enabling fault-tolerant stateful in-switch applications. In Proceedings of the 2021 ACM SIGCOMM 2021 Conference, pages 223–244, 2021.
  23. Iot device fingerprinting on commodity switches. In NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, pages 1–9. IEEE, 2022.
  24. A survey on intent based networking. IEEE Communications Surveys & Tutorials, 2022.
  25. Using p4 to enable scalable intents in software defined networks. In 2018 IEEE 26th International Conference on Network Protocols (ICNP), pages 442–443, 2018.
  26. Eris: Coordination-free consistent transactions using in-network concurrency control. In Proceedings of the 26th Symposium on Operating Systems Principles, pages 104–120, 2017.
  27. Automatic policy generation for {{\{{Inter-Service}}\}} access control of microservices. In 30th USENIX Security Symposium (USENIX Security 21), pages 3971–3988, 2021.
  28. Arkham: an advanced refinement toolkit for handling service level agreements in software-defined networking. Journal of Network and Computer Applications, 90:1–16, 2017.
  29. The programmable data plane: Abstractions, architectures, algorithms, and applications. ACM Computing Surveys (CSUR), 54(4):1–36, 2021.
  30. A survey on intent-driven networks. IEEE Access, 8:22862–22873, 2020.
  31. Netgvt: offloading global virtual time computation to programmable switches. In Proceedings of the Symposium on SDN Research, pages 16–24, 2022.
  32. Exploiting commutativity for practical fast replication. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), pages 47–64, 2019.
  33. Pga: Using graphs to express and automatically reconcile network policies. In Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, SIGCOMM ’15, pages 29–42, New York, NY, USA, 2015. ACM.
  34. P4i/o: Intent-based networking with p4. In 2019 IEEE Conference on Network Softwarization (NetSoft), pages 438–443. IEEE, 2019.
  35. Intent-based networks: An industrial perspective. In Proceedings of the 1st International Workshop on Future Industrial Communication Networks, pages 35–40, 2018.
  36. In-network computation is a dumb idea whose time has come. In Proceedings of the 16th ACM Workshop on Hot Topics in Networks, HotNets-XVI, page 150–156, New York, NY, USA, 2017. Association for Computing Machinery.
  37. Scaling distributed machine learning with in-network aggregation. In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21), pages 785–808. USENIX Association, April 2021.
  38. Inspire: Integrated nfv-based intent refinement environment. In 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), pages 186–194. IEEE, 2017.
  39. A controlled natural language to support intent-based blockchain selection. In 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–9. IEEE, 2020.
  40. Conflict-free replicated data types. In Stabilization, Safety, and Security of Distributed Systems: 13th International Symposium, SSS 2011, Grenoble, France, October 10-12, 2011. Proceedings 13, pages 386–400. Springer, 2011.
  41. Towards network-accelerated ml-based distributed computer vision systems. In 2021 IEEE 27th International Conference on Parallel and Distributed Systems (ICPADS), pages 122–129, 2021.
  42. Composing dataplane programs with μ𝜇\muitalic_μp4. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 329–343, 2020.
  43. Accelerator-aware in-network load balancing for improved application performance. In 2022 IFIP Networking Conference (IFIP Networking), pages 1–9. IEEE, 2022.
  44. Safely and automatically updating in-network acl configurations with intent language. In Proceedings of the ACM Special Interest Group on Data Communication, pages 214–226. 2019.
  45. Safely and automatically updating in-network acl configurations with intent language. In Proceedings of the ACM Special Interest Group on Data Communication, SIGCOMM ’19, page 214–226, New York, NY, USA, 2019. Association for Computing Machinery.
  46. Reactive configuration updating for intent-based networking. In 2017 International Conference on Information Networking (ICOIN), pages 97–102. IEEE, 2017.
  47. {{\{{SwiSh}}\}}: Distributed shared state abstractions for programmable switches. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), pages 171–191, 2022.
  48. Noa Zilberman. In-network computing, Apr 2019. https://www.sigarch.org/in-network-computing-draft [Accessed: Feb 22 2024].

Summary

No one has generated a summary of this paper yet.

Sign Up to Summarize

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

Plain-English Summary of “Araucaria: Simplifying INC Fault Tolerance with High-Level Intents”

Overview

This paper introduces Araucaria, a tool that helps make “in‑network computing” (INC) more reliable when things go wrong. INC means performing some computing tasks inside network devices (like smart switches) instead of on regular servers. This can make systems faster, but it also makes them more complicated and harder to fix when a device fails. Araucaria lets people describe what kind of reliability they want using simple, high-level rules (called “intents”), and then automatically builds and configures the network code to meet those rules.

Key Objectives

The paper focuses on three simple goals:

  • Make it easier to set up and manage fault tolerance (how a system keeps working when parts fail) for INC.
  • Allow operators to express what they want (like “keep working even if two switches fail” or “keep data consistent across backups”) in human-friendly language.
  • Automatically translate those high-level requests into the detailed switch code and settings that enforce them, and prove it works fast and at scale.

How Did They Do It? (Methods and Approach)

Think of a network like a sports team:

  • The main switch is the star player.
  • Backup switches are substitutes ready to step in.
  • A “coordinator” is the coach who notices when the star goes down and directs recovery.
  • The “intent” is like a simple instruction from the manager (e.g., “always have two substitutes” or “make sure all players keep the same score”).

Araucaria works in three main steps:

  1. Intent language and translation
    • Operators write what they need using a constrained natural language (clear, structured phrases), such as:
      • “tolerates two failures” (availability)
      • “consistency: strong” (replicas must process things in the same order)
      • Or “consistency: eventual [merge: max]” (replicas can temporarily differ, but will later agree by picking the largest value).
    • Araucaria compiles this intent and turns it into a plan with building blocks.
  2. Instrumenting the INC code
    • The INC code is written in P4, a language for programming network devices.
    • Araucaria automatically inserts reusable “building blocks” into the P4 program:
      • Failure detector: notices when the main switch crashes.
      • Replication: sends copies of relevant packets or state to backup switches.
      • State collection: figures out how current each backup is.
      • Recovery: restores backups to a correct state, depending on the chosen consistency model.
    • It carefully merges these blocks into the existing switch program (parser, control flow, headers) without breaking anything, like adding new modules into a game engine.
  3. Configuration and deployment
    • Araucaria sets up network rules (like multicast groups and mirror ports) so packets are copied to backups.
    • It configures servers to replay lost packets if needed and applies merge functions for conflict resolution (e.g., choosing the highest timestamp).
    • When a crash happens, the coordinator triggers recovery by switching traffic to a backup and replaying or merging data so everything is consistent again.

Technical terms explained in everyday language:

  • “P4”: a programming language to teach network devices exactly how to handle packets.
  • “BMv2” and “Tofino”: different platforms that run P4 programs (BMv2 is a software simulator; Tofino is real hardware).
  • “Strong consistency”: all backups process things in exactly the same order (like a synchronized dance).
  • “Eventual consistency”: backups might temporarily disagree, but will later match (like friends syncing notes after class).
  • “CRDT and merge functions”: smart data types and rules that let different versions combine safely (e.g., picking the largest counter value) without reordering everything.

Main Findings

The authors tested Araucaria in simulations and on real hardware and found:

  • Fast recovery after failures: on a real Tofino switch, systems recovered in about 0.16 seconds on average.
  • Scalable translation: converting high-level intents into concrete configurations is quick, even at large scale (e.g., 800 intents translated in about 0.20 seconds).
  • Flexible recovery strategies:
    • Sending periodic snapshots plus replaying lost packets (strong consistency) is slower when many servers are involved (up to ~7 seconds with 8 servers).
    • Sending all packets to replicas plus replaying a few lost ones is faster (around ~4 seconds with 8 servers) because fewer replays are needed.
    • Using smart merge functions and CRDTs (strong eventual consistency) is fastest (under ~2 seconds), because you don’t need to reorder or replay lots of packets—conflicts are resolved by rules like “pick the biggest timestamp.”
  • Low overhead: Araucaria adds very little extra work to the switch. It uses a small number of rules and P4 primitives (like cloning and recirculation), so performance remains high.

Why It Matters (Implications)

Araucaria helps bridge the gap between what operators want and the complex code needed to enforce it. In practical terms:

  • It makes networks with in‑network computing safer and more reliable without requiring deep programming expertise.
  • It speeds up recovery after failures, which can be critical for systems like online services, data centers, or IoT networks.
  • It proves that high-level, intent-based approaches can control detailed, programmable data planes—making future network management simpler, faster, and less error-prone.

In short, Araucaria shows that you can ask the network for reliability in plain words and get strong, automatic protections—turning complicated fault tolerance into something easy to use and quick to deploy.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a concise list of unresolved issues, assumptions, and missing analyses that future research could address to strengthen and generalize Araucaria.

  • Failure model coverage is limited to crash faults; there is no treatment of byzantine behavior, partial failures (e.g., link/port outages), network partitions, packet corruption, or resource exhaustion in the data plane and control plane.
  • Coordinator resilience is not addressed; the coordinator appears to be a single point of failure with no redundancy, leader election, or failover mechanism.
  • Failure detection is based on timeouts without analysis of detection accuracy, false positives/negatives, or tuning under varying latency and loss; the 16–18 s recovery window in emulation suggests significant detection latency that is not optimized or explained.
  • Strong consistency semantics are not formally specified; Araucaria relies on client-side replay and logical clocks without proofs of linearizability or ordering guarantees across replicas, especially under concurrent multi-server traffic.
  • CRDT/merge function correctness is not verified; there is no formal method to check that user-specified merge functions actually ensure SEC and preserve application invariants.
  • The constrained intent language is narrow (availability, strong/eventual consistency, simple merges like max/add) and lacks constructs for performance targets, resource constraints, topology constraints, fault scopes, or compositional policies across multiple functionalities.
  • Intent conflict resolution, prioritization, and composition are not detailed; how multiple intents for different INCs interact, override, or conflict in shared environments is left unspecified.
  • Assurance mechanisms are minimally described; there is no systematic feedback loop, violation detection, or automated re-refinement strategy when configurations drift from intents.
  • Instrumentation relies on naming conventions and preprocessor includes without formal composition guarantees; there is no static verification that parser/control-flow rewrites are loop-free, non-ambiguous, and preserve original INC semantics for complex P4 programs.
  • General applicability across diverse INC workloads is not demonstrated; evaluation is limited to NetGVT (logical clock sync) and does not cover non-commutative state, per-flow load balancing, KV stores, aggregation, or service chains with more complex state interactions.
  • Data-plane state synchronization is packet-centric; how register state (e.g., counters, tables) is captured, snapshotted, and reconciled generically across replicas is unclear, especially beyond simple packet replay.
  • Bandwidth and latency overhead of replication, cloning, and recirculation in the steady state are not measured; impact on application throughput and tail latency under normal operation is unknown.
  • Resource scaling on hardware is untested at realistic sizes; P4 memory/register budgets, clone/multicast session limits, pipeline stage constraints, and compile-time limits are only measured on small topologies (45 hosts, 2 switches).
  • Topology assumptions are simplistic; replication via multicast is evaluated on single-hop setups without considering multi-hop paths, ECMP, asymmetric routes, loop prevention, and heterogeneous ASIC capabilities.
  • Partition and split-brain scenarios are not considered; the system lacks protocols to avoid dual primaries, reconcile divergent replica histories, or safely promote replicas under partitions.
  • Primary selection and failover criteria are not specified; policies for choosing the new main INC (e.g., health, freshness, proximity, resource load) are absent.
  • Security is not addressed; there are no mechanisms for authenticating coordinator–switch–server communications, preventing malicious replay/merge misuse, or ensuring integrity/confidentiality of replication traffic.
  • Idempotency and duplicate suppression during replay are not discussed; without guarantees, recovery can introduce duplicate effects for non-idempotent operations.
  • Portability beyond BMv2 and Tofino is untested; compatibility with other ASICs/targets and interaction with cross-platform abstractions (e.g., Lyra) is not evaluated.
  • Dynamic updates and live re-instrumentation are not covered; how Araucaria handles intent changes at runtime without disrupting traffic or consistency is unclear.
  • Monitoring and observability are under-specified; the nature, frequency, and semantics of telemetry exported to assurance, and how operators debug inconsistencies or recovery progress, remain open.
  • Quantitative comparison to prior INC fault-tolerance systems (e.g., RedPlane, Swish) is missing; there is no head-to-head evaluation of recovery time, consistency guarantees, overhead, or scalability.
  • Compiler and deployment pipeline performance is only partially measured; translation time is reported, but instrumentation time, P4 compile time, and deployment latency (especially on Tofino) are not.
  • Intent example correctness and language semantics need tightening; Listing 1 shows an incomplete parameter (size:) and inconsistent naming (“syncIntent” vs “syncnIntent”), indicating gaps in specification clarity and validation tooling.
View Paper Prompt  View All Prompts 

Open Problems

We found no open problems mentioned in this paper.

Continue Learning

We haven't generated follow-up questions for this paper yet.

Generate Now

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 2 tweets with 0 likes about this paper.

Sign Up for Free