Pith. sign in

REVIEW 3 major objections 9 minor 37 references

P4-NIDS: High-Performance Network Monitoring and Intrusion Detection in P4

T0 review · 3 major / 9 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read This paper claims that a single P4 data-plane program can export extended NetFlow v9 records and run a decision-tree intrusion detector at wire speed, with negligible throughput impact up to 8 million packets per second.

desk verdict Real hardware NetFlow exporter work with a load-bearing accuracy claim that is inherited from an offline model, not measured on the P4 implementation. read the letter →

arxiv 2411.17987 v2 pith:FIJQSR5K submitted 2024-11-27 cs.NI

Yaying Chen , Siamak Layeghy , Liam Daly Manocchio , Marius Portmann This is my paper · ORCID
classification cs.NI
keywords P4NetworkmonitoringNetFlowv9IntrusiondetectionDecisiontreeProgrammabledataplaneSmartNICThroughputevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper tries to show that network monitoring and intrusion detection can run entirely inside a P4-programmable data plane, without offloading to a controller or external middlebox. It claims that a P4 NetFlow exporter can generate extended NetFlow v9 records at wire speed, and that the same pipeline can host a decision-tree intrusion detector that classifies flows while forwarding traffic. On a 40 Gbps Netronome SmartNIC, the paper reports negligible throughput impact up to about 8 million packets per second, with memory overhead in the kilobyte range. The motivation is that traditional out-of-band monitoring and detection cannot keep up with Terabit-scale cloud networks.

What carries the argument

The load-bearing mechanism is a register-based NetFlow table: a hash of the 5-tuple selects a flow entry, and each NetFlow field lives in its own P4 register array, so the decision tree can read all features directly in the data plane while the control plane periodically exports them. The decision tree itself is encoded as a chain of if-else statements, which is how P4's limited control flow is made to execute a pre-trained classifier. The hash-indexed register array is what lets the system keep cross-packet state without controller involvement.

What would settle it

Replay a labeled UNSW-NB15 or CIC-IDS-2018 traffic trace through the Netronome SmartNIC running the P4-NIDS program, read each flow's 'malicious flag' register, and compare against ground truth; if the F1 score is substantially below the reported 99.76 or 98.09, the high-accuracy claim would be refuted.

Watch

Extended reading notes

Core claim

The central claim is that a single P4 program can combine a NetFlow v9 generator and a machine-learning-based intrusion detection system in the data plane, preserving forwarding performance. The NetFlow component hashes each packet's 5-tuple into a Flow ID that indexes a set of register arrays, one per NetFlow field, supporting 12 fields and extended to 22 in the decision-tree scenario. The IDS component is a pre-trained decision tree, taken from an earlier work, unfolded into nested if-else statements that read the register fields and write a 'malicious flag'. The paper reports F1 scores of 99.76 on UNSW-NB15 and 98.09 on CIC-IDS-2018 for this classifier, and shows hardware throughput that closely matches offered load across the tested range regardless of the number of NetFlow fields or the active decision-tree classifier.

Load-bearing premise

The paper's high-accuracy claim rests on the assumption that the P4 register-based realization classifies traffic exactly as accurately as the offline decision-tree model, since the F1 scores come from the offline model and the hardware test measures throughput only.

Editorial extensions

If this is right

  • If the claims hold, operators can deploy monitoring and basic intrusion detection on the switch itself, removing the collector and controller from the latency path.
  • NetFlow export with 9 to 22 fields can run at wire speed with only kilobyte-scale memory increases, making Terabit-scale monitoring practical on programmable NICs.
  • The decision-tree classifier adds no measurable throughput drop in the hardware experiments, so security classification can be 'always on' rather than sampled or offloaded.
  • The roughly 4x throughput advantage over the evaluated flow-monitoring baseline suggests in-band exporters can be substantially cheaper than earlier P4 designs.

