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

The literature lacked an exhaustive synthesis of programmable data planes, including their evolution, architecture, applications, challenges, and future trends. This paper surveys and classifies P4-based work in a comprehensive taxonomy, compares schemes with legacy approaches, and identifies challenges and future directions.

  • Problem

    The literature lacked an exhaustive synthesis of programmable data-plane evolution, architectures, P4 applications, challenges, and future trends.

    Source: §XIV · pp. 53–54

  • Method

    The paper surveys programmable data planes, presents a P4 application taxonomy, compares schemes with legacy approaches, and discusses challenges and future trends.

    Source: §XIV · pp. 53–54

  • Results

    The survey organizes numerous significant P4 works into a taxonomy, compares schemes within categories and against legacy approaches, and identifies open challenges and future trends.

    Source: §XIV · p. 54

  • Takeaways & Limitations

    The survey concludes that closed networks will diminish as open-source and deeply programmable architectures become dominant.

    Source: §XIV · p. 54

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

    Source: D. CONTENT-CENTRIC NETWORKING · p. 29

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 presents P4 programmable switches as an evolution beyond closed, vendor-controlled networking that enables faster protocol innovation, while offering a comprehensive survey of their ecosystem, applications, comparisons, challenges, and future directions. It addresses gaps in prior surveys through detailed taxonomy and cross-work comparisons, including against legacy server-based approaches.

I. INTRODUCTION

  • Closed proprietary networking caused protocol ossification, slow innovation, and lengthy hardware design cycles, exemplified by VXLAN’s ASIC implementation taking years rather than weeks in software.SDN separated control and data planes and accelerated control-plane innovation but did not transfer packet-processing control from vendors.Source: §I · pp. 1–2
  • P4 programmable forwarding removes the vendor-controlled entry barrier by enabling operators, engineers, and researchers to rapidly design, test, deploy, and reprogram packet-processing behavior.P4 is described as the de-facto language for protocol-independent packet processors and as a natural evolution of SDN.Source: §I · p. 2
  • The P4 ecosystem spans operators, hyperscale data centers, switch and chip manufacturers, research backbones, and testbeds using programmable platforms without compromising performance.Examples include FABRIC, SDX, and 2STiC, alongside commercial deployments and products.Source: §I · p. 2

A. CONTRIBUTION

  • The survey fills a literature gap by explaining the transition from legacy and SDN devices to programmable switches, introducing P4 and PISA, and analyzing more than 200 articles.It also presents a P4 application taxonomy and discusses challenges, considerations, future perspectives, and open research issues.Source: A. CONTRIBUTION · p. 2

B. PAPER ORGANIZATION

  • The paper proceeds from related-survey comparison and network evolution to programmable-switch architecture, methodology, application taxonomy, category comparisons, challenges, future directions, and conclusions.The roadmap is illustrated in Fig. 2.Source: B. PAPER ORGANIZATION · p. 2, Figure 2 · p. 3

II. RELATED SURVEYS

  • Prior surveys examined P4 compilers, stateful data planes, SDN evolution, and data-plane flexibility, but their coverage remained limited in scope or critical discussion.Stubbe et al. surveyed P4 compilers and interpreters, while Dargahi et al. covered stateful data planes and security; Satapathy et al. briefly described SDN evolution and P4 elements.Source: §II · pp. 3–4
  • Existing surveys generally lack critical discussion of P4 features, broad application coverage, challenges, future work, or detailed explanations of how reviewed papers differ.Some surveys also omit relevant application categories or focus narrowly on security, INT, stateful data planes, or selected management functions.Source: §II · pp. 3–4
  • This work claims the first exhaustive exploration of the programmable data-plane ecosystem, adding microscopic intra-category comparisons and comparisons between P4 switch-based and legacy server-based schemes.It provides a detailed application taxonomy, evaluates applications within categories, and derives challenges and future perspectives.Source: §II · pp. 3–4, Table 1 · p. 3

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

The paper contrasts vendor-controlled traditional and SDN devices with programmable P4 switches, then introduces PISA architecture, programmable-switch features, and a systematic taxonomy of more than 200 works. The taxonomy organizes research across disciplines, compares approaches with contemporary and legacy systems, and identifies challenges and future directions.

A. TRADITIONAL AND SDN DEVICES

  • Traditional networks run OSPF and BGP in vendor-controlled control and data planes, whereas SDN centralizes control in a software controller but retains a fixed-function data plane.SDN distributes controller-computed tables through APIs such as OpenFlow.Source: A. TRADITIONAL AND SDN DEVICES · pp. 4–5

B. COMPARISON OF TRADITIONAL, SDN, AND PROGRAMMABLE DATA PLANE DEVICES

  • P4 switches let users define forwarding behavior with protocol-independent primitives, target-agnostic runtime interfaces, parallel match-action stages, and runtime reprogrammability, although their maturity and support remain limited.The same P4 program can run on different targets without runtime-application modifications.Source: B. COMPARISON OF TRADITIONAL, SDN, AND… · p. 5

C. NETWORK EVOLUTION AND ANALOGY WITH OTHER DOMAIN SPECIFIC PROCESSORS

  • Networking follows the broader evolution from domain-specific processors to PISA, whose network-optimized instruction sets are programmed with the high-level P4 language.The paper relates PISA to CPUs, DSPs, GPUs, and TPUs developed for other specialized workloads.Source: C. NETWORK EVOLUTION AND ANALOGY WITH… · p. 5

A. PISA ARCHITECTURE

  • PISA combines a programmable parser, match-action pipeline, and deparser to parse custom or standard headers, process them, and serialize reconstructed packets.The pipeline uses tables, registers, and ALUs for simultaneous lookups and actions, while sequential stages handle dependencies.Source: A. PISA ARCHITECTURE · p. 5
  • P4 defines lookup-key formats while the control plane populates table entries with keys and action data for packet matching and operations such as selecting an output port.Keys can be formed from packet-header information, including destination IP addresses.Source: A. PISA ARCHITECTURE · p. 5

B. PROGRAMMABLE SWITCH FEATURES

  • Programmable switches provide agility, top-down protocol design, protocol independence, target independence, and parallel processing, while additional stages can increase chip area, power consumption, and latency.The compiler converts target-independent P4 into target-dependent binaries, and P4_16 broadens support to ASICs, FPGAs, and NICs.Source: B. PROGRAMMABLE SWITCH FEATURES · pp. 5–7

V. METHODOLOGY AND TAXONOMY

  • More than 200 data-plane research works from 2016–2020, supplemented by first-quarter 2021 works, were surveyed across software, ASIC, NetFPGA, and SmartNIC platforms.The vast majority were implemented on software and hardware switches; behavioral software switches support prototyping, whereas non-behavioral switches can be production-grade.Source: Figure 5 · p. 6, §V · pp. 7–8
  • The taxonomy separates surveyed P4 and data-plane programmability works into high-level and sub-categories, verifies assignments through related-work examination, and compares approaches with contemporary and legacy systems.Hardware-switch adoption is increasing, but acquiring Tofino platforms can require an NDA, training, and costly development support; the survey also identifies challenges and future trends.Source: Figure 6 · p. 7, §V · pp. 8–9

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

Programmable data-plane telemetry provides fine-grained, microsecond-scale visibility and data-plane reactions beyond conventional monitoring, while PBT and INT variations reduce overhead or adapt collection to application needs.

VI. IN-BAND NETWORK TELEMETRY (INT)

  • INT captures per-packet network state at microsecond scale and enables immediate data-plane reactions, addressing the accuracy and visibility limits of conventional monitoring.It can measure queue occupancy, link utilization, and queuing latency without control-plane intervention, supporting actions such as rerouting congested flows.Source: §VI · p. 9
  • INT reports can reveal packet paths, forwarding rules, per-switch queue time, and flows sharing a queue.The INT source inserts instructions, transit hops add metadata, and the sink removes headers before delivery to upper-layer applications.Source: §VI · p. 9

A. POSTCARD-BASED TELEMETRY (PBT)

  • PBT preserves user packets by having each switch generate programmable postcards for events such as flow boundaries, sampling, drops, or congestion.A monitor receives the postcards instead of extracting telemetry carried inside user packets.Source: Figure 9 · p. 9, A. POSTCARD-BASED TELEMETRY (PBT) · p. 10

B. INT VARIATIONS

  • Probing-based systems such as NetVision, INT-Path, and NetView provide application-specific or network-wide telemetry, but probes may differ from actual traffic conditions.INT-Path uses Euler-trail path planning for non-overlapping probe paths, while NetView targets on-demand, full-coverage, scalable telemetry.Source: B. INT VARIATIONS · pp. 10–11
  • INT-variation deployment depends on configuration simplicity, monitoring scope, and hardware fit because network-wide monitoring adds overhead and software implementations may not fit hardware pipelines.Some solutions still require manual operator intervention to configure telemetry processes.Source: B. INT VARIATIONS · pp. 10–11
  • INT offers richer, more granular, push-based tracking than legacy monitoring but is more vulnerable to eavesdropping and tampering, whereas PBT simplifies security processing at the cost of report correlation and delay.INT bandwidth overhead is significant for every-packet reporting but decreases substantially with event-based reports.Source: B. INT VARIATIONS · pp. 11–12
  • INT variations reduce telemetry overhead through probes, selective flow or packet sampling, probabilistic encoding, or other adaptive collection schemes.These approaches target applications that need approximate telemetry rather than per-packet, per-hop information, but sampling and anomaly-based monitoring can lose information.Source: B. INT VARIATIONS · pp. 10–11

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

The survey reviews INT collectors and programmable-network performance methods, emphasizing accelerated telemetry processing and congestion control based on fine-grained, in-network measurements. It classifies congestion control into hybrid and in-network approaches while identifying performance advantages and deployment limitations.

C. INT COLLECTORS

  • INT collectors parse, filter, analyze, and optionally store telemetry reports; INTCollector accelerates processing with XDP and separates fast-path report processing from normal-path event storage.High-performance collectors are needed because INT generates large numbers of reports, and collectors may run as open- or closed-source systems.Source: C. INT COLLECTORS · p. 12
  • 27 times faster than Prometheus INT exporter, INTCollector achieved the highest throughput, while IntMon was 57 times slower than Prometheus INT exporter.Figure 10 compares CPU efficiency across IntMon, Prometheus INT exporter, and INTCollector.Source: C. INT COLLECTORS · pp. 12–13, Figure 10 · p. 12

D. SUMMARY AND LESSONS LEARNED

  • INT provides fine-grained switch-state visibility for microbursts, but its telemetry volume motivates overhead–accuracy tradeoffs, accelerated collectors, and future work on compression, coverage, information richness, and deployment simplicity.Collectors analyze embedded telemetry and can trigger control-plane actions; INT collectors commonly use XDP or DPDK-style acceleration to handle traffic at Kpps scale.Source: D. SUMMARY AND LESSONS LEARNED · p. 13, C. INT COLLECTORS · p. 13

A. CONGESTION CONTROL (CC)

  • Programmable-network congestion control comprises hybrid schemes that provide network-assisted feedback to end hosts and in-network schemes that reroute, steer, or control traffic without end-host modifications.The broader network-performance discussion links congestion control and queue management to low latency, high bandwidth, and avoiding network overload.Source: A. CONGESTION CONTROL (CC) · p. 13, §VII · p. 13
  • Hybrid methods use mechanisms including NACKs, packet trimming, pacing, ECN, and INT feedback, while in-network methods reroute flows, separate congestion-control groups, share buffers, or extend QCN to IP-routed networks.Examples include NDP, NCF, TCP pacing, EECN, backup-path rerouting, FAB, and P4QCN.Source: A. CONGESTION CONTROL (CC) · pp. 13–14
  • HPCC uses INT-based precise link-load and queue information to compute flow rates with one update, enabling near-zero queueing, few parameters, and promising latency, bandwidth, and convergence results.Switches piggyback INT metadata into TCP/RDMA acknowledgements, and smart NICs use it to adjust sending rates; HPCC was not evaluated against Internet algorithms such as CUBIC or BBR.Source: A. CONGESTION CONTROL (CC) · pp. 13–14
  • Key limitations include NDP’s asymmetric-topology failures and retransmissions, NCF’s manual tuning and absent implementation results, pacing’s dependence on few large-flow senders, and P4QCN’s lack of hardware evaluation.P4Air improves fairness but requires queues per congestion-control group despite limited switch queues, while feedback mechanisms require security against packet modification.Source: A. CONGESTION CONTROL (CC) · pp. 14–15
  • Compared with end-host inference and one-bit legacy ECN, programmable switches provide prompt, fine-grained congestion measurements that improve detection accuracy, reduce queueing, and accelerate convergence, but require network support and parameters.End-host schemes avoid infrastructure changes, whereas ECN-enabled devices and programmable switches use parameters such as marking thresholds.Source: A. CONGESTION CONTROL (CC) · pp. 13, 15

B. MEASUREMENTS

The section surveys programmable-switch measurement schemes that overcome the coarse, fixed, and inflexible nature of legacy polling, sampling, streaming, and INT-based measurements. It organizes work around query-driven monitoring, performance diagnosis, queue and other metrics, and customizable in-network processing.

Background

  • Programmable switches provide fine-grained, line-rate, customizable measurements and reactive processing, unlike legacy polling and sampling schemes that offer only coarse-grained visibility.Legacy methods cannot accurately track rapidly changing TCP fields such as congestion window, receive window, and sending rate.Source: B. MEASUREMENTS · p. 15

Generic Query-based Monitoring

  • Query-driven systems translate changing monitoring requirements into switch programs or control-plane execution, spanning FlowRadar, UnivMon, Marple, Sonata, PacketScope, and BeauCoup.These systems use counters, sketches, dataflow operators, and heterogeneous-query abstractions to trade accuracy, generality, and resource use.Source: B. MEASUREMENTS · p. 16

Performance Diagnosis Systems

  • Performance-diagnosis systems use line-rate telemetry to identify TCP bottlenecks, retransmission failures, latency degradation, or top-k problematic flows, with reactive rerouting or rate limiting.Dapper, Blink, SpiderMon, and the approach in diagnose different failure signals and trigger corresponding responses.Source: B. MEASUREMENTS · pp. 16, 18

Queue and Other Metrics Measurement

  • Queue-focused systems measure queue occupancy and microbursts, while other schemes estimate traffic entropy and TCP RTT for congestion, attack detection, SLA, and QoE applications.ConQuest identifies queue-heavy flows, BurstRadar detects microbursts, P4Entropy estimates Shannon entropy, and [95] passively measures ISP TCP RTT.Source: B. MEASUREMENTS · pp. 16–17

Measurements Schemes Comparison, Discussions, and Limitations

  • OmniMon reduces memory by 33%-96% and actions by 66%-90% versus state-of-the-art solutions through coordinated split-merge telemetry across switches, end-hosts, and controllers.The design combines high-accuracy per-flow measurements with network-wide control-plane collaboration.Source: B. MEASUREMENTS · pp. 17–18

In-Network versus Legacy Measurements

  • Programmable switches let operators customize sketches and streaming algorithms as P4 programs, improving scalability beyond metric-specific hardware while supporting event-based monitoring and flexible data-plane processing.Time-adaptive sketches implement recency using data-plane bit shifts and control-plane de-emphasis, addressing programmable-ASIC constraints on timers, loops, and stages.Source: B. MEASUREMENTS · pp. 18–19

C. ACTIVE QUEUE MANAGEMENT (AQM)

Active queue management (AQM) reduces queueing delay, packet loss, and bufferbloat, addressing limitations in legacy queue visibility and equipment support. P4-programmable switches enable customizable AQM implementations and faster experimentation with new algorithms.

Background

  • Legacy devices provide little or no visibility into which flows occupy or share a queue, motivating queue-management research.Large queue backlogs account for much of the delay in communication sessions.Source: C. ACTIVE QUEUE MANAGEMENT (AQM) · p. 19
  • AQM algorithms prevent buffers from becoming full to reduce queueing delay, mitigate packet loss, and improve fairness among flows.Bufferbloat increases end-to-end delay and jitter while decreasing throughput; modern AQMs target this problem.Source: C. ACTIVE QUEUE MANAGEMENT (AQM) · p. 19
  • P4 programs make it possible to implement AQMs on programmable switches, customize parameters in response to traffic, and rapidly test newer algorithms.CoDel, proposed in 2013 and shown effective against Bufferbloat, remains unavailable in most network equipment.Source: C. ACTIVE QUEUE MANAGEMENT (AQM) · p. 19

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

Programmable P4 switches support implementable and customizable queueing, QoS, traffic-management, and multicast mechanisms, while reducing dependence on fixed-function devices and signaling state. Their practical limitations include hardware processing complexity, parameter tuning, and incomplete hardware implementations for several approaches.

2) Standardized AQMs Implementation

  • Implemented programmable-switch AQMs include CoDel, AFQ, PIE, PI2, RED, ABC, SP-PIFO, and MTQ/QTL, covering bufferbloat mitigation, fairness, congestion management, and scheduling.AFQ approximates fair queuing using per-flow state, packet scheduling, egress-queue selection, multiple queues, and a count-min sketch.Source: 2) Standardized AQMs Implementation · pp. 19–20
  • AQM practicality depends on implementation complexity: CoDel and PI2 use simple operations, whereas fair queuing requires costly classification, per-packet scheduling, and buffer allocation.Parameter- and threshold-heavy schemes are harder to manage and less autonomous, while hardware constraints make complex FQ algorithms expensive on high-speed devices.Source: 2) Standardized AQMs Implementation · p. 20
  • P4 enables rapid, cost-efficient AQM deployment and customization, reducing implementation timelines from years on fixed-function equipment to weeks while supporting production-network testing.Programmable switches let operators implement AQMs in P4, test them with production networks, and adapt them to changing traffic conditions.Source: 2) Standardized AQMs Implementation · p. 20

D. QUALITY OF SERVICE AND TRAFFIC MANAGEMENT

  • Programmable switches provide QoS and traffic management through programmable classification, metering, prioritization, marking, scheduling, and traffic policing logic.Reported systems include application-header-aware QoS routing, end-to-end bandwidth management, congestion-window marking, RL-SP-DRR scheduling, and multi-color metering for multi-tenancy.Source: D. QUALITY OF SERVICE AND TRAFFIC… · p. 21
  • Hardware support remains uneven: the bandwidth manager was implemented on Tofino, while several QoS and traffic-management systems ran only on BMv2 despite hardware-compatible primitives or queues.Layer-5 processing may not sustain line rate on hardware, whereas metering and multiple-priority-queue features are available on current hardware targets.Source: D. QUALITY OF SERVICE AND TRAFFIC… · pp. 21–22

E. MULTICAST

  • Unlike legacy multicast, programmable switches can process custom headers and metadata, addressing mobility, limited group-table capacity, hardcoded signaling, and non-standard protocol constraints.P4 traffic management can also use high-granularity switch-state metadata, including queue occupancy and packet sojourn time, at line rate.Source: E. MULTICAST · p. 22, D. QUALITY OF SERVICE AND TRAFFIC… · p. 22
  • Source-routed multicast schemes encode tree or group information in packet headers: ELMO scales on hardware at line rate, whereas BIER removes per-group state but was limited to BMv2 by heavy processing.BIER also avoids signaling for building, managing, and tearing down multicast trees; ELMO has no restrictions on group or network sizes.Source: E. MULTICAST · p. 22
  • P4 multicast supports application-specific trees, eliminates or reduces per-group state and signaling, and enables easy reconfiguration, while PAM adds priority-based adaptive rate allocation for cloud file transfers.PAM addresses changing link bandwidth, fault tolerance, scalability, limited priority queues, and complex data-plane computation through decentralized preemptive scheduling.Source: E. MULTICAST · pp. 22–23

F. SUMMARY AND LESSONS LEARNED … B. CACHING

Programmable switches support customizable monitoring, congestion control, QoS, multicast, middlebox, load-balancing, and caching functions, often moving processing into the data plane for flexibility and performance. Across these applications, key challenges include scalability, deployment with legacy systems, state management, probing overhead, cache-policy flexibility, and hardware feasibility.

F. SUMMARY AND LESSONS LEARNED

  • Future programmable-network applications should generalize monitoring, reduce storage and controller intervention, manage accuracy-memory trade-offs, support legacy multicast deployment, and improve multicast reliability.Measurement-driven congestion control uses throttling, payload reduction, sending-rate enforcement, queue separation, traffic policing, and bandwidth management.Source: F. SUMMARY AND LESSONS LEARNED · p. 23

VIII. MIDDLEBOX FUNCTIONS

  • Programmable switches can implement middlebox functions with custom packet-header inspection and modification at line rate, avoiding operating-system scheduling, interrupt, pre-emption, and related virtualization delays.Legacy middleboxes provide limited manufacturer-defined functions, while NFV on x86 servers improves innovation but introduces performance implications.Source: §VIII · p. 23

A. LOAD BALANCING

  • Switch-based load balancing stores connection state locally to preserve per-connection consistency, while stateless designs use backend state, packet marking, or utilization-based weights.Stateful schemes include HULA, MP-HULA, and Contra; stateless schemes include Beamer, SHELL, and W-ECMP.Source: A. LOAD BALANCING · p. 24
  • Active probing can improve load-balancing decisions but adds bandwidth overhead, while multi-path transport requires schemes such as MP-HULA, Contra, and DASH to avoid suboptimal bottleneck placement.HULA may pin multiple subflows of one connection to the same bottleneck link.Source: A. LOAD BALANCING · p. 24

B. CACHING

  • In-network caches store hot items in programmable switches, serve hits locally, forward misses to backend servers, invalidate entries on writes, and receive periodic controller updates.This design targets skewed key-value access, where changing hot items can otherwise overload servers and reduce throughput.Source: B. CACHING · p. 25
  • Caching schemes differ by cached data, automatic versus manual indexing, and custom versus standard protocols; application-specific systems cache NDN names, FIB entries, industrial-control data, or DNS entries.CONCORDIA stores cache metadata in the switch while coordinating coherence among server caches.Source: B. CACHING · pp. 25–26
  • NetCache handles two billion queries per second for 64,000 items with 16-bytes keys and 128-bytes values, improves throughput 3-10 times over commodity servers, and reduces latency by 50% for 40% of queries.IncBricks reduces request latency by over 30% compared to client-side caching systems.Source: B. CACHING · p. 26
  • Switch-based caching delivers order-of-magnitude higher throughput than general-purpose servers and reduces latency by 50%, while resolving load imbalance through data-plane logic.Server-based caching remains more flexible for cache policies and key, value, and table sizes.Source: B. CACHING · p. 26

C. TELECOMMUNICATION SERVICES · D. CONTENT-CENTRIC NETWORKING

Programmable switches accelerate 5G telecom functions and media offloading by moving processing from x86 servers into the data plane, while also enabling high-throughput publish/subscribe and named-data networking services. Across both domains, these gains are constrained by switch memory and the difficulty of implementing complex or stateful features in hardware.

C. TELECOMMUNICATION SERVICES

  • 5G-oriented schemes generally offload x86-based telecom functions to programmable hardware to meet ultra-reliable, low-latency, and low-jitter requirements, including microseconds-scale targets.TurboEPC additionally offloads a significant portion of packet-core signaling traffic to improve control-plane throughput and latency.Source: C. TELECOMMUNICATION SERVICES · pp. 27–28
  • 18% and 25% reductions in handover time were reported for two- and three-handover sequences, respectively, relative to legacy approaches.Programmable switches were also used for 5G backhaul enhancement, firewalling, signaling, combined SGW/PGW processing, hybrid gNBs, and UPF implementation.Source: C. TELECOMMUNICATION SERVICES · pp. 27–28
  • Media relaying on programmable switches substantially lowers latency, jitter, and packet loss while supporting over one million sessions, compared with about 1,000 sessions per server CPU core before QoS degrades.The switch-based relay also improves CPU usage and Mean Opinion Score, although functions such as media mixing and noise reduction remain difficult to implement in the data plane.Source: C. TELECOMMUNICATION SERVICES · p. 28

D. CONTENT-CENTRIC NETWORKING

  • Content-centric networking uses named data rather than named hosts, and programmable switches address software-middlebox throughput and latency limits for publish/subscribe applications.Systems support stateful packet predicates, flexible attribute/value encoding, and distribution strategies for dynamic IoT and other pub/sub workloads.Source: D. CONTENT-CENTRIC NETWORKING · p. 28
  • P4-based named-data systems include NDN.p4, its scalable content-store extension, and ECDN, which supports adaptive forwarding, customized monitoring, in-network caching control, and publish/subscribe forwarding.ECDN generates data-plane configuration from application requirements, while adaptive programmability distinguishes it from other P4-based CDN schemes.Source: D. CONTENT-CENTRIC NETWORKING · pp. 28–29
  • Programmable-switch pub/sub systems reduce broker latency variation, and packet-subscription processing reached line rate at the full 6.5 Tbps capacity of a Tofino switch.Encoding notification trees in packet headers avoids updating switch rules when subscriptions change, while predicate compilation can automate table generation using Binary Decision Diagrams.Source: D. CONTENT-CENTRIC NETWORKING · pp. 28–29
  • Switch memory limits the amount of pub/sub data that can be distributed, while software features such as QoS levels, session persistence, message retaining, and last-will notifications are challenging to implement in hardware.P4 also has shortcomings for stateful variable-length protocols, an important limitation for implementing NDN in the data plane.Source: D. CONTENT-CENTRIC NETWORKING · p. 29

E. SUMMARY AND LESSONS LEARNED … B. MACHINE LEARNING

The survey finds that programmable switches support middlebox functions, in-network computation, consensus, and machine-learning acceleration, while remaining constrained by storage, computation, scalability, and model-complexity limits. Across these applications, reported systems reduce communication or latency and can substantially improve throughput and training time when computations are offloaded to the data plane.

E. SUMMARY AND LESSONS LEARNED

  • Programmable switches implement middleboxes including load balancers, caches, telecom offloads, and publish/subscribe brokers, with future work targeting scalability, priority, reliability, and richer services.Load balancing commonly stores connection state in the data plane; caching can serve hot items at line rate; telecom offloading includes media and user-plane functions; brokers need delivery guarantees, retention, and QoS differentiation.Source: E. SUMMARY AND LESSONS LEARNED · pp. 29–30
  • Reported middlebox and ML designs must balance programmable-switch resource limits against application requirements, motivating compression, communication minimization, scalable sessions, simpler models, and improved recovery mechanisms.The survey identifies storage and computation limits for switches, scalability limits for telecom sessions and load balancing, and incomplete or narrow support for neural-network inference.Source: E. SUMMARY AND LESSONS LEARNED · p. 29, B. MACHINE LEARNING · pp. 32–33

IX. NETWORK-ACCELERATED COMPUTATIONS

  • Network-accelerated computation applies ASIC packet processing to consensus, machine learning, stream processing, and other workloads, potentially improving throughput by an order of magnitude or more over software.The opportunity follows from switch ASICs processing packets at terabits-per-second rates.Source: §IX · p. 30

A. CONSENSUS

  • Consensus implementations include P4-based Paxos variants, Eris, P4BFT, and Raft offloading, but full Paxos remains difficult under data-plane constraints and often requires simplifying or partitioning protocol logic.NOPaxos relies on ordered unreliable multicast, NetChain separates steady state from reconfiguration, and P4xos executes Paxos logic directly in switch ASICs.Source: A. CONSENSUS · pp. 30–31
  • Programmable switches accelerate consensus by processing messages on the wire, reducing coordinator latency from 96us to 340ns and requiring fewer hops than legacy deployments.These benefits arise because consensus messages are processed in the network rather than by general-purpose CPUs.Source: A. CONSENSUS · p. 31

B. MACHINE LEARNING

  • SwitchML aggregates distributed model updates in the switch, minimizing communication while addressing storage, per-packet computation, quantization, and failure-recovery constraints.Each worker sends its update vector and receives the aggregated update; streaming, work partitioning, and quantization address hardware limitations.Source: B. MACHINE LEARNING · p. 32, Figure 18 · p. 32
  • Up to 300% faster ML training and over 2.5 billion consensus messages per second demonstrate substantial gains from hardware-switch offloading.SwitchML speeds training by up to 300% compared to existing distributed-learning approaches, while P4xos processes over 2.5 billion consensus messages per second and reduces latency three times compared to traditional approaches.Source: A. CONSENSUS · p. 31, B. MACHINE LEARNING · p. 32
  • Machine-learning systems span in-network aggregation and inference, but inference is limited by switch computation, feature, accuracy, and evaluation-platform constraints.N2Net targets binary neural networks, IIsy is bounded to packet-header features and excludes popular neural-network algorithms, and BaNaNa Split evaluated one binary layer on a network-processor SmartNIC.Source: B. MACHINE LEARNING · pp. 31–33

SERVER-BASED ML … A. AGGREGATION

The surveyed applications show that programmable switches can accelerate ML, consensus, and IoT processing, while hardware limits constrain model storage, protocol complexity, and computation. IoT aggregation reduces header overhead and improves throughput, latency, and jitter compared with server-based aggregation, but sacrifices flexibility.

SERVER-BASED ML

  • Switch-based ML inference operates at line rate for faster client results, but estimation-based computation and limited SRAM constrain complex processing and large-model storage.Server-based inference does not face these switch capacity limitations.Source: SERVER-BASED ML · p. 33
  • Offloading aggregation to a centralized switch can significantly accelerate distributed training, although switch memory cannot store a complete model update and encrypted traffic remains challenging.Source: SERVER-BASED ML · p. 33

D. SUMMARY AND LESSONS LEARNED

  • Programmable-switch delegation improves performance for tasks including consensus and ML training despite switches supporting only basic, limited operations.Such computation offloading is becoming a trend in data centers and backbone networks.Source: D. SUMMARY AND LESSONS LEARNED · p. 33
  • In-network consensus implementations mainly target Paxos and Raft, but hardware constraints require simplified protocols and leave novel algorithms and failure recovery as future needs.Source: D. SUMMARY AND LESSONS LEARNED · p. 33
  • In-network ML training and inference achieve significant performance improvements when switches aggregate model updates or classify samples, with future work spanning classification, regression, and clustering.Source: D. SUMMARY AND LESSONS LEARNED · p. 33

X. INTERNET OF THINGS (IOT)

  • IoT devices transmit small sensor payloads to remote servers for analysis, creating bandwidth inefficiency because packet headers occupy a large fraction of each packet.Sigfox LPWAN supports 12-byte payloads while Ethernet, IP, and UDP headers total 42 bytes, approximately 78% of the packet.Source: §X · p. 33, A. AGGREGATION · p. 33

A. AGGREGATION

  • Packet aggregation combines small IoT payloads into larger packets to reduce header overhead, while programmable-switch designs transparently aggregate and disaggregate traffic without endpoint changes.The extended design supports variable payload sizes, dynamic packet counts limited by MTU, and line-rate aggregation and disaggregation.Source: A. AGGREGATION · p. 34
  • Switch-based IoT aggregation provides higher throughput and lower latency and jitter than server-based approaches, whereas server-based aggregation offers greater flexibility in aggregation size.Aggregation on the IoT device causes long delays and low throughput because devices have limited computational and energy resources.Source: A. AGGREGATION · p. 34, Table 25 · p. 34

B. SERVICE AUTOMATION … A. HEAVY HITTER

Programmable switches automate IoT services, aggregate packets, and extend line-rate cybersecurity capabilities, including accurate heavy-hitter detection. Across these applications, in-network processing improves latency, scalability, bandwidth efficiency, detection speed, and policy flexibility while exposing implementation and deployment limitations.

C. SUMMARY AND LESSONS LEARNED

  • IoT packet aggregation reduces header bandwidth overhead by combining frequent small packets, but timers and side-effect analysis are needed to control delay, jitter, loss, and retransmissions.A P4 switch aggregates and encapsulates packets, while a downstream switch disaggregates them to restore the originals.Source: Figure 19 · p. 34, C. SUMMARY AND LESSONS LEARNED · p. 35

B. SERVICE AUTOMATION

  • BLESS processes BLE Attribute Protocol operations in the data plane, while Muppet translates actions between BLE and Zigbee and logs events remotely.Muppet uses ONOS with the Protocol Independent framework, and each supported protocol requires dedicated parsers and action policies.Source: B. SERVICE AUTOMATION · p. 35
  • Switch-based IoT automation combines P2P latency and energy benefits with cloud-like scalability and reachability.BLESS encodes service transactions in the data plane, while Muppet extends the approach to multiple non-IP protocols.Source: B. SERVICE AUTOMATION · p. 35

C. SUMMARY AND LESSONS LEARNED

  • Service-automation research should develop translators for non-IP protocols and use production-grade software switches supporting non-Ethernet IoT protocols.These directions target interoperability across devices and protocols while improving scalability, reachability, energy consumption, and latency.Source: C. SUMMARY AND LESSONS LEARNED · p. 35

XI. CYBERSECURITY

  • Programmable switches can inspect upper OSI layers at line rate, unlike existing security solutions, despite limited computational power.Security applications include heavy-hitter detection, traffic engineering, DDoS mitigation, anonymity, and cryptography.Source: §XI · pp. 35–36

A. HEAVY HITTER

  • Heavy-hitter schemes span local and network-wide detection, trading memory and accuracy through hash tables or sketches and trading deterministic reporting against communication cost.Network-wide tracking is necessary when distributed traffic exceeds thresholds even though no individual switch observes a heavy flow.Source: A. HEAVY HITTER · pp. 36–37
  • HashPipe identified 300 heaviest flows from a 400,000-flow CAIDA ISP trace using 80KB of memory with 95% accuracy.Its pipeline of hash tables stores flow identifiers and byte counts, adapting the space-saving algorithm.Source: A. HEAVY HITTER · p. 36
  • Data-plane heavy-hitter detection examines every packet at line rate, improving detection accuracy and speed while enabling reactive flow-size-aware routing.This avoids the limited accuracy caused by CPU and bandwidth overheads in sampling-based methods.Source: A. HEAVY HITTER · pp. 36–37

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

Programmable switches extend data-plane functionality to cryptography, privacy-preserving networking, and access control, but constrained computation, recirculation, and incomplete security mechanisms limit some deployments. Across these areas, P4 enables line-rate or partially deployable processing while shifting complexity into externs, simplified cryptographic operations, policy tables, or switch state.

B. CRYPTOGRAPHY

  • Cryptographic hashing remains application-dependent: CPUs are easy to use but have several-millisecond latency, SmartNICs provide the highest throughput up to 900-byte packets, and NetFPGA offers the lowest latency without native P4 integration.P4’s common CRC hashes are computationally simpler than SHA-256 but insecure and collision-prone, so no single target fits every requirement.Source: B. CRYPTOGRAPHY · pp. 37–38
  • Most P4 cryptographic schemes delegate complex computations to CPUs, FPGAs, or user-defined externs because switch targets and P4 primarily support basic arithmetic; such externs are not applicable to ASICs such as Tofino.External implementations include cryptographic hashes, IPsec ESP tunnel mode, MACsec, and FPGA-based VHDL externs, while AES demonstrates fully data-plane execution.Source: B. CRYPTOGRAPHY · pp. 37–38
  • 10Gbps throughput was attained for AES-128 on Tofino by recirculating packets through five pipeline passes, although loopback-port bandwidth limits performance.A single pipeline performs two AES rounds, and additional physical loopback ports could enhance throughput.Source: B. CRYPTOGRAPHY · p. 38

C. PRIVACY AND ANONYMITY

  • P4 privacy systems provide partially deployable, low-latency, lightweight protections by anonymizing traffic or obfuscating headers and topology, addressing performance and deployability limitations of overlay systems.ONTAS anonymizes online traces with 0% packet-processing overhead and half the storage of existing offline tools, but does not anonymize TCP/UDP fields or support multiple concurrent privacy policies.Source: C. PRIVACY AND ANONYMITY · pp. 39–40
  • More than 90% of link failures were detected despite NetHide’s topology obfuscation, while PINOT achieves higher throughput through a single ASIC pipeline pass and SPINE would require three passes in ASIC hardware.SPINE conceals IP addresses and TCP fields using simplified encryption and SipHash, whereas PANEL combines source rewriting, normalization, and TTL randomization for partial deployment.Source: C. PRIVACY AND ANONYMITY · pp. 39–40

D. ACCESS CONTROL

  • Programmable switches can authenticate and authorize traffic at line rate before it reaches servers, reducing traversal and software-processing latency while increasing server service throughput.Access-control applications include stateful P4 firewalls, port knocking, context-aware policies, OS fingerprinting, and one-time-password authentication.Source: D. ACCESS CONTROL · pp. 40–41
  • Access-control mechanisms retain security and policy limitations: port knocking is vulnerable to spoofing, sniffing, and security-through-obscurity, while context packets lack authentication, integrity, and confidentiality.Context-aware enforcement can maintain minimum latency under heavy DoS attacks, but its unprotected context communication permits snooping and impersonation; OS fingerprinting lacks sophisticated rate-limiting policies.Source: D. ACCESS CONTROL · pp. 40–41
  • P4 access control supports deeper inspection and state-dependent customizable policies than traditional firewalls, but deeply parsing packets degrades throughput and P4Guard itself operates only through the transport layer.P4 policies and algorithms are operator-defined, whereas fixed-function firewalls rely on vendor implementations; non-programmable NGFWs provide advanced DPI at much lower than line-rate throughput.Source: D. ACCESS CONTROL · pp. 40–41

E. DEFENSES

P4 programmable data planes enable in-network defenses that address volumetric and diverse attacks while avoiding the throughput, latency, jitter, placement, and cost problems of host- or middlebox-based schemes. The surveyed defenses span attack-specific and generic designs, with trade-offs involving programmability, external processing, constrained resources, and deployment scope.

Background

  • P4 defenses are motivated by terabit-per-second attacks that existing mechanisms cannot handle and by the throughput, latency, jitter, and last-mile limitations of host- and middlebox-based protection.Programmable switches enable customized detection and mitigation without significant network overhead.Source: E. DEFENSES · p. 42

Attack-specific

  • Attack-specific schemes target SYN floods, spoofed IP traffic, distributed SIP DDoS, and Modbus threats using flow tracking, hop-count filtering, and protocol filtering.Examples include Hill et al., NETHCF, Febro et al., Scholz et al. [212], and Ndonda et al..Source: E. DEFENSES · p. 42

Generic Attacks

  • Generic defenses address multiple or changing threats through abstractions, automated sensitivity-attack discovery, entropy-based detection, ML-Pushback, policy languages, unified DDoS mitigation, covert-channel defense, EFSMs, and decentralized link-flooding protection.Representative systems include FastFlex, Poseidon, NetWarden, Ripple, and related broad-spectrum and network-wide mechanisms.Source: E. DEFENSES · p. 42

Defense Schemes Comparison, Discussions, and Limitations

  • Defense schemes comprise attack-specific and generic categories, while data-plane deployment improves performance and requires addressing resource multiplexing, optimal placement, distributed control, and dynamic scaling.NETHCF reduces filtering delay and bandwidth overhead, whereas FastFlex emphasizes these four programming challenges.Source: E. DEFENSES · p. 42, Table 32 · p. 43
  • Constrained switches approximate intensive computations or delegate them externally; NETHCF uses a data-plane cache and control-plane mirror, Poseidon partitions primitives across switches and servers, and computes entropies in the data plane.Poseidon requires external server modules, whereas Jaqen runs fully in the switch and uses universal sketches to detect broad attack classes.Source: E. DEFENSES · p. 43

Comparison between P4-based and Traditional Defense Schemes

  • Network-wide cooperation improves detection accuracy and promptness, while switch-based defenses can detect, throttle, or drop suspicious traffic at line rate with lower costs than traditional solutions.Table 33 compares switch-based Poseidon and Jaqen with other defense schemes; server-based last-mile defenses are insufficient for attacks targeting the network core.Source: E. DEFENSES · pp. 43–44, Table 33 · p. 44

F. SUMMARY AND LESSONS LEARNED … B. VERIFICATION

The survey summarizes programmable-switch applications in cybersecurity and emphasizes the need for robust troubleshooting and verification because programmable P4 behavior can introduce serious runtime and deployment faults. It reviews passive, probing-based, static, symbolic, and runtime methods, highlighting their coverage, overhead, scalability, and correctness tradeoffs.

F. SUMMARY AND LESSONS LEARNED

  • Cybersecurity applications use programmable switches to detect heavy hitters, execute cryptography, protect identities and topology, enforce access control, and accelerate defense detection and mitigation.Heavy-hitter systems still need lower state storage, fewer false positives and negatives, incremental deployment, and greater flow visibility.Source: F. SUMMARY AND LESSONS LEARNED · p. 44
  • Data-plane cryptography is needed for applications requiring low hashing collisions and strong data protection, although most existing efforts delegate complex computation to the control plane; AES has been implemented in the data plane.Privacy systems also obfuscate topology and rewrite source information or headers, but must preserve path tracing, link-failure visibility, header-space compatibility, and resistance to obfuscation inversion.Source: F. SUMMARY AND LESSONS LEARNED · p. 44
  • Future access-control and defense systems should authenticate users in-network, offload firewall functions such as line-rate URL filtering, and mitigate stealthy slow DDoS attacks.The surveyed examples include port knocking and keyword searches in packet payloads.Source: F. SUMMARY AND LESSONS LEARNED · p. 44

A. TROUBLESHOOTING

  • Troubleshooting schemes either passively track packet processing or inject probes: passive methods miss untriggered rule faults, while probing methods can incur substantial control and probe overhead.Programmable networks require program-dependent testing, unlike rigid probing of fixed-function legacy devices.Source: A. TROUBLESHOOTING · p. 45
  • P4Tester checks all rules efficiently on Tofino while using fewer probes than server-based ATPG and Pronto, whereas P4DB troubleshoots runtime bugs with small throughput and latency penalties.P4Tester uses BDD-based intermediate representations and source-routed probes; P4DB provides watch, break, and next visibility primitives without modifying the data plane.Source: A. TROUBLESHOOTING · p. 45

B. VERIFICATION

  • Runtime and end-to-end verification extend coverage: P4RL detects bugs and outperforms a baseline, while bf4 combines compile-time checks, controller predicates, code changes, and runtime monitoring to discover previously missed bugs.Vera detects parsing/deparsing errors, invalid memory accesses, and loops using symbolic execution and match-forest scalability improvements.Source: B. VERIFICATION · p. 46

3) Verification Schemes Discussions … C. ARITHMETIC COMPUTATIONS

The paper surveys verification approaches for programmable data planes and identifies challenges and future directions involving autonomous control, memory, resource organization, and arithmetic computation. These issues reflect the need to analyze P4-defined behavior while overcoming constrained switch hardware.

3) Verification Schemes Discussions

  • P4 verification schemes translate programs into formal models or use symbolic execution, while P4RL detects path-related consistency between data and control planes.Examples include Datalog translation for reachability and well-formedness, GCL with Z3 for safety and program-specific properties, and symbolic test generation.Source: 3) Verification Schemes Discussions · p. 46
  • Traditional verification tools cannot handle programmable forwarding changes without internal reprogramming, so programmable-network verification analyzes the P4 programs defining data-plane behavior.Evaluations commonly use switch.p4, which implements Layer 2/3 functions, ACL, QoS, and other cloud-network features.Source: 3) Verification Schemes Discussions · pp. 46–47

C. SUMMARY AND LESSONS LEARNED

  • P4-switch measurements can support troubleshooting and correctness verification in a control loop, with future work targeting self-driving, knowledge-defined, and zero-touch networks.The surveyed challenges and future trends are organized in Fig. 23.Source: C. SUMMARY AND LESSONS LEARNED · p. 47, §XIII · p. 47

A. MEMORY CAPACITY (SRAM AND TCAM)

  • Stateful applications are enabled by storing data across packets, but on-chip memory is limited to tens or hundreds of megabytes, forcing performance–memory trade-offs.Caching hit rates and measurement scope depend on available memory for stored statistics and counters.Source: A. MEMORY CAPACITY (SRAM AND TCAM) · p. 47
  • Remote DRAM accessed through RoCE can expand switch memory with throughput close to line rate and 1-2 microseconds of added latency, but address-only access, update overhead, packet loss, and API integration remain challenges.The approach reuses commodity-server resources without adding infrastructure costs.Source: A. MEMORY CAPACITY (SRAM AND TCAM) · pp. 47–48

B. RESOURCES ACCESSIBILITY

  • Pipeline-local memory and sequential execution make table placement difficult and can underutilize resources when match and action workloads are imbalanced.Disaggregating memory and compute through a shared pool and processor cluster addresses these limitations, but hardware-vendor adoption remains limited.Source: B. RESOURCES ACCESSIBILITY · p. 48

C. ARITHMETIC COMPUTATIONS

  • Arithmetic computation is constrained by simple integer operations, few per-packet instructions, nanosecond-scale processing, and substantial hardware-resource demands, limiting complex AQM and machine-learning workloads.Examples include CoDel square roots and floating-point vector averaging.Source: C. ARITHMETIC COMPUTATIONS · p. 48
  • Approximation and control-plane pre-computation mitigate arithmetic limits, while future automation could identify complex operations and generate data-plane code with corresponding control-plane APIs.Leading-zero counting with longest-prefix match approximates square roots, and a community library could collect such P4 implementations.Source: C. ARITHMETIC COMPUTATIONS · p. 48

D. NETWORK-WIDE COOPERATION … H. PROGRAMMING SIMPLICITY

The paper surveys challenges and future directions for network-wide cooperation, control-plane interaction, security, interoperability, and programming simplicity in programmable switches. Across these areas, it emphasizes state synchronization, reduced control-plane dependence, attack resilience, incremental deployment, and tools that simplify P4 development.

D. NETWORK-WIDE COOPERATION

  • Network-wide cooperation enables switches to make decisions using shared state, but requires synchronization that avoids continuous software-controller communication.In-network DDoS detection illustrates the need: aggregating byte counts across switches can expose a sender whose traffic remains below each switch’s local threshold.Source: D. NETWORK-WIDE COOPERATION · pp. 48–49
  • SNAP, LODGE, LOADER, Swing State, P4Sync, and SwiShmem address distributed state management, but migration overhead, inconsistency, delivery, merging, replication, and authentication remain challenges.P4Sync guarantees authenticated and complete migration with rate control, while frequent migrations can incur RSA-2048 signing and verification costs of 2.15ms and 0.07ms, respectively.Source: D. NETWORK-WIDE COOPERATION · p. 49

E. CONTROL PLANE INTERVENTION

  • Control-plane intervention can delay applications such as rerouting and force complex operations such as cuckoo hashing onto the switch CPU.Future tools should automatically identify excessive control/data-plane interaction and suggest or generate workflows that delegate suitable tasks, including failure detection, notification, and connectivity retrieval, to the data plane.Source: E. CONTROL PLANE INTERVENTION · pp. 49–50

F. SECURITY

  • Sensitivity attacks exploit crafted traffic to trigger adverse data-plane behavior, including path skew, congestion, cache imbalance, data loss, and memory-driven eviction.Future defenses should combine automatic attack discovery, formally verified code, fast or self-stabilizing mode changes, cross-domain security interfaces, and exposed attack patterns.Source: F. SECURITY · p. 50

G. INTEROPERABILITY

  • Incremental P4 deployment alongside legacy devices avoids immediate infrastructure replacement but can reduce application effectiveness because partial deployment limits flow visibility.A greedy placement algorithm uses F1 score to position P4 switches for heavy-hitter detection, while future work should generalize placement to caching, consensus, and in-network defense applications.Source: G. INTEROPERABILITY · p. 50
  • Network taps let P4 switches analyze legacy-device traffic without fully replacing existing infrastructure, preserving timing and packet order while enabling fine-grained monitoring.Applications include RTT estimation, network-wide telemetry, and DDoS detection or mitigation; a single P4 switch can serve many non-programmable devices.Source: G. INTEROPERABILITY · pp. 50–51, Figure 27 · p. 50

H. PROGRAMMING SIMPLICITY

  • P4 programming is difficult because bugs, hardware resource limits, trial-and-error compilation, concurrent functions, and weak modularity threaten network cost, stability, and correctness.Although ordinary switch deployment may only require a NOS such as SONIC or FBOSS, in-network applications require operators to program the ASIC.Source: H. PROGRAMMING SIMPLICITY · p. 51
  • Future programming tools should simplify workflows and generate hardware-fitting P4 code, while P4All uses elastic programs, loops, target constraints, and compiler optimization.P4All remains limited by manually specified utility functions and workload assumptions and does not support multivariate or nonlinear functions.Source: H. PROGRAMMING SIMPLICITY · p. 51

I. DEEP PROGRAMMABILITY … XIV. CONCLUSIONS

The paper surveys deep programmability, modularity, practical testing, human involvement, and future directions for programmable data planes. It identifies mechanisms, limitations, and initiatives supporting open, verifiable, increasingly autonomous networks.

I. DEEP PROGRAMMABILITY

  • Deep programmability partitions network behavior across programmable switches, NICs, virtual switches, and end hosts, emphasizing software-defined functions, verification, telemetry, and autonomous control.Realizing this vision requires line-rate, movable code and systematic partitioning methods that respect feedforward hardware pipelines; P4 can specify dependencies and invoke CPU code through externs.Source: §I · pp. 51–52

J. MODULARITY AND VIRTUALIZATION

  • Modularity and virtualization must support simultaneous network functions while preserving resource, performance, and security isolation during reconfiguration.Hyper4 enables hot-pluggable behavior but incurs recirculation overhead; remaining challenges include latency interference, limited live reconfiguration, recompilation, and state loss.Source: J. MODULARITY AND VIRTUALIZATION · p. 52

K. PRACTICAL TESTING

  • Practical testing remains necessary because simulations and CPU-bound emulations cannot faithfully reproduce production-network performance, traffic rates, or scale.TurboNet emulates data and control planes at line rate by slicing switch ports and queues, while P4Campus promotes hardware-switch experiments using replayed campus traffic.Source: K. PRACTICAL TESTING · pp. 52–53

L. HUMAN INVOLVEMENT

  • Large, opaque networks motivate self-driving, zero-touch, and knowledge-defined approaches based on closed-loop control rather than extensive manual configuration.Autonomous operation requires real-time observation, on-the-fly behavior generation, and rapid verification and deployment of generated code.Source: L. HUMAN INVOLVEMENT · p. 53

XIV. CONCLUSIONS

  • The survey traces networking’s evolution from traditional control planes through SDN to programmable-switch architectures and presents P4 as the de-facto data-plane programming language.It motivates data-plane programmability and describes the general architecture of programmable switches based on PISA.Source: §XIV · pp. 53–54
  • Its taxonomy surveys and compares numerous programmable-data-plane works within application categories and against legacy approaches, then consolidates challenges, considerations, and future initiatives.The survey covers more than 150 articles and provides a comprehensive analysis of programmable-switch applications.Source: §XIV · p. 54
  • The paper concludes that closed network designs will diminish as open-source systems and deep programmability increasingly dominate future networking architectures.This conclusion is presented as an evidence-based future direction of the surveyed literature.Source: §XIV · p. 54

Related papers

Loading 2102.00643v2…