PaperlayerView exact revision on arXiv

Source-linked AI summary

An Exhaustive Survey on P4 Programmable Data Plane Switches: Taxonomy, Applications, Challenges, and Future Trends

Elie F. Kfoury, Jorge Crichigno, Elias Bou-Harb

arXiv:2102.00643v2cs.NI

TL;DR

Programmable data-plane research lacks a comprehensive synthesis of its evolution, architecture, P4 applications, challenges, and future directions. This paper surveys the field, builds a taxonomy from more than 150 articles, and concludes that open-source and deeply programmable architectures are likely to dominate future networks.

  • Problem

    The literature lacks a comprehensive synthesis of programmable data-plane architectures, P4 applications, comparative schemes, challenges, and future trends.

  • Method

    The paper conducts an exhaustive survey covering networking evolution, programmable-switch architecture, P4, application taxonomy, scheme comparisons, challenges, and future trends.

  • Results

    The survey organizes numerous P4 works into a taxonomy, compares schemes with one another and legacy approaches, and identifies future trends and initiatives.

  • Takeaways & Limitations

    The survey concludes that closed networks are likely to diminish as open-source and deeply programmable data-plane architectures become dominant.

  • Takeaways & Limitations

    P4 remains limited in supporting stateful variable-length protocols, an important issue for implementing some data-plane applications.

Abstract

from arXiv · show

Traditionally, the data plane has been designed with fixed functions to forward packets using a small set of protocols. This closed-design paradigm has limited the capability of the switches to proprietary implementations which are hardcoded by vendors, inducing a lengthy, costly, and inflexible process. Recently, data plane programmability has attracted significant attention from both the research community and the industry, permitting operators and programmers in general to run customized packet processing function. This open-design paradigm is paving the way for an unprecedented wave of innovation and experimentation by reducing the time of designing, testing, and adopting new protocols; enabling a customized, top-down approach to develop network applications; providing granular visibility of packet events defined by the programmer; reducing complexity and enhancing resource utilization of the programmable switches; and drastically improving the performance of applications that are offloaded to the data plane. Despite the impressive advantages of programmable data plane switches and their importance in modern networks, the literature has been missing a comprehensive survey. To this end, this paper provides a background encompassing an overview of the evolution of networks from legacy to programmable, describing the essentials of programmable switches, and summarizing their advantages over Software-defined Networking (SDN) and legacy devices. The paper then presents a unique, comprehensive taxonomy of applications developed with P4 language; surveying, classifying, and analyzing more than 150 articles; discussing challenges and considerations; and presenting future perspectives and open research issues.

I. INTRODUCTION … II. RELATED SURVEYS

The paper frames programmable data planes as a response to protocol ossification and vendor-locked packet processing, with P4 enabling faster, customizable forwarding development. It fills gaps in prior partial surveys through a comprehensive examination of programmable switches, applications, challenges, and future directions.

  • I. INTRODUCTION: Closed, proprietary networking hardware and standardized requirements caused protocol ossification, slowing innovation and limiting protocol flexibility.The VXLAN ASIC implementation illustrates the lengthy process that programmable approaches aim to shorten.
  • I. INTRODUCTION: SDN separated control and data planes and accelerated software-based control innovation, but vendors retained control over packet-processing functions.Programmable switches subsequently extended programmability into the data plane itself.
  • I. INTRODUCTION: P4 programmable switches let operators, engineers, researchers, and practitioners develop, test, and deploy protocol-independent forwarding behavior in shorter time spans.P4 is identified as the de-facto standard for defining forwarding behavior.
  • A. CONTRIBUTION: The paper addresses the absence of updated, comprehensive material by surveying network evolution, programmable-switch essentials, P4, comparative advantages, applications, challenges, and future perspectives.Its application taxonomy surveys more than 150 articles.
  • B. PAPER ORGANIZATION: The survey proceeds from traditional and SDN devices to programmable data planes, then covers programmable-switch features, PISA, methodology, applications, challenges, and future trends.The paper roadmap organizes these topics across successive sections.
  • II. RELATED SURVEYS: Earlier surveys addressed narrower topics, including P4 compilers, stateful data planes, programmable-network abstractions, SDN evolution, flexibility, monitoring, in-network computing, INT, and stateful applications.Their scopes and taxonomies varied, but each covered only selected aspects of programmable data planes.
  • II. RELATED SURVEYS: Previous surveys lacked microscopic comparisons within application categories and comparisons between switch-based and legacy server-based schemes.The authors therefore characterize this work as the first exhaustive exploration of the whole programmable data-plane ecosystem.

III. TRADITIONAL CONTROL PLANE AND SDN … V. METHODOLOGY AND TAXONOMY

The paper contrasts vendor-controlled traditional and SDN devices with user-programmable P4 switches, then explains PISA architecture, programmable-switch features, and a systematic taxonomy of the literature. The survey analyzes more than 200 works from 2016–2020, includes early 2021 studies, and organizes them into high-level disciplines and subcategories.

  • A. TRADITIONAL AND SDN DEVICES: Traditional networks run OSPF and BGP in vendor-controlled control and data planes, whereas SDN separates the planes and centralizes control through software.SDN controllers compute switch tables and distribute them through APIs such as OpenFlow.
  • B. COMPARISON OF TRADITIONAL, SDN, AND PROGRAMMABLE DATA PLANE DEVICES: P4 programmable devices let users define forwarding behavior, use protocol-independent primitives, and provide target-agnostic runtime interfaces across different targets.The same P4 program can run on different targets without modifying runtime applications.
  • C. NETWORK EVOLUTION AND ANALOGY WITH OTHER DOMAIN SPECIFIC PROCESSORS: PISA extends the broader evolution of domain-specific processors with networking-optimized instruction sets programmed through the high-level P4 language.PISA was designed as a machine model for networking and Protocol Independent Switch Architecture.
  • A. PISA ARCHITECTURE: PISA comprises a programmable parser, programmable match-action pipeline, and programmable deparser.The parser defines and parses custom or standard headers, while the pipeline executes operations using tables, registers, and ALUs.
  • A. PISA ARCHITECTURE: The P4 program defines lookup keys, while the control plane populates table entries with matching keys and corresponding action data.Keys may use packet-header information such as destination IP addresses, and actions may specify operations such as output ports.
  • B. PROGRAMMABLE SWITCH FEATURES: Programmable switches provide agility and top-down design, allowing programmers to develop, test, and adopt protocols and features in weeks or months rather than years.Their flexibility is accompanied by hardware trade-offs: additional stages can increase parallelism while consuming more chip area, power, and latency.
  • V. METHODOLOGY AND TAXONOMY: More than 200 data plane-related works from 2016 up to 2020 were surveyed, with important works from the first quarter of 2021 additionally included.The survey categorizes works by implementation platforms and designs a taxonomy covering significant data-plane programmability and P4 research.
  • V. METHODOLOGY AND TAXONOMY: The taxonomy was verified by correlating papers’ related work into high-level categories and subcategories, then comparing programmable approaches with contemporary and legacy alternatives.It also presents challenges, considerations, and current and future trends for the surveyed disciplines.

VI. IN-BAND NETWORK TELEMETRY (INT) · A. POSTCARD-BASED TELEMETRY (PBT) · B. INT VARIATIONS

Programmable switches enable precise, microsecond-scale in-band telemetry that exposes packet-level network state without control-plane intervention. The section contrasts INT with postcard-based and traditional telemetry, then surveys variations that reduce overhead through conditional reporting, probing, or probabilistic and selective insertion.

  • VI. IN-BAND NETWORK TELEMETRY (INT): Conventional tools provide millisecond-level accuracy at best and cannot capture microsecond events or per-packet visibility across congested networks.Examples include ping, traceroute, SNMP, NetFlow, and sFlow.
  • VI. IN-BAND NETWORK TELEMETRY (INT): INT queries switch state and reports fine-grained measurements such as queue occupancy, link utilization, and queuing latency at microsecond-scale resolution.Telemetry collection and reporting are performed entirely by the data plane.
  • VI. IN-BAND NETWORK TELEMETRY (INT): INT can reveal packet paths, forwarding rules, per-switch queue time, and flows sharing a queue, including under multipath routing.The INT source inserts headers and labels, intermediate switches add their labels, and the final switch strips headers before sending reports to a collector.
  • A. POSTCARD-BASED TELEMETRY (PBT): Postcard-based Telemetry avoids modifying user packets by having each traversed switch generate a postcard and send it to a monitor.INT instead augments user packets with switch-collected data, including forwarding paths, timestamps, and latency.
  • B. INT VARIATIONS: Unconditional INT adds headers to every packet, increasing bandwidth overhead and reducing throughput; event-based reports significantly decrease that overhead.P4 conditional statements can trigger reports only when events such as excessive queue utilization occur.
  • B. INT VARIATIONS: Telemetry designs face deployment and security trade-offs: manual configuration can hinder deployment, network-wide monitoring adds overhead, and INT is more vulnerable than PBT.INT offers simpler flow tracking, whereas PBT tolerates additional processing for security enhancements.
  • B. INT VARIATIONS: INT variations reduce overhead through probing, passive collection, dynamic header-frequency adjustment, multilayer encoding, and probabilistic insertion.NetVision and INT-Path actively send probes, standardized INT collects passively, sINT adjusts insertion frequency, and PINT probabilistically adds telemetry information.

C. INT COLLECTORS … A. CONGESTION CONTROL (CC)

The paper surveys INT collectors and programmable-switch congestion-control schemes, emphasizing high-performance telemetry processing, precise congestion feedback, and tradeoffs in deployment and scalability. It also contrasts INT’s fine-grained visibility with legacy monitoring and outlines limitations of current approaches.

  • C. INT COLLECTORS: INT collectors process, filter, and optionally store telemetry reports, making high performance essential because INT typically produces large report volumes.Collectors may analyze events and trigger control-plane actions, while accelerated implementations address the processing burden.
  • C. INT COLLECTORS: Open-source collectors include IntMon, Prometheus INT exporter, and INTCollector, while proprietary alternatives provide analytics such as anomaly, congestion, packet-drop, and latency analysis.IntMon controls monitored flows and metadata through a web interface; proprietary systems include Deep Insight and BroadView Analytics.
  • C. INT COLLECTORS: 57 times slower than Prometheus INT is IntMon, whereas INTCollector achieves the highest throughput and is 27 times faster than Prometheus INT exporter.The comparison attributes low processing rates of early collectors to the absence of kernel and hardware acceleration, alongside limited features.
  • D. SUMMARY AND LESSONS LEARNED: Legacy telemetry cannot capture microbursts or fine-grained measurements, whereas INT embeds high-precision switch-state data into packets for collector analysis and action.The collector can inform the control plane to update table entries.
  • VII. NETWORK PERFORMANCE: Low latency and high bandwidth are critical for modern data-intensive applications, making congestion control and active queue management important for avoiding overload and managing queues.The paper identifies congestion control as a central network-performance concern.
  • A. CONGESTION CONTROL (CC): Programmable-switch congestion-control methods are classified as hybrid CC, which provides network-assisted feedback to end hosts, or in-network CC, which acts without end-host modifications.Existing approaches span loss-based, model-based, ECN, and data-center-specific algorithms.
  • A. CONGESTION CONTROL (CC): HPCC uses INT-based precise link-load information and one rate update to achieve accurate flow rates, near-zero queueing, and almost parameterless operation.INT data is piggybacked into TCP/RDMA acknowledgements, enabling smart NICs to adjust sending rates.
  • A. CONGESTION CONTROL (CC): Congestion-control schemes face topology, scalability, evaluation, and security limitations, including NDP’s failure on asymmetric topologies under heavy load and queue-allocation constraints in P4Air.TCP pacing minimizes queuing delays but works well only with few large-flow senders; feedback mechanisms also require protection against packet modification.

B. MEASUREMENTS

Programmable switches overcome the coarse visibility and inflexibility of polling, sampling, and fixed-function monitoring by enabling customized, fine-grained measurements at line rate. The section surveys query-driven monitoring, performance diagnosis, queue visibility, and specialized metrics implemented with programmable data planes.

  • Background: Legacy polling and sampling methods provide only coarse-grained visibility because they use large polling intervals and limited sampling accuracy.Sampling may occur once every 30,000 packets.
  • Background: Programmable switches enable fine-grained, high-accuracy, line-rate measurements using customizable sketches, bloom filters, and reactive processing.These structures can be tailored to specific metrics of interest.
  • Performance Diagnosis Systems: Recent measurement systems diagnose TCP bottlenecks and failures, monitor queue occupancy and microbursts, and estimate traffic entropy using fine-grained data-plane visibility.Examples include Dapper, Blink, ConQuest, BurstRadar, and P4Entropy.
  • Generic Query-based Monitoring: OmniMon coordinates telemetry across programmable switches, end-hosts, and controllers, reducing memory by 33%-96% and actions by 66%-90% versus state-of-the-art solutions.The system combines data-plane accuracy with control-plane network-wide collaboration, synchronization, and accountability.
  • Generic Query-based Monitoring: Recency-aware monitoring addresses the inability of native streaming algorithms to represent time, enabling programmable ASICs to capture traffic trends relevant to monitoring and attack detection.Count-min sketch uses constant memory but is oblivious to the passage of time.
  • Generic Query-based Monitoring: Customized sketching and streaming algorithms can be implemented as P4 programs, allowing operators to modify monitoring algorithms as requirements change and thereby improve scalability.Query-driven interfaces can also convert monitoring requirements into deployable switch programs.

C. ACTIVE QUEUE MANAGEMENT (AQM)

Active Queue Management (AQM) addresses queueing delay and packet loss by preventing device buffers from becoming full, motivated by legacy devices’ limited visibility into queue occupancy and flow sharing.

  • C. ACTIVE QUEUE MANAGEMENT (AQM): AQM algorithms shorten queueing delay by preventing device buffers from becoming full.Researchers investigate queue management to reduce delay and packet losses while providing fairness among flows.
  • C. ACTIVE QUEUE MANAGEMENT (AQM): Legacy devices provide little or no insight into which flows occupy or share a queue.Large queue backlogs account for most delays encountered during communication sessions.

2) Standardized AQMs Implementation · D. QUALITY OF SERVICE AND TRAFFIC MANAGEMENT · E. MULTICAST

Programmable switches support diverse AQM, QoS, traffic-management, and multicast mechanisms, while enabling customized packet processing and faster deployment than fixed-function devices. These approaches improve fairness, latency, utilization, scalability, and flexibility, but implementation complexity and hardware limitations remain important constraints.

  • 2) Standardized AQMs Implementation: Programmable switches implement standardized AQMs including CoDel, AFQ, PIE, PI2, RED, and combinations of these schemes.CoDel eliminates Bufferbloat, AFQ approximates fair queuing at line rate, and PI2 supports coexistence between classic and scalable congestion controls.
  • 2) Standardized AQMs Implementation: AQMs require parameter and threshold tuning under some network conditions, making schemes with many such controls harder to manage and less autonomous.Programmable switches shorten AQM deployment from a process that might take years on fixed-function devices to one that can be completed in weeks.
  • 2) Standardized AQMs Implementation: CoDel and PI2 are relatively simple to implement, whereas FQ requires complex flow classification, per-packet scheduling, and buffer allocation that make hardware deployment expensive.AFQ approximates fair queuing using per-flow state, basic calculations, switch-state mutation, and egress-queue selection.
  • D. QUALITY OF SERVICE AND TRAFFIC MANAGEMENT: Programmable switches support QoS and traffic management by classifying, metering, marking, prioritizing, and routing traffic according to application headers, QoS demands, flow rates, and tenancy requirements.Reported systems include layer-5-aware routing, two-level queues, congestion-window adjustment after threshold marking, RL-SP-DRR scheduling, and multi-color traffic marking.
  • D. QUALITY OF SERVICE AND TRAFFIC MANAGEMENT: QoS/TM implementations remain uneven across targets: was implemented on a Tofino hardware switch, while was implemented only on BMv2 and was not implemented on hardware.RL-SP-DRR uses multiple priority queues supported by hardware targets, whereas the virtual-network solution focused on bandwidth isolation and priority differentiation.
  • D. QUALITY OF SERVICE AND TRAFFIC MANAGEMENT: Unlike legacy networks restricted to standard header fields, programmable switches can inspect customized headers and extract high-granularity metadata for traffic management.This programmability enables operators to express traffic-management logic in a programming language and perform customized protocol processing.
  • E. MULTICAST: P4-based multicast encodes group membership or multicast trees in packet headers, reducing or eliminating per-group switch state and signaling protocols.ELMO targets scalable multi-tenant datacenter applications, while BIER removes per-multicast group state and does not require signaling to build, manage, or tear down trees.
  • E. MULTICAST: PAM provides preemptive, decentralized multicast rate control by using priority-encoded scheduling headers and real-time link loads to allocate rates adaptively.Its scheduling operates at RTT scales and addresses changing bandwidth, fault tolerance, scalability, and file-transfer completion times.

F. SUMMARY AND LESSONS LEARNED … B. CACHING

The surveyed P4 applications include network monitoring, programmable middleboxes, switch-based load balancing, and in-network caching. These approaches improve programmability and performance but face deployment, overhead, and hardware-feasibility considerations.

  • F. SUMMARY AND LESSONS LEARNED: Network-wide monitoring uses streaming methods, data structures such as sketches and bloom filters, approximation algorithms, and query-based languages to specify monitoring tasks.Future measurement work should consider generalizing monitoring approaches.
  • VIII. MIDDLEBOX FUNCTIONS: Legacy middleboxes are manufacturer-designed and therefore limited in functionality, typically providing standard functions such as NAT and protocol conversion.RFC 3234 defines a middlebox as a device performing nonstandard functions between source and destination hosts.
  • A. LOAD BALANCING: Stateful P4 load balancing stores connection information in the switch dataplane to map connections consistently to servers without a software layer.The majority of proposed approaches are stateful and store information locally for load-balancing decisions.
  • A. LOAD BALANCING: Active probing in schemes such as HULA, MP-HULA, and Contra supplies network metrics for decisions but increases bandwidth overhead and may degrade performance.HULA can also make sub-optimal decisions for multiple subflows sharing a bottleneck, motivating multipath-aware schemes.
  • A. LOAD BALANCING: Stateless load balancing avoids per-connection state in the switch, using backend connection state, packet marking, or utilization-based weights instead.Beamer, SHELL, and W-ECMP exemplify these alternatives.
  • B. CACHING: Hot-item skew in key-value stores creates load and latency challenges because popular items receive more queries and their popularity can change rapidly.Modern applications may require thousands of storage accesses to retrieve a single web page.
  • B. CACHING: In-network caching stores hot items in programmable switches, serves hits locally, and forwards misses to the appropriate storage server.NetCache, IncBricks, and AppSwitch apply programmable switching to key-value storage, while other schemes target applications such as NDN, industrial control, and DNS.
  • B. CACHING: 2 billion queries per second: NetCache handled 64,000 items with 16-bytes keys and 128-bytes values, improving throughput by 3-10 times and reducing 40% of queries’ latency by 50%.Switch-based caching also has order-of-magnitude higher throughput than general-purpose servers and reduces latency by 50%, but hardware feasibility is not always certain.

C. TELECOMMUNICATION SERVICES · D. CONTENT-CENTRIC NETWORKING

Programmable switches offload 5G, media-relay, and content-centric networking functions to the data plane, improving performance and enabling application-specific packet processing. These systems support high-throughput pub/sub and NDN use cases, but remain constrained by switch memory and P4’s handling of stateful variable-length protocols.

  • C. TELECOMMUNICATION SERVICES: Programmable switches offload 5G functions including backhaul processing, firewalling, packet-core signaling, SGW/PGW integration, and UPF implementation.These designs target 5G requirements for ultra-reliable low latency and jitter at microseconds-scale.
  • C. TELECOMMUNICATION SERVICES: Telecom schemes generally offload x86-server functionality to the data plane to improve latency and throughput while targeting 5G KPIs.TurboEPC specifically offloads a significant portion of packet-core signaling messages to improve control-plane throughput and latency.
  • C. TELECOMMUNICATION SERVICES: 18% and 25% reductions in handover time were achieved for two- and three-handover sequences, respectively, compared with legacy approaches.SMARTHO uses programmable switches to perform wireless-network handovers efficiently.
  • C. TELECOMMUNICATION SERVICES: Nanoseconds-scale latency and jitter, improved packet loss, CPU usage, MOS, and scalability beyond one million concurrent sessions were achieved for offloaded VoIP media.The programmable-switch relay replaces x86-based servers whose latency and jitter were milliseconds-scale.
  • D. CONTENT-CENTRIC NETWORKING: Content-centric networking addresses named data rather than named hosts, while publish/subscribe provides scalable and robust communication between information producers and consumers.Packet subscription evaluates stateful predicates, and other systems encode notification distribution trees in packet headers.
  • D. CONTENT-CENTRIC NETWORKING: NDN.p4 and related P4-based CDN systems provide request caching, content stores, scalable forwarding, and application-driven data-plane configuration.These efforts adapt Named Data Networking and content delivery to programmable-switch implementations.
  • D. CONTENT-CENTRIC NETWORKING: 6.5 Tbps line-rate processing used the full capacity of a Tofino switch for a Nasdaq ITCH publish/subscribe use case.A BDD-based compiler generated P4 tables from logical predicates, simplifying configuration by avoiding manual table-entry installation.
  • D. CONTENT-CENTRIC NETWORKING: Switch-based pub/sub significantly reduces latency and variation, but switch memory limits distributed data and P4 struggles with stateful variable-length protocols.Adaptive, application-programmable designs address some limitations of other P4-based CDN schemes.

E. SUMMARY AND LESSONS LEARNED … B. MACHINE LEARNING

The surveyed applications show programmable switches supporting middlebox functions, network-accelerated computation, consensus, and machine-learning training and inference. Results include reduced coordination latency, substantially higher consensus throughput, accelerated ML aggregation, and ongoing constraints from switch resources and computation limits.

  • E. SUMMARY AND LESSONS LEARNED: Programmable switches support middlebox functions including caching, load balancing, service offloading, and publish/subscribe brokering.These applications customize data-plane behavior beyond standard router and switch capabilities.
  • E. SUMMARY AND LESSONS LEARNED: In-network caches can serve hot items at line rate, while telecom offloading and publish/subscribe remain open to improvements in scalability, reliability, retention, and QoS.Suggested directions include item compression, communication minimization, more concurrent sessions, packet-delivery guarantees, message retaining, and QoS differentiation.
  • IX. NETWORK-ACCELERATED COMPUTATIONS: Programmable switches enable upper-layer logic to run in the ASIC as in-network computation, potentially improving throughput by an order of magnitude or more over software applications.Switch ASICs are designed to process packets at terabits per second rates.
  • A. CONSENSUS: Network acceleration targets consensus because conventional protocols incur expensive coordination and latency overhead on every request.Programmable-switch designs include P4-based NOPaxos, P4 Paxos, NetChain, Eris, and P4BFT, while full Paxos remains difficult under data-plane constraints.
  • A. CONSENSUS: P4xos reduced latency by three times compared to traditional approaches and processed over 2.5 billion consensus messages per second.The system was implemented on a Tofino hardware switch, with the reported throughput representing four orders of magnitude improvement.
  • A. CONSENSUS: 340ns was the reported minimum latency for a Paxos coordinator when consensus messages were processed on the wire, compared with 96us for a traditional CPU-based coordinator.Network-assisted consensus deployments also require fewer hops than legacy deployments.
  • B. MACHINE LEARNING: In-network ML training systems aggregate worker updates on switches, and SwitchAgg reduced job completion time by as much as 50%.SwitchML provided a complete hardware-switch implementation for synchronous stochastic gradient descent, using streaming, work partitioning, quantization, and failure recovery to address design challenges.
  • B. MACHINE LEARNING: In-network inference includes simplified neural-network processing, Binary Neural Network compilation, and other ML models, but full-fledged models face extensive computation demands and resource or accuracy limitations.N2Net targets bitwise BNN operations, while IIsy is limited in algorithm scope, packet-header features, and classification accuracy.

SERVER-BASED ML … A. AGGREGATION

The surveyed applications use programmable switches to accelerate machine-learning computation and packet aggregation, while facing hardware, memory, encryption, latency, and flexibility constraints. The paper also identifies broader in-network applications and future opportunities across consensus, machine learning, and IoT networking.

  • SERVER-BASED ML: Switch-based ML inference can execute at line rate and provide faster client results, although complex computations rely on estimations.The literature divides ML applications into expedited data-plane inference and accelerated network training.
  • SERVER-BASED ML: Offloading aggregation to a centralized switch can significantly accelerate distributed training, but limited switch memory cannot store an entire model update.Encrypted traffic remains challenging when inference or training is handled by the switch.
  • D. SUMMARY AND LESSONS LEARNED: Programmable-switch delegation improves tasks such as consensus and machine-learning model training despite switches supporting only basic, limited operations.This trend is emerging in data centers and backbone networks.
  • D. SUMMARY AND LESSONS LEARNED: In-network consensus implementations mainly provide simplified Paxos or Raft variants because of hardware constraints, motivating novel algorithms and failure-recovery mechanisms.Current schemes do not implement the full complexity of these protocols.
  • D. SUMMARY AND LESSONS LEARNED: Switch aggregation of model updates and classification of new samples have produced significant ML performance improvements, with future work spanning classification, regression, and clustering.Other data-plane applications include stream and parallel processing, string searching, erasure coding, lock management, database-query acceleration, compression, and computer-vision offloading.
  • X. INTERNET OF THINGS (IOT): IoT applications involve many constrained devices periodically sending sensor readings to remote collectors for processing and analysis.Examples include smart water utilities, smart grids, smart manufacturing, smart gas, and smart metering.
  • A. AGGREGATION: IoT packets often contain small payloads with proportionally large headers; Sigfox supports 12-byte payloads while Ethernet, IP, and UDP headers total 42 bytes.This overhead motivates aggregating multiple payloads into one larger packet.
  • A. AGGREGATION: Switch-based IoT aggregation reduces header bandwidth overhead and, on ASICs, delivers higher throughput with lower latency and jitter than server-based approaches, whereas servers offer greater aggregation flexibility.Legacy CPU or control-plane aggregation increases end-to-end latency and decreases throughput; P4 switches store payloads in registers, later transmit aggregated packets, and disaggregate them near the server.

B. SERVICE AUTOMATION … A. HEAVY HITTER

The surveyed P4 applications automate IoT services, inspect packets at line rate for cybersecurity, and detect heavy hitters with localized or network-wide schemes. These approaches improve scalability, reachability, latency, energy use, detection accuracy, and reaction speed, while exposing protocol, communication, memory, and operational limitations.

  • B. SERVICE AUTOMATION: BLESS encodes IoT service transactions in the data plane, while Muppet extends it to support multiple non-IP protocols.BLESS maintains link-layer connections for peer-to-peer connectivity; Muppet uses an ONOS-based control plane with the Protocol Independent framework.
  • B. SERVICE AUTOMATION: Switch-based service automation combines P2P-like low energy and latency with improved scalability and reachability.The approach is presented as overcoming the principal limitations of both P2P and cloud-based automation.
  • C. SUMMARY AND LESSONS LEARNED: IoT packet aggregation reduces header bandwidth overhead by combining several small packets into a larger packet, but its delay, jitter, loss, and retransmission effects require study.A P4 switch aggregates and encapsulates packets, while another switch disaggregates them across the WAN.
  • C. SUMMARY AND LESSONS LEARNED: Service automation encodes IoT application transactions in the data plane, with future work targeting translators for non-IP protocols and production-grade software switches for non-Ethernet devices.These directions aim to let applications using different protocols exchange data.
  • XI. CYBERSECURITY: Programmable switches support cybersecurity functions including heavy-hitter detection, traffic engineering, DDoS mitigation, anonymity, and cryptography.They can inspect upper layers, including the application layer, at line rate.
  • A. HEAVY HITTER: Heavy hitters are a small number of flows carrying most traffic, contributing to congestion and increasing completion times for delay-sensitive mice flows.Prompt detection enables reactions such as redirecting heavy hitters to a low-priority queue.
  • A. HEAVY HITTER: Heavy-hitter schemes span local and network-wide detection, trading deterministic error-free reporting against communication costs or probabilistic reporting with negligible communication costs.HashPipe and Elastic Trie detect local heavy or hierarchical flows, while other approaches address distributed detection and incremental deployment alongside legacy devices.
  • A. HEAVY HITTER: 80KB of memory identified the 300 heaviest flows with 95% accuracy in HashPipe’s evaluation on a CAIDA ISP trace containing 400,000 flows.Data-structure selection governs the memory-accuracy tradeoff, with hash tables and sketches frequently used for heavy-flow counters.

B. CRYPTOGRAPHY · C. PRIVACY AND ANONYMITY · D. ACCESS CONTROL

The surveyed P4 applications extend programmable switches to cryptography, privacy and anonymity, and access control, while exposing tradeoffs involving computational complexity, deployment, throughput, and security limitations. These approaches enable in-network protection and policy enforcement at line rate, but often rely on constrained primitives, recirculation, or partial deployment.

  • B. CRYPTOGRAPHY: B. CRYPTOGRAPHY: Cryptographic operations are useful for integrity, encryption, and collision mitigation, but their complexity exceeds the basic arithmetic supported by many P4 targets.The surveyed work therefore explores external cryptographic functions, data-plane implementations, and delegated processing.
  • B. CRYPTOGRAPHY: B. CRYPTOGRAPHY: CRC is easier and less complex than SHA-256 but is insecure and has a high collision rate, while CPU hashing has several milliseconds of latency.SmartNICs provide the highest throughput among the evaluated cryptographic-hash platforms, according to the passage.
  • B. CRYPTOGRAPHY: B. CRYPTOGRAPHY: AES data-plane processing performs two AES rounds per switch pipeline and completes AES-128’s 10 rounds in five pipeline passes through recirculation.Recirculation is limited by loopback-port bandwidth, although the Tofino implementation attained 10Gbps throughput.
  • C. PRIVACY AND ANONYMITY: C. PRIVACY AND ANONYMITY: Programmable-switch systems target low-latency, lightweight, and partially deployable anonymity through traffic anonymization, identity protection, and topology obfuscation.These approaches address performance and deployability limitations associated with volunteer-operated overlays and architecture-wide changes.
  • C. PRIVACY AND ANONYMITY: C. PRIVACY AND ANONYMITY: ONTAS protects personally identifiable information with an operator policy language, while PANEL supports partial deployment alongside legacy devices through source-address rewriting and normalization.SPINE encrypts IP addresses and TCP sequence and acknowledgment numbers, whereas ASIC implementation would require three pipeline passes and decrease throughput by a factor of three.
  • D. ACCESS CONTROL: D. ACCESS CONTROL: Programmable switches can authenticate and authorize traffic at line rate before it reaches servers, reducing server-side verification work and network or software-processing latency.The surveyed mechanisms include stateful P4 firewalls, port knocking, context-aware policies, and operating-system fingerprinting.
  • D. ACCESS CONTROL: D. ACCESS CONTROL: P4Guard provides policy-based filtering through the transport layer, while deep packet inspection can exceed traditional firewall visibility but may lose line rate when parsing more bytes.Port-knocking authentication is vulnerable to IP spoofing and packet sniffing because programmable switches do not use cryptographic hashes and unencrypted knocking exposes packets.
  • D. ACCESS CONTROL: D. ACCESS CONTROL: Software-based passive operating-system fingerprinting causes 38% degradation in throughput, whereas switch hardware can fingerprint hosts and apply policies at line rate.The data-plane approach still lacks sophisticated policies involving traffic rate-limiting.

E. DEFENSES

P4 data-plane defenses address escalating, high-volume DDoS threats while avoiding the throughput, latency, jitter, and last-mile limitations of end-host and server-based mechanisms. Existing approaches span attack-specific and generic schemes, but constrained switch capabilities, external dependencies, and unresolved limitations remain important challenges.

  • Background DDoS attacks: Recent DDoS attacks have reached terabits per second, exceeding the capacity of existing defense mechanisms.Their frequency, volume, and rate make DDoS attacks persistent security concerns.
  • Background DDoS attacks: End-host and x86-based middlebox defenses degrade throughput and increase latency and jitter, while last-mile deployment can severely affect network operation.These limitations motivate moving defense functions into the data plane, closer to attack traffic.
  • Defense Schemes Comparison, Discussions, and Limitations: Defense schemes comprise attack-specific mechanisms, such as NETHCF for spoofed IP traffic, and generic mechanisms addressing multiple attacks concurrently.Examples include SYN-flood tracking, distributed SIP-DDoS mitigation, FastFlex, ML-Pushback, Poseidon, and unified volumetric and stealthy-DDoS defenses.
  • Defense Schemes Comparison, Discussions, and Limitations: Constrained programmable switches cannot easily perform extensive computations, requiring approximation or delegation to CPUs, servers, or controllers.Approximation introduces a computation-complexity and measurement-accuracy trade-off, while delegation can add deployment costs and latency.
  • Defense Schemes Comparison, Discussions, and Limitations: Network-wide defenses improve detection accuracy and promptness through cooperation among multiple switches, while existing schemes retain limitations for future work.Jaqen executes fully in the switch and uses universal sketches, addressing external-support limitations identified for Poseidon.

F. SUMMARY AND LESSONS LEARNED … B. VERIFICATION

The surveyed work applies programmable switches to cybersecurity and develops testing and verification methods to manage the risks of customizable data-plane programs. These methods span passive monitoring, probing, static analysis, symbolic execution, and runtime verification, while facing trade-offs in coverage, scalability, memory, and deployment safety.

  • F. SUMMARY AND LESSONS LEARNED: Programmable switches support cybersecurity goals including heavy-hitter detection, data-plane cryptography, privacy protection, access control, and in-network defenses.These applications aim to detect and counter heavy hitters, execute cryptographic primitives, protect identities and topology, enforce policies, and accelerate defenses.
  • F. SUMMARY AND LESSONS LEARNED: Data-plane cryptography is necessary for applications requiring low hashing collisions and strong data protection, although complex computations are often delegated to the control plane.Recent systems nevertheless demonstrate that AES can be implemented in the data plane.
  • A. TROUBLESHOOTING: Troubleshooting schemes either passively track packet processing or inject probes, but passive detection cannot check table rules that existing packets have not triggered.Probing-based methods address broader rule coverage, while passive methods depend on observed packet behavior.
  • A. TROUBLESHOOTING: P4Tester generates probes from intermediate representations and table rules, using source routing to achieve high rule coverage with low overhead on a Tofino prototype.The supplied passage reports that P4Tester can check all rules efficiently and uses fewer probes than the comparison approach.
  • A. TROUBLESHOOTING: P4DB provides three operator-oriented debugging primitives—watch, break, and next—and was evaluated on BMv2 with a small throughput penalty and little latency increase.Unlike probing systems, P4DB assumes packets consistently trigger the runtime bugs and does not require modifying the data-plane implementation.
  • B. VERIFICATION: Static verification checks P4 programs before deployment, whereas runtime verification uses passive measurements and proactive network testing to detect runtime faults.The distinction reflects the inability of static verification to detect faults that occur only during execution.
  • B. VERIFICATION: Verification tools employ assertions, Hoare logic, symbolic execution, generated test cases, reinforcement learning, and runtime monitoring to identify P4 program bugs and enforce intended behavior.Examples include ASSERT-P4, p4v, p4pktgen, Vera, P4RL, and bf4, which address compile-time, testing, scalability, or runtime enforcement concerns.

3) Verification Schemes Discussions … C. ARITHMETIC COMPUTATIONS

The paper surveys verification approaches for programmable data planes and identifies limitations and future directions involving network autonomy, memory capacity, resource accessibility, and arithmetic computation.

  • 3) Verification Schemes Discussions: Switch.p4 is the most commonly evaluated program, while P4RL detects path-related consistency between data and control planes.Switch.p4 includes Layer 2/3 functionality, ACL, QoS, and other cloud data-center networking features.
  • 3) Verification Schemes Discussions: Verification schemes analyze P4 programs directly because traditional tools cannot accommodate customized forwarding behavior without internal reprogramming.Some schemes translate P4 programs into verification languages or models, such as Datalog or GCL with Z3.
  • C. SUMMARY AND LESSONS LEARNED: P4-based testing and measurement support troubleshooting and correctness verification, enabling future autonomous or self-healing networks.Measurements collected through P4 switches can provide inputs for control loops and zero-touch or knowledge-defined networking.
  • XIII. CHALLENGES AND FUTURE TRENDS: The paper organizes research and operational challenges from its taxonomy and identifies initiatives and future trends for programmable switches.These challenges and trends are summarized in Fig. 23.
  • A. MEMORY CAPACITY (SRAM AND TCAM): Stateful processing enables applications such as in-network caching, fine-grained measurement, and stateful load balancing, but on-chip memory is limited to tens to hundreds of megabytes.Applications store and retrieve data across packets, while available switch memory constrains stateful functionality.
  • A. MEMORY CAPACITY (SRAM AND TCAM): Memory size creates performance and functionality trade-offs: caching hit rate depends on capacity, while measured-flow scope and information richness depend on available memory.Measurement applications commonly store data-plane statistics such as byte and packet counters.
  • B. RESOURCES ACCESSIBILITY: Disaggregating memory and compute could remove per-stage memory constraints and sequential execution by using centralized memory and processor clusters.Existing programmable-switch hardware generally follows the RMT model, so hardware implementation and analysis of disaggregation remain future work.
  • C. ARITHMETIC COMPUTATIONS: Arithmetic computation is constrained by simple non-floating-point operations, few per-packet operations, tens-of-nanoseconds pipeline budgets, and substantial hardware-resource consumption.Approximation and pre-computation can address these limits, but approximation sacrifices precision; square roots can be approximated by counting leading zeros with longest-prefix matching.

D. NETWORK-WIDE COOPERATION … H. PROGRAMMING SIMPLICITY

The paper surveys challenges and future directions for coordinating programmable switches, limiting control-plane dependence, securing data-plane programs, interoperating with legacy infrastructure, and simplifying P4 programming. Across these areas, it emphasizes distributed state management, automated tooling, incremental deployment, and hardware-aware development.

  • D. NETWORK-WIDE COOPERATION: Switch cooperation can share network-wide state locally, but continuous software-controller communication motivates direct switch-to-switch message exchange.Centralized SDN management enables shared state and better decisions, while software-system packet exchange creates an architectural drawback.
  • D. NETWORK-WIDE COOPERATION: Frequent state migration can add traffic and authentication overhead; P4Sync reports 2.15ms for RSA-2048 signing and 0.07ms for verification.P4Sync guarantees complete snapshot transfer, avoids repeatedly retransmitted updates, and adapts migration traffic to changing network conditions.
  • E. CONTROL PLANE INTERVENTION: Control-plane intervention increases latency, especially when data-plane limitations prevent direct table updates during rerouting or collision-free hashing.Future tools should detect excessive control/data-plane interaction and suggest alternative workflows or generated code; failure detection, notification, and connectivity retrieval can be delegated to the data plane.
  • F. SECURITY: Sensitivity attacks exploit intelligently crafted traffic patterns that trigger unexpected data-plane behavior, making manual discovery of defenses unreliable, time consuming, and error-prone.Recent efforts aim to automatically derive traffic patterns that drive programs away from common-case behavior.
  • G. INTEROPERABILITY: Incremental P4 deployment alongside legacy devices avoids immediate infrastructure replacement, but partial deployment can reduce application effectiveness through limited flow visibility.Heavy hitter detection accuracy is strongly affected by flow visibility, motivating algorithms that optimize incremental placement.
  • G. INTEROPERABILITY: Network taps let P4 switches analyze legacy-device traffic without fully replacing infrastructure, supporting RTT estimation, telemetry, and DDoS detection or mitigation.Taps preserve timing information and packet order, while P4 processing enables fine-grained queue monitoring and microburst observation beyond legacy routers’ coarse statistics.
  • H. PROGRAMMING SIMPLICITY: P4 programming is difficult because programs contain bugs, hardware resources are restricted, and development relies on trial and error under low-level limitations.Programmable switches also require operators to have programming experience, unlike earlier fixed-function ASIC environments.
  • H. PROGRAMMING SIMPLICITY: Future research should simplify operator workflows through graphical-to-P4 translation and code generation that fits target hardware.P4All explores compact elastic programs that stretch across available resources, extending P4 with loops and compiling target-constrained programs, but remains far from practical deployment.

I. DEEP PROGRAMMABILITY … XIV. CONCLUSIONS

The paper envisions deeply programmable, modular, and increasingly autonomous networks, while identifying challenges in line-rate portability, isolation, practical testing, and human involvement. It concludes by surveying programmable data planes, presenting a P4 taxonomy, and discussing challenges and future directions.

  • I. DEEP PROGRAMMABILITY: Deep programmability distributes software-defined network behavior across programmable switches, NICs, virtual switches, accelerators, and end-host networking stacks.Operators describe functions such as routing and congestion control as software, while XDP and BPF accelerate kernel packet forwarding.
  • I. DEEP PROGRAMMABILITY: A central deep-programmability challenge is writing clean code that can move across hardware pipelines while operating at line rate.The control plane manages programmable switches, NICs, and virtual switches through P4 and runtime APIs such as P4Runtime.
  • J. MODULARITY AND VIRTUALIZATION: Multiple network functions must coexist on one physical switch without causing connectivity loss or service downtime when data-plane programs change.Cloud providers also seek to expose on-switch network functions as services to diverse customers.
  • J. MODULARITY AND VIRTUALIZATION: Modular P4 programs and virtualization must provide resource, performance, and security isolation while supporting dynamic integration of multiple services.Hyper4 dynamically configures a general-purpose P4 program by translating P4 programs into table entries, whereas HyperVDP and P4Visor latency is determined by the highest-latency P4 program.
  • K. PRACTICAL TESTING: Practical testing remains difficult because simulations and CPU-bound emulations lack the performance or measurement accuracy of production networks at high traffic rates.Smaller-scale emulation testbeds can also produce results that differ from production networks.
  • K. PRACTICAL TESTING: TurboNet uses programmable switches to emulate production networks at scale and line rate by slicing one switch into multiple port- and queue-separated switches.P4Campus promotes hardware-switch experimentation by replaying campus traffic against production data and pursuing multiple targets, virtualization, and topologies.
  • L. HUMAN INVOLVEMENT: Network automation requires real-time observation, on-the-fly behavior generation, and verification to close the loop toward self-driving or zero-touch operation.Programmable switches enable microburst detection, visualization, and per-packet examination, but completely automating networks remains difficult.
  • XIV. CONCLUSIONS: The survey traces networking’s evolution to programmable data planes, explains PISA and P4, presents a taxonomy comparing research with legacy approaches, and identifies challenges and future initiatives.Its conclusion frames programmable data planes as a response to the closed nature of contemporary networks.
Loading 2102.00643v2…