Reading between the lines

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

  • I would read the F1 scores as a property of the offline decision-tree model, not of the P4 execution, because the paper does not report measuring the hardware pipeline's classifications against labeled traffic; a direct on-hardware accuracy test would settle whether the P4 version inherits that accuracy.
  • The same register-array design could likely host other simple classifiers such as small random forests or threshold-based anomaly rules, provided their feature sets fit in P4 registers and their control flow can be encoded as nested if-else statements.
  • Hash collisions in the flow table could merge distinct flows and distort both NetFlow statistics and classification; an evaluation varying the hash width and table size would quantify this risk.
  • The hardware test's offered-load ceiling is set by the generator NIC, so the 8 mpps result uses 64-byte packets at about 5.3 Gbps and 1024-byte packets at about 25.8 Gbps; a true 40 Gbps full-line-rate test would need a stronger traffic generator.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 9 minor

Summary. This paper proposes P4-NIDS, a P4 implementation of a NetFlow v9 exporter and a decision-tree-based intrusion detection system deployed on both BMv2 and a Netronome CX 2x40GbE SmartNIC. The monitoring component extracts extended NetFlow fields at line rate, and the NIDS component implements a pre-trained decision tree from [13] using P4 registers. The evaluation reports low memory overhead, CPU utilization of 0.3% in emulation, SmartNIC throughput that tracks the offered load up to ~25.9 Gbps / ~7.8 Mpps, and F1 scores of 99.76 (UNSW-NB15) and 98.09 (CIC-IDS-2018). The paper claims these results show high-accuracy detection with negligible throughput impact, surpassing state-of-the-art in-band monitoring and IDS solutions.

Significance. The paper makes a useful contribution by demonstrating that a flow-based decision-tree NIDS can be implemented in P4 and run on a commercial SmartNIC with modest resource overhead, and by providing a comparison with FlowStalker in emulation. The hardware testbed and throughput measurements are a strength that distinguishes the work from many prior P4 proposals that stop at BMv2. However, the headline accuracy claim is inherited from an offline model [13] rather than measured on the P4 implementation, and the throughput evaluation lacks a no-NIDS hardware baseline and is limited by the traffic generator's 25.9 Gbps cap. The significance of the paper would increase substantially if the authors added an accuracy validation of the P4 data plane or explicitly scoped the claim to inherited offline-model accuracy.

major comments (3)
  1. [5.1, Table 1] The F1 scores reported in Table 1 under 'Our solution (BMv2)' are not measurements of the P4 implementation. Section 4.2 states that the DT classifier was 'proposed and evaluated in [13]' and that the P4 program deploys this 'pre-trained DT model'; no experiment is described in which the BMv2 or Netronome implementation actually classifies traffic from UNSW-NB15 or CIC-IDS-2018 and computes an F1 score. The abstract's claim of 'high-accuracy detection' therefore rests on the unverified assumption that the P4 register-based re-implementation preserves the offline model's accuracy. The row label is misleading and should be changed (e.g., to 'Model [13] (offline)') or replaced with data-plane accuracy measurements.
  2. [4.2, Listing 1.1] The paper does not validate that the NetFlow features computed by the P4 program are semantically identical to the features used to train the offline model in [13]. The P4 code reads register values such as TCP_WIN_MAX_OUT, MIN_TTL, NUM_PKTS_1024_TO_1514_BYTES, and packet/byte counters keyed by a hash of the 5-tuple, but no experiment compares these register values with the offline feature extractor's definitions (e.g., flow timeout, directionality, counter widths, TCP window sampling). A feature mismatch would degrade classification accuracy without affecting the throughput measurements. A concrete validation—for instance, exporting P4-computed features for a replayed dataset trace and comparing them with the dataset's feature values—should be added or the accuracy claim should be explicitly limited to the offline model.
  3. [5.2, Figure 7 and Table 3] The claim of 'negligible impact on throughput' is not directly measured against a hardware baseline. Figure 7 shows SmartNIC throughput for five NetFlow-field configurations and the DT-enabled configuration, but does not include a 'Basic Port Forwarding' (no monitoring/IDS) curve, even though Section 5.2 states that the same three scenarios as in emulation were evaluated. In addition, Pktgen-DPDK caps the offered load at about 25.9 Gbps (Table 3), so the SmartNIC is never tested at its 40 Gbps line rate, and the maximum measured packet rate is about 7.8 Mpps rather than the '8 million packets per second' stated in the abstract. The conclusion of negligible impact is therefore inferred from the throughput tracking the offered load, not from a baseline comparison, and the stated traffic-rate ceiling is not reached.
minor comments (9)
  1. [4.1] The text says 'the system supports 12 NetFlow fields', while Section 5.2 and Figure 7 describe 'DT-based NIDS using 22 NetFlow features'. Please clarify the field count and how the extra features were added.
  2. [5.2, Table 2] The sentence 'the minimal memory increase, which remains within the kilobyte range' is contradicted by the table, where External Memory grows from 965.37 to 969.89 MB (about 4.5 MB). Please correct the wording or report the actual deltas.
  3. [5.2, Table 2] The table column 'Classifier Memory' does not match the component list in the text, which defines 'CLS (CLS Memory)'. Please align the terminology.
  4. [Listing 1.1] The code excerpt has unbalanced braces: the inner if-else chain starting at line 14 is not closed before the outer '} else {' at line 19. Please provide a complete, compilable snippet or note where clauses are omitted.
  5. [5.1, Figure 5] The y-axis label 'Drop of Throughput %' uses decimal tick values (0.000, 0.025, ..., 0.125), which are fractions, not percentages. Please fix the axis or the text, and reconcile with the statement that the solution shows '25% to 50% less throughput drop'.
  6. [5.1] The claim that CPU utilisation 'consistently remained at 0.3%' across all three scenarios lacks information about the measurement method, the traffic load, and whether this is a meaningful comparison for BMv2. Please add the measurement details.
  7. [Abstract] The abstract states 'traffic rates up to 8 million packets per second', but Table 3's maximum is approximately 7.83 Mpps. Please adjust the wording to match the measured range or present data that reaches 8 Mpps.
  8. [Table 1] The column header 'CIC-2018/2017' combines two datasets; since the proposed method is evaluated on CIC-IDS-2018 and Leo on CIC-IDS-2017, please split the columns or state the mismatch explicitly in the table caption.
  9. [Reference [13]] Reference [13] lacks publication venue and year format details; please provide the full bibliographic information for the 'Light Bulb' paper.

Circularity Check

1 steps flagged · score 4.0 of 10

Table 1's F1 scores are inherited from the authors' prior work [13] and relabeled as 'Our solution (BMv2)', so the high-accuracy detection claim rests on a self-citation rather than on any measured P4 classification result.

  1. self citation load bearing [Section 4.2 (ML-based NIDS in P4) and Section 5.1, Table 1]
    "we used a pre-trained DT model, as proposed and evaluated in [13], to illustrate the feasibility of implementing an efficient in-band NIDS ... In this implementation, NetFlow fields, read from P4 registers, are distributed across the if-else statements based on the conditions defined by the pre-trained DT model, as proposed in [13]. ... Table 1 presents the F1-scores of our solution alongside Leo's. Our DT-based classifier demonstrates significantly better performance on the UNSW-NB15 dataset."

    The paper's 'high-accuracy detection' claim is supported by Table 1, which lists F1 = 99.76 (UNSW-NB15) and 98.09 (CIC-IDS-2018) under the row 'Our solution (BMv2)'. However, the paper never reports measuring the P4 implementation's classifications on either BMv2 or the Netronome SmartNIC; the emulation section only measures throughput and CPU. The accompanying text says the DT model was 'proposed and evaluated in [13]', and [13] is by three of the same authors. The F1 numbers are therefore the offline model's scores from that self-cited paper, relabeled as the current system's performance.

full rationale

The throughput and resource-utilization parts of the paper are not circular: Figure 7 and Table 3 report direct hardware measurements of the SmartNIC under offered load, and the NetFlow/DT overhead claims follow from those measurements. No fitted parameter is disguised as a prediction in the performance chain. The circularity is confined to the classification-accuracy claim. Section 4.2 explicitly imports a pre-trained decision tree from [13], a paper sharing three authors, and Section 5.1's Table 1 presents that model's F1 scores as 'Our solution (BMv2)' without any accuracy measurement of the actual P4 data plane on either emulated or hardware targets. The paper also never validates that the P4-computed register values (e.g., TCP_WIN_MAX_OUT, NUM_PKTS_1024_TO_1514_BYTES, MIN_TTL) are semantically identical to the offline features used to train the model, so the central accuracy result is load-bearing on an unverified equivalence plus a self-citation. Because the independently measured throughput claims remain substantive, the overall circularity is partial, not total.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on the pre-trained decision tree from [13], on the assumption that the P4 implementation preserves that model's accuracy, on hash-based flow tables without collision handling, and on the interpretation of resource and throughput measurements. No new free parameters or invented entities are introduced in this paper; the model parameters are external.

assumptions (4)
  • domain assumption The pre-trained decision-tree classifier from [13] is a valid NIDS model and its offline F1 scores transfer to the P4 register-based implementation.
    Section 4.2 selects the model from [13] (self-cited) and Section 5.1 reports its F1 scores as 'Our solution (BMv2)' without measuring the P4 program's classifications.
  • domain assumption Hashing the 5-tuple into a Flow ID yields a collision-free and overflow-free flow table for the tested traffic.
    Section 4.1 derives Flow ID from a hash and stores flow state in registers; no collision resolution or table-size bound is specified.
  • domain assumption BMv2 CPU utilization and the Program Studio memory report are meaningful proxies for production hardware overhead.
    Section 5.1 concludes 'minimal load' from 0.3% CPU on a software switch; Section 5.2 uses the Netronome IDE's memory report as evidence of lightweight operation.
  • domain assumption NetFlow v9 feature set of 22 fields is sufficient for the intrusion detection accuracy reported.
    Section 4.2 says the DT uses 22 NetFlow fields; the sufficiency of this feature set was established in the cited model [13], not in this paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of P4-NIDS: High-Performance Network Monitoring and Intrusion Detection in P4." pith.science (2026). https://pith.science/paper/FIJQSR5K

@misc{pith2026241117987,
  author       = {Pith},
  title        = {Pith review of: P4-NIDS: High-Performance Network Monitoring and Intrusion Detection in P4},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FIJQSR5K}},
  note         = {Machine review of arXiv:2411.17987}
}
read the original abstract

This paper presents a high-performance, scalable network monitoring and intrusion detection system (IDS) implemented in P4. The proposed solution is designed for high-performance environments such as cloud data centers, where ultra-low latency, high bandwidth, and resilient infrastructure are essential. Existing state-of-the-art (SoA) solutions, which rely on traditional out-of-band monitoring and intrusion detection techniques, often struggle to achieve the necessary latency and scalability in large-scale, high-speed networks. Unlike these approaches, our in-band solution provides a more efficient, scalable alternative that meets the performance needs of Terabit networks. Our monitoring component captures extended NetFlow v9 features at wire speed, while the in-band IDS achieves high-accuracy detection without compromising on performance. In evaluations on real-world P4 hardware, both the NetFlow monitoring and IDS components maintain negligible impact on throughput, even at traffic rates up to 8 million packets per second (mpps). This performance surpasses SoA in terms of accuracy and throughput efficiency, ensuring that our solution meets the requirements of large-scale, high-performance environments.

Figures

Figures reproduced from arXiv: 2411.17987 by the authors.

Figure 1
Figure 1. P4-NIDS architecture in left) Hardware data plane and Right) BMv2 emulation environment 4 Method [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗
Figure 2
Figure 2. NetFlow Table, and fields used to create the hash value for a flow entry [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Emulated network setup VM configured with 6 virtual CPU core (100% capacity) and 8 GB RAM, run￾ning Desktop Ubuntu 16.04 (Kernel 4.4.0-150-generic). The network elements, including clients and servers for both benign and attack traffic, as well as the target host, were created using the Mininet network emulator [29]. Mininet is the standard emulation tool employed by the P4 consortium to test P4 program functionalit… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Throughput comparison of P4-NIDS and FlowStalker by NetFlow features For comparison, we used two recent implementation of similar approaches in P4. As highlighted in the related work, FlowStalker [19] represents the current state-of-the-art in flow extraction schemes w…
Figure 5
Figure 5. Figure 5: Throughput drop of P4-NIDS and FlowStalker by NetFlow features [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6 [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Thoughput Vs. OfferedLoad Gbps with a 1024-byte packet size, it drops to only 5.302 Gbps with a 64-byte packet size. Considering these constraints, we evaluated the throughput of SmartNIC across five different NetFlow generation scenarios, each with varying feature set…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 37 canonical work pages

  1. [13]

    Network Intrusion Detection System in a Light Bulb

    Liam Daly Manocchio, Siamak Layeghy, and Marius Portmann. Network Intrusion Detection System in a Light Bulb. 10 2022

    work page 2022

  2. [1]

    Enabling intent to configure scientific networks for high performance demands

    Mariam Kiran, Eric Pouyoul, Anu Mercian, Brian Tierney, Chin Guok, and In- der Monga. Enabling intent to configure scientific networks for high performance demands. Future Generation Computer Systems, 79:205–214, 2018

    work page 2018

  3. [2]

    Understanding flows in high-speed sci- entific networks: A netflow data study

    Mariam Kiran and Anshuman Chhabra. Understanding flows in high-speed sci- entific networks: A netflow data study. Future Generation Computer Systems, 94:72–79, 2019

    work page 2019

  4. [3]

    An optimization-based approach for efficient network monitoring using in-band network telemetry

    Jonatas Adilson Marques, Marcelo Caggiani Luizelli, Roberto Iraj´ a Tavares da Costa Filho, and Luciano Paschoal Gaspary. An optimization-based approach for efficient network monitoring using in-band network telemetry. Journal of Internet Services and Applications, 10:1–20, 2019

    work page 2019

  5. [4]

    Predictive end-to-end enterprise process network moni- toring

    Felix Oberdorf, Myriam Schaschek, Sven Weinzierl, Nikolai Stein, Martin Matzner, and Christoph M Flath. Predictive end-to-end enterprise process network moni- toring. Business & Information Systems Engineering, 65(1):49–64, 2023

    work page 2023

  6. [5]

    A review on machine learning–based approaches for internet traffic classification

    Ola Salman, Imad H Elhajj, Ayman Kayssi, and Ali Chehab. A review on machine learning–based approaches for internet traffic classification. Annals of Telecommu- nications, 75(11):673–710, 2020

    work page 2020

  7. [6]

    Encrypted network traffic classification and resource allocation with deep learning in software defined network

    Roy Setiawan, Ramakoteswara Rao Ganga, Priya Velayutham, Kumaravel Thangavel, Dilip Kumar Sharma, Regin Rajan, Sujatha Krishnamoorthy, and Sud- hakar Sengan. Encrypted network traffic classification and resource allocation with deep learning in software defined network. Wireless Personal Communications, pages 1–17, 2022

    work page 2022

  8. [7]

    P4: Programming Protocol-independent Packet Processors

    Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rex- ford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, et al. P4: Programming Protocol-independent Packet Processors. ACM SIGCOMM Com- puter Communication Review, 44(3):87–95, 2014. 18 Yaying Chen et al

    work page 2014

Show all 37 references
  1. [8]

    A survey on data plane programming with p4: Fundamentals, advances, and applied research

    Frederik Hauser, Marco H¨ aberle, Daniel Merling, Steffen Lindner, Vladimir Gure- vich, Florian Zeiger, Reinhard Frank, and Michael Menth. A survey on data plane programming with p4: Fundamentals, advances, and applied research. Journal of Network and Computer Applications, 21...

    2023

  2. [9]

    Memory management in activermt: Towards runtime-programmable switches

    Rajdeep Das and Alex C Snoeren. Memory management in activermt: Towards runtime-programmable switches. In Proceedings of the ACM SIGCOMM 2023 Conference, pages 1043–1059, 2023

    2023

  3. [10]

    Random linear network coding on programmable switches

    Diogo Gon¸ calves, Salvatore Signorello, Fernando MV Ramos, and Muriel M´ edard. Random linear network coding on programmable switches. In 2019 ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), pages 1–6. IEEE, 2019

    2019

  4. [11]

    P4tonfv: Offloading from p4 switches to nfv in programmable data planes

    Adrian Pekar, Laszlo A Makara, Yuan-Cheng Lai, Ying-Dar Lin, and Winston Seah. P4tonfv: Offloading from p4 switches to nfv in programmable data planes. International Journal of Communication Systems, 37(5):e5687, 2024

    2024

  5. [14]

    The p4 compiler, 2024

    The P4 Language Consortium. The p4 compiler, 2024

    2024

  6. [15]

    Announcing P4Runtime – A Contribution by the P4 API Working Group, 2017

    Open Networking Foundation. Announcing P4Runtime – A Contribution by the P4 API Working Group, 2017. Accessed: 2024-11-02

    2017

  7. [16]

    P4 16 language specification, 2024

    The P4 Language Consortium. P4 16 language specification, 2024

    2024

  8. [17]

    A Survey of Network Flow Applications

    Bingdong Li, Jeff Springer, George Bebis, and Mehmet Hadi Gunes. A Survey of Network Flow Applications. Journal of Network and Computer Applications, 36(2):567–581, 2013

    2013

  9. [18]

    Cisco IOS NetFlow Version 9 Flow-Record Format - White Paper

    Cisco Systems. Cisco IOS NetFlow Version 9 Flow-Record Format - White Paper. https://www.cisco.com/en/US/technologies/tk648/tk362/technologies white paper09186a00800a3db9.pdf, 2011

    2011

  10. [19]

    Schaeffer-Filho

    Lucas Castanheira, Ricardo Parizotto, and Alberto E. Schaeffer-Filho. FlowStalker: Comprehensive Traffic Flow Monitoring on the Data Plane using P4. InICC 2019 - 2019 IEEE International Conference on Communications (ICC), pages 1–6, 2019

    2019

  11. [20]

    Implementing Your Switch Target with BMv2, 1 2017

    BMv2. Implementing Your Switch Target with BMv2, 1 2017

    2017

  12. [21]

    P4flow: Monitoring traffic flows with pro- grammable networks

    Habib Mostafaei and Shafi Afridi. P4flow: Monitoring traffic flows with pro- grammable networks. IEEE Communications Letters, 25(11):3546–3550, 2021

    2021

  13. [22]

    P4-based proactive monitoring scheme in software-defined net- works

    Bong-Hwan Oh. P4-based proactive monitoring scheme in software-defined net- works. IEEE Transactions on Network and Service Management, 2024

    2024

  14. [23]

    Do switches dream of machine learning? toward in-network classification

    Zhaoqi Xiong and Noa Zilberman. Do switches dream of machine learning? toward in-network classification. In Proceedings of the 18th ACM Workshop on Hot Topics in Networks, pages 25–33, 2019

    2019

  15. [24]

    Leo: Online ML-based Traffic Classification at Multi-Terabit Line Rate

    Syed Usman Jafri, Sanjay Rao, Vishal Shrivastav, and Mohit Tawarmalani. Leo: Online ML-based Traffic Classification at Multi-Terabit Line Rate. 2024

    2024

  16. [25]

    Map4: A pragmatic framework for in-network machine learning traffic clas- sification

    Bruno Missi Xavier, Rafael Silva Guimar˜ aes, Giovanni Comarela, and Magnos Mar- tinello. Map4: A pragmatic framework for in-network machine learning traffic clas- sification. IEEE Transactions on Network and Service Management, 19(4):4176– 4188, 2022

    2022

  17. [26]

    Evaluating standard feature sets towards increased generalisability and explainability of ml-based net- work intrusion detection

    Mohanad Sarhan, Siamak Layeghy, and Marius Portmann. Evaluating standard feature sets towards increased generalisability and explainability of ml-based net- work intrusion detection. Big Data Research, 30:100359, 2022

    2022

  18. [27]

    P4-Utils: Extension to Mininet that makes P4 networks easier to build, run and debug, 9 2021

    ETH Zurich NSG. P4-Utils: Extension to Mininet that makes P4 networks easier to build, run and debug, 9 2021. P4-NIDS, Intrusion Detection in P4 19

    2021

  19. [28]

    In-Line Any-Depth Deep Neural Networks Using P4 Switches

    Paolini, Emilio and De Marinis, Lorenzo and Scano, Davide and Paolucci, Francesco. In-Line Any-Depth Deep Neural Networks Using P4 Switches. IEEE Open Journal of the Communications Society, 5(May):3556–3567, 2024

    2024

  20. [29]

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

    Bob Lantz, Brandon Heller, and Nick McKeown. A Network in a Laptop: Rapid Prototyping for Software-Defined Networks. In Proceedings of the 9th ACM SIG- COMM Workshop on Hot Topics in Networks, pages 1–6, 2010

    2010

  21. [30]

    P4 16 language specification, 5 2017

    The P4 Language Consortium. P4 16 language specification, 5 2017

    2017

  22. [31]

    https: //github.com/esnet/iperf

    iPerf3: A TCP, UDP, and SCTP network bandwidth measurement tool. https: //github.com/esnet/iperf. Accessed: 24-05-2024

    2024

  23. [32]

    Ghorbani

    Iman Sharafaldin, Arash Habibi Lashkari, and Ali A. Ghorbani. Toward generating a new intrusion detection dataset and intrusion traffic characterization. ICISSP 2018 - Proceedings of the 4th International Conference on Information Systems Security and Privacy, 2018-January:108...

    2018

  24. [33]

    UNSW-NB15: A Comprehensive Data set for Net- work Intrusion Detection systems (UNSW-NB15 Network Data Set)

    Nour Moustafa and Jill Slay. UNSW-NB15: A Comprehensive Data set for Net- work Intrusion Detection systems (UNSW-NB15 Network Data Set). In Military communications and information systems conference (MilCIS) (pp. 1-6). IEEE., pages 1–6. IEEE, 2015

    2015

  25. [34]

    Pktgen-DPDK: DPDK Based Packet Generator, 2024

    Pktgen Project. Pktgen-DPDK: DPDK Based Packet Generator, 2024. Accessed: 2024-11-02

    2024

  26. [35]

    DPDK: Data Plane Development Kit, 2024

    DPDK Project. DPDK: Data Plane Development Kit, 2024. Accessed: 2024-11-02

    2024

  27. [36]

    Software development - p4c sdk

    Netronome Support. Software development - p4c sdk. Accessed: 2024-11-15

    2024

  28. [37]

    Software development - nfp toolchain

    Netronome Support. Software development - nfp toolchain. Accessed: 2024-11-15

    2024

  29. [38]

    Programming protocol- independent packet processors high-level programming (p4hlp): Towards unified high-level programming for a commodity programmable switch

    Zijun Hang, Mei Wen, Yang Shi, and Chunyuan Zhang. Programming protocol- independent packet processors high-level programming (p4hlp): Towards unified high-level programming for a commodity programmable switch. Electronics, 8(9):958, 2019

    2019

Pith tools

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