Pith. sign in

REVIEW 4 major objections 5 minor 59 references

A programmable switch can build a limit order book and run market prediction in the data plane, cutting latency by over 10% versus a server benchmark.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-04 07:35 UTC pith:4XLIVNGY

load-bearing objection A genuine first for in-network LOB construction and ML inference on a switch, but the prototype doesn't handle MBO cancel/update actions, so the LOB it maintains isn't the real book and the headline numbers are computed on corrupted state. the 4 major comments →

arxiv 2608.02424 v1 pith:4XLIVNGY submitted 2026-08-03 cs.NI cs.CEcs.ET

In-Network Market Prediction Using Machine Learning and Limit Order Books

Xinpeng Hong , Changgang Zheng , Joshua Lilley , Stefan Zohren , Noa Zilberman This is my paper
classification cs.NI cs.CEcs.ET
keywords in-network machine learningprogrammable switcheslimit order bookmarket-by-order datahigh-frequency tradingprice movement predictionhybrid inferenceP4 data plane
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper's central claim is that programmable network switches can do more than forward packets: they can reconstruct a stock's limit order book from market-by-order feeds and run small machine-learning models on that book to predict short-term price moves, all at microsecond-scale latency. If true, high-frequency trading systems could move prediction from servers into the network path and remove a host round-trip. The authors demonstrate this with a prototype on a hardware switch, an emulated next-generation switch, and a software switch, comparing against server-based models. The software target stays within a few percent of server accuracy and F1, the hardware target retains about 72% of precision and 64% of F1 on average, and a hybrid switch-plus-server design keeps roughly 45% of traffic and 38% of transaction value on the switch while holding the average error-rate change near 3%.

Core claim

On the paper's own terms, the discovery is that a limit order book—a stateful structure normally maintained by an exchange matching engine—can be constructed and updated entirely inside a programmable switch pipeline, and the same pipeline can extract features and run a pre-trained tree-based model on every message. Quantitatively: microsecond-scale end-to-end latency with over 10% reduction versus an exchange order-matching server benchmark; line-rate throughput; average hardware-target precision and F1 at roughly 72% and 64% of the server benchmark; near-server performance on the software target; and a hybrid deployment that handles about 45% of traffic and 38% of transaction value on the

What carries the argument

The load-bearing mechanism is the in-switch limit-order-book update algorithm. Because hardware switches cannot loop and can access a register only once per pipeline pass, the authors flatten matching into parallel per-price-level comparisons: each level compares its stored volume with the order's remaining size and its price with the current best bid and ask; one of four outcomes decides whether to add volume, consume volume, or leave residual size. Recirculation provides a second pipeline pass to write updated state back. The maintained book feeds feature extraction, mid-price labeling, and the mapped tree-based model in the same data plane.

Load-bearing premise

The evaluation assumes the switch-maintained order book accurately mirrors the real exchange book; the current prototype does not process cancellation or modification messages, so with frequent cancellations the book—and therefore the features and labels—can drift from the true state.

What would settle it

Replay a market-by-order feed with frequent cancellations through the current prototype and compare the switch's maintained best bid/ask and level volumes against a correct server-side reconstruction; any divergence invalidates the ML labels. Separately, reproduce the end-to-end latency measurement on the same hardware with the same exchange order-matching benchmark to verify the claimed over-10% reduction.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Programmable switches can host stateful financial data processing, not just stateless packet forwarding.
  • Prediction can happen in the network path, yielding microsecond-level latency and over 10% reduction versus an exchange order-matching server benchmark.
  • Tree-ensemble models fit switch constraints well enough to keep accuracy within a few percent of server models on a software target and within about 25-35% on a hardware target.
  • Hybrid deployment with a confidence threshold gives operators a tunable trade-off: roughly 45% of traffic and 38% of transaction value can be handled on-switch while the average error-rate change stays near 3%.
  • The same generated pipeline can be applied to different stocks and sectors with consistent behavior.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The authors leave implicit that the same pipeline could serve other microstructure targets—spread, depth, volatility, or trade sign—by changing only the label and retraining; nothing in the architecture is specific to mid-price direction.
  • The acknowledged gap on cancellation and modification messages means the reported ML metrics describe the switch-maintained book; a natural next experiment is to replay a feed with heavy cancellations and measure how far the switch book's best prices and volumes drift from a true server-side reconstruction.
  • The hardware resource trade-off suggests a testable scaling law: as switch ASICs gain stages and memory, increasing book depth from three to ten price levels should close most of the remaining accuracy gap, which the authors' emulation of a less-constrained target already hints at.
  • One could generalize the hybrid design to per-stock or dynamic confidence thresholds rather than a single fixed threshold, using the authors' observed threshold-error-rate curves as calibration data.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents LOBIN, a P4-based in-network system that maintains a limit order book (LOB) from market-by-order (MBO) feeds, extracts LOB features, and runs pretrained ML models for short-horizon mid-price movement prediction on programmable switches (BMv2, Intel Tofino, and emulated Tofino 2). The authors also propose a hybrid deployment in which low-confidence switch predictions are forwarded to a server-side model. The evaluation uses one day of NASDAQ TotalView-ITCH data for three stocks and reports ML metrics (precision, recall, F1, accuracy) for several models, relative latency and throughput on Tofino, and hybrid-deployment results claiming about 45% of traffic and 38% of transaction value processed on-switch with only about 3% error-rate degradation. The paper concludes that LOBIN achieves microsecond-level latency and over 10% latency reduction relative to a server benchmark.

Significance. If the evaluation is sound, LOBIN would be a valuable proof of concept: it shows that LOB construction, feature extraction, and ML inference can coexist in the data plane, and that a hybrid switch/server design can cut latency and server load with a small accuracy penalty. The use of public NASDAQ data, multiple ML models, two hardware/software targets, and a reproducible benchmark framework are strengths. However, the central claim of constructing a faithful LOB is undermined by the lack of support for MBO cancellation and update actions in the described algorithms, and the evaluation methodology omits a train/test split and reports only point estimates. These issues must be resolved before the headline results can be accepted.

major comments (4)
  1. [Section III-A, Algorithms 1-2, Section VI] The MBO action field is stated to include add, cancel, and update (Section III-A), yet Algorithms 1 and 2 do not branch on this field, do not track order IDs, and provide no explicit handling of cancellation or replacement messages. In Algorithm 1, a cancel message with Po < Pa is treated as a new order and line 18 executes R_l[Po] += So, inflating depth and potentially misplacing best-bid/ask registers. Algorithm 2 has the same structure. The paper concedes this in Section VI: 'LOBIN does not store MBO states but can update volumes within LOBs, allowing for order cancellations and updates, with minor changes to the current prototype.' Since the ML features and labels in Section V-A are computed from this maintained LOB, Table I and the hybrid results in Figure 8 are based on a book that can diverge from the real exchange book. This is load-bearing: the paper claims LOBIN 'constructs lim
  2. [Section V-A] The evaluation does not report a train/test split, cross-validation, or repeated runs. The text says the server benchmarks avoid overfitting, but no split is described. Without a held-out test set, the reported accuracies, F1 scores, and especially the 'optimal' confidence thresholds in Section V-C can be optimistically biased. The dataset is also a single trading day (January 30, 2020) for three stocks, so the generalization claim is thin. The authors should provide the split (or cross-validation), report confidence intervals, and temper the cross-stock conclusions.
  3. [Section V-C and Abstract] The headline hybrid-deployment numbers—'approximately 45% of the traffic' and '38% of the total potential transaction value' with 'average change in error rate around 3%'—are not supported by the per-stock data in Figure 8 as presented. The thresholds are selected per stock (0.98 for EXC, 0.96 for AZN), and the reported switch fractions are about 20% for FANG, 48.12% for EXC, and 27.81% for AZN; the aggregate 45% requires a clear weighting (by message count or value) and the error-rate change needs to be defined across the three stocks at the selected thresholds. As written, the aggregate claim appears to conflate per-stock optimal thresholds with an average, and the 'around 3%' figure is not derived from a transparent procedure.
  4. [Section V-B] The claim of 'over a 10% reduction in latency compared to the NASDAQ order-matching server benchmark' is based on comparing LOBIN's relative latency (Figure 7) to an external benchmark from reference [56], not on a same-testbed measurement. The paper itself notes the Tofino latency is under NDA and reports only ratios to switch.p4, so the absolute latency and the comparison basis are unclear. The authors should either measure the server benchmark in the same testbed or clearly state the conditions under which the 10% improvement is obtained, including that the external benchmark excludes ML inference.
minor comments (5)
  1. [Section I and Table I] The introduction says Tofino 2 is an 'emulation environment,' but Table I and the text sometimes treat it as a hardware target. Clarify that Tofino 2 results are emulated, not measured, in the table caption and around Figure 6.
  2. [Algorithm 2] Line 33 uses the bound 'P_h' in the for loop, but P_h is never defined in the pseudocode or in the variable list. The intended bound (presumably the highest price level in the LOB) should be stated.
  3. [Table I] The table includes 'KM' (k-means) as a classifier, but k-means is a clustering algorithm. Clarify how it is used for classification (e.g., cluster labels assigned to training data) since the comparison otherwise mixes methods.
  4. [Section V-A] The text says 'around 440K entries from three distinct stocks' and later mentions 'all MBO messages for each trading day.' Please state whether 440K is the total number of MBO messages across all three stocks or per stock, and clarify how missing consecutive days may affect the feature/label construction.
  5. [Section VI] There is a typo in the opening sentence: 'LOBsBy Design' should be 'LOBs by design.' Also, the statement that LOBIN 'can update volumes within LOBs, allowing for order cancellations and updates' is misleading given the algorithms lack action handling; this should be corrected to align with the actual implementation.

Circularity Check

0 steps flagged

No circularity: LOBIN is an empirical system evaluation; self-citations are to independent tools, and the acknowledged MBO-state limitation is a correctness risk, not a definitional reduction.

full rationale

LOBIN contains no derivation chain that reduces to its inputs. The central claims are implementation and measurement: P4 LOB maintenance (Section IV, Algorithms 1-2), ML inference generated by Planter [39], and evaluation against public NASDAQ TotalView-ITCH data and a server benchmark (Table I, Figures 7-8). Training on LOB features to predict future mid-price movement is standard supervised forecasting, not a case where X is defined in terms of Y: labels are 100-tick future movements, not the features themselves. The hybrid-deployment percentages (45% traffic, 38% value, ~3% error change) are measured outcomes of threshold selection, not fitted parameters renamed as predictions. Self-citations to Planter [39], IIsy [47], and the earlier stateless-market-prediction work [42] are to separate published systems/results with independent content; none is a uniqueness theorem or an ansatz that forces the paper's conclusions. The Discussion (Section VI) limitation, 'LOBIN does not store MBO states but can update volumes within LOBs, allowing for order cancellations and updates, with minor changes to the current prototype,' is flagged: since Algorithms 1-2 do not branch on the MBO action field, the in-switch LOB may diverge from the true book, so the reported ML numbers may be computed on corrupted state. That is a correctness/soundness risk, not circularity; the evaluation still measures the implemented prototype against external data with no equation or fitted value equal to the result by construction.

Axiom & Free-Parameter Ledger

2 free parameters · 5 axioms · 0 invented entities

The ledger captures what the evaluation assumes. The ML models are trained on market data, which is normal fitting, but the paper does not state a train/test split and the hardware-derived feature limits vary across targets. The hybrid confidence thresholds are genuine free parameters fitted to the evaluation results. The LOB-update fidelity assumption is the most important: as pseudocoded, only add/match events are processed and cancel/update actions are deferred, so the data-plane LOB may not equal the real book. The external benchmark assumption underpins the headline latency claim.

free parameters (2)
  • Hybrid confidence threshold = 0.98 (EXC), 0.96 (AZN); per-stock selection used for aggregate result
    Thresholds are chosen 'by adjusting ... to optimal levels' on test data (Sec. V-C, Fig. 8); the 45%/38%/3% aggregate figures depend on these choices.
  • ML model hyperparameters and feature dimensions = Tofino: DT depth<=4, RF/XGB 4 trees/depth<=3, 3 LOB levels; Server: depth<=20, up to 300 trees, 10 levels
    Model complexity is constrained by hardware and trained on the same day's data; without an explicit train/test split or confidence intervals, accuracy comparisons across targets are not fully controlled.
axioms (5)
  • domain assumption The P4 LOB update procedure accurately reflects exchange matching (price/time priority) using aggregate volume at price levels, without per-order state.
    Algorithms 1-2 process each MBO as an add/matching event; cancel/update actions are not implemented ('minor changes' per Discussion), so the maintained LOB may diverge from the true book.
  • domain assumption MBO messages extracted from NASDAQ TotalView-ITCH sample are correctly reconstructed and representative.
    Single date Jan 30, 2020, three stocks; relies on external ITCH converter [53].
  • domain assumption LOB price levels (up to 10 on server/BMv2, 3 on Tofino) and mid-price provide sufficient features for the 100-tick prediction task.
    Follows prior literature [11][12] but not independently justified here; different feature counts across targets confound accuracy comparisons.
  • domain assumption Planter-generated in-network models preserve the server-trained model's decision behavior sufficiently for evaluation.
    Uses own prior framework [39]; no formal equivalence proof, though validation via accuracy table.
  • domain assumption The NASDAQ order-matching benchmark latency [56] is a valid baseline for the claimed >10% improvement.
    Tofino absolute latency is under NDA; comparison is indirect between different hardware/software stacks.

pith-pipeline@v1.3.0-daily-deepseek · 17278 in / 13917 out tokens · 134290 ms · 2026-08-04T07:35:57.488507+00:00 · methodology

0 comments
read the original abstract

Machine learning is significantly transforming algorithmic trading, yet the requirement for rapid execution speeds persists. While both aspects aim to boost profitability, embedding advanced machine-learning techniques with reduced trading latency presents a notable challenge. Adopting in-network machine learning, which involves offloading inference to programmable network devices, offers a delicate equilibrium in this trade-off. In this paper, we present LOBIN, a solution that utilizes machine learning within the network for market prediction based on high-frequency market data feeds. LOBIN is adept at constructing limit order books and performing inference directly within programmable switches. When compared to server-based benchmarks, LOBIN not only predicts future stock price movements with higher throughput but also maintains robust machine learning performance. It achieves over a 10% reduction in latency compared to the NASDAQ order-matching server benchmark and delivers microsecond-level latency. Furthermore, the machine learning performance of LOBIN can be further enhanced through the adoption of a hybrid deployment approach that integrates both the switch and the servers. Our evaluation demonstrates that among all data feeds of evaluated stocks, the application of hybrid deployment results in approximately 45% of the traffic and 38\% of the total potential transaction value being processed within switches without server intervention, reducing latency while ensuring that the average change in error rate of predictions remains at around 3% relative to benchmarks based solely on server use.

Figures

Figures reproduced from arXiv: 2608.02424 by Changgang Zheng, Joshua Lilley, Noa Zilberman, Stefan Zohren, Xinpeng Hong.

Figure 1
Figure 1. Figure 1: General working scenario of LOBIN. electrical power within the HFT industry [6], which are considered detrimental to long-term and sustainable finance. In-network computing offloads applications to run within programmable network devices [7]. In-network ML, as a specific type of in-network computing, deploys pre-trained ML models within network devices and conducts inference there for lower latency, higher… view at source ↗
Figure 2
Figure 2. Figure 2: Workflow of updating a LOB with MBO feeds. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: An illustration of how MBO data updates a LOB. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: System design of LOBIN. are used to train an ML model, using LOB-based features. The trained model ⃝1 is mapped to the data plane ⃝2 , and table entries are generated. The mapping includes generating a P4 program ⃝3 , which contains both the mapped model and LOB-related logic: LOB construction and update, and feature extraction. The generated P4 program is loaded to the programmable data plane ⃝4 , while t… view at source ↗
Figure 5
Figure 5. Figure 5: Box plots of precision, recall, F1-score, and accuracy across ML [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: (a) The pipeline relative latency (R-Latency) on Tofino for different [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 6
Figure 6. Figure 6: The average ratio (%) of precision, recall, F1-score, and accuracy [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: The accuracy, the error rate, the fraction (Frac.) of traffic offloaded [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

59 extracted references · 2 linked inside Pith

  1. [1]

    Does Algorithmic Trading Improve Liquidity?

    T. Hendershott, C. M. Jones, and A. J. Menkveld, “Does Algorithmic Trading Improve Liquidity?”J Finance, vol. 66, no. 1, pp. 1–33, 2011

    2011

  2. [2]

    High Frequency Trading,

    P. Gomberet al., “High Frequency Trading,” inEncyclopedia of Infor- mation Science and Technology. IGI Global, 2015, pp. 1–9

    2015

  3. [3]

    High-Frequency Trading and Market Performance,

    M. Baldauf and J. Mollner, “High-Frequency Trading and Market Performance,”J Finance, vol. 75, no. 3, pp. 1495–1526, 2020

    2020

  4. [4]

    Machine Learning for Market Mi- crostructure and High Frequency Trading,

    M. Kearns and Y . Nevmyvaka, “Machine Learning for Market Mi- crostructure and High Frequency Trading,”High Frequency Trading: New Realities for Traders, Markets, and Regulators, 2013

    2013

  5. [5]

    Automated Trading Systems Statistical and Machine Learning Methods and Hardware Implementation: A Survey,

    B. Huanget al., “Automated Trading Systems Statistical and Machine Learning Methods and Hardware Implementation: A Survey,”Enterprise Information Systems, vol. 13, no. 1, pp. 132–144, 2019

    2019

  6. [6]

    One Day, the Stock Market Could Eat the Power Grid,

    J. Stokes, “One Day, the Stock Market Could Eat the Power Grid,” Wired, 2011. [Online]. Available: https://www.wired.com/insights/2011/ 12/stock-market-power/

    2011

  7. [7]

    The Case for In-network Computing on Demand,

    Y . Tokusashiet al., “The Case for In-network Computing on Demand,” inProceedings of the Fourteenth EuroSys Conference 2019, 2019

    2019

  8. [8]

    Can the Network be the AI Accelerator?

    D. Sanvito, G. Siracusano, and R. Bifulco, “Can the Network be the AI Accelerator?” inNetCompute, 2018, pp. 20–25

    2018

  9. [9]

    Do Switches Dream of Machine Learning? Toward In-Network Classification,

    Z. Xiong and N. Zilberman, “Do Switches Dream of Machine Learning? Toward In-Network Classification,” inHotNets, 2019, pp. 25–33

    2019

  10. [10]

    Modelling High-Frequency Limit Order Book Dynamics with Support Vector Machines,

    A. N. Kercheval and Y . Zhang, “Modelling High-Frequency Limit Order Book Dynamics with Support Vector Machines,”Quantitative Finance, vol. 15, no. 8, pp. 1315–1329, 2015

    2015

  11. [11]

    Benchmark Dataset for Mid Price Forecasting of Limit Order Book Data with Machine Learning Methods,

    A. Ntakariset al., “Benchmark Dataset for Mid Price Forecasting of Limit Order Book Data with Machine Learning Methods,”Journal of Forecasting, vol. 37, no. 8, pp. 852–866, 2018

    2018

  12. [12]

    DeepLOB: Deep Convolutional Neural Networks for Limit Order Books,

    Z. Zhang, S. Zohren, and S. Roberts, “DeepLOB: Deep Convolutional Neural Networks for Limit Order Books,”IEEE Transactions on Signal Processing, vol. 67, no. 11, pp. 3001–3012, 2019

    2019

  13. [13]

    Using Deep Learning for Price Prediction by Ex- ploiting Stationary Limit Order Book Features,

    A. Tsantekidiset al., “Using Deep Learning for Price Prediction by Ex- ploiting Stationary Limit Order Book Features,”Applied Soft Computing, vol. 93, p. 106401, 2020

    2020

  14. [14]

    Who Benefits from an Open Limit-Order Book?

    S. Baruch, “Who Benefits from an Open Limit-Order Book?”The Journal of Business, vol. 78, no. 4, pp. 1267–1306, 2005

    2005

  15. [15]

    “Tofino,” https://www.barefootnetworks.com/products/brief-tofino/

  16. [16]

    The Reference P4 Software Switch,

    “The Reference P4 Software Switch,” https : / / github. com / p4lang / behavioral-model

  17. [17]

    Time Series Forecasting for Nonlinear and Non- stationary Processes: A Review and Comparative Study,

    C. Chenget al., “Time Series Forecasting for Nonlinear and Non- stationary Processes: A Review and Comparative Study,”Iie Transac- tions, vol. 47, no. 10, pp. 1053–1071, 2015

    2015

  18. [18]

    A Survey on Machine Learning for Stock Price Prediction: Algorithms and Techniques,

    M. Obthonget al., “A Survey on Machine Learning for Stock Price Prediction: Algorithms and Techniques,”FEMIB, 2020

    2020

  19. [19]

    Evaluating Multiple Classifiers for Stock Price Direction Prediction,

    M. Ballingset al., “Evaluating Multiple Classifiers for Stock Price Direction Prediction,”Expert systems with Applications, vol. 42, no. 20, pp. 7046–7056, 2015

    2015

  20. [20]

    Predicting Stock and Stock Price Index Movement Using Trend Deterministic Data Preparation and Machine Learning Techniques,

    J. Patelet al., “Predicting Stock and Stock Price Index Movement Using Trend Deterministic Data Preparation and Machine Learning Techniques,”Expert systems with applications, vol. 42, no. 1, pp. 259– 268, 2015

    2015

  21. [21]

    Predicting the Direction of Stock Market Prices Using Tree-based Classifiers,

    S. Basaket al., “Predicting the Direction of Stock Market Prices Using Tree-based Classifiers,”North Am. J. Econ. Finance, vol. 47, pp. 552– 567, 2019

    2019

  22. [22]

    Risk and Return in High-Frequency Trading,

    M. Baronet al., “Risk and Return in High-Frequency Trading,”JFQA, vol. 54, no. 3, 2019

    2019

  23. [23]

    Accelerating Recurrent Neural Networks in Ana- lytics Servers: Comparison of FPGA, CPU, GPU, and ASIC,

    E. Nurvitadhiet al., “Accelerating Recurrent Neural Networks in Ana- lytics Servers: Comparison of FPGA, CPU, GPU, and ASIC,” inFPL. IEEE, 2016, pp. 1–4

    2016

  24. [24]

    FPGA Accelerated Low- Latency Market Data Feed Processing,

    G. W. Morris, D. B. Thomas, and W. Luk, “FPGA Accelerated Low- Latency Market Data Feed Processing,” in2009 17th IEEE Symposium on High Performance Interconnects. IEEE, 2009, pp. 83–89

    2009

  25. [25]

    A Scalable Architecture for Low-Latency Market-Data Processing on FPGA,

    Q. Tanget al., “A Scalable Architecture for Low-Latency Market-Data Processing on FPGA,” inISCC. IEEE, 2016, pp. 597–603

    2016

  26. [26]

    Streaming, Low-latency Communication in On-line Trading Systems,

    H. Subramoni, F. Petriniet al., “Streaming, Low-latency Communication in On-line Trading Systems,” inIPDPSW. IEEE, 2010, pp. 1–8

    2010

  27. [27]

    Announcing DPU-based Ac- celeration for NSX,

    V . Santosh and S. Singh, “Announcing DPU-based Ac- celeration for NSX,”VMWare, 2022. [Online]. Avail- able: https : / / blogs . vmware . com / networkvirtualization / 2022 / 08 / announcing-dpu-based-acceleration-for-nsx.html/

    2022

  28. [28]

    AMD Announces New Alveo X3 Se- ries for Electronic Trading,

    AMD, “AMD Announces New Alveo X3 Se- ries for Electronic Trading,”HPC Wire, 2022. [Online]. Available: https : / / www. hpcwire . com / off-the-wire / amd-announces-new-alveo-x3-series-for-electronic-trading/

    2022

  29. [29]

    A Low-Latency Library in FPGA Hardware for High-Frequency Trading (HFT),

    J. W. Lockwoodet al., “A Low-Latency Library in FPGA Hardware for High-Frequency Trading (HFT),” inHOTI. IEEE, 2012, pp. 9–16

    2012

  30. [30]

    SDN Security: A Survey,

    S. Scott-Hayward, G. O’Callaghan, and S. Sezer, “SDN Security: A Survey,” in2013 IEEE SDN4FNS. IEEE, 2013, pp. 1–7

    2013

  31. [31]

    P4: Programming Protocol-Independent Packet Processors,

    P. Bosshartet al., “P4: Programming Protocol-Independent Packet Processors,”ACM SIGCOMM CCR, vol. 44, no. 3, pp. 87–95, 2014

    2014

  32. [32]

    McKeown,PISA: Protocol Independent Switch Architecture, 2015, P4 Workshop

    N. McKeown,PISA: Protocol Independent Switch Architecture, 2015, P4 Workshop

    2015

  33. [33]

    P4Pi: P4 on Raspberry Pi for Networking Education,

    S. Lakiet al., “P4Pi: P4 on Raspberry Pi for Networking Education,” ACM SIGCOMM CCR, vol. 51, no. 3, pp. 17–21, 2021

    2021

  34. [34]

    The P4→NetFPGA Workflow for Line-Rate Packet Processing,

    S. Ibanezet al., “The P4→NetFPGA Workflow for Line-Rate Packet Processing,” inProceedings of the ACM FPGA 2019, 2019, pp. 1–9

    2019

  35. [35]

    NetCache: Balancing Key-Value Stores with Fast In- Network Caching,

    X. Jinet al., “NetCache: Balancing Key-Value Stores with Fast In- Network Caching,” inProceedings of the 26th SOSP, 2017, pp. 121–136

    2017

  36. [36]

    P4xos: Consensus as a Network Service,

    H. T. Danget al., “P4xos: Consensus as a Network Service,”IEEE/ACM ToN, vol. 28, no. 4, pp. 1726–1738, 2020

    2020

  37. [37]

    Scaling Distributed Machine Learning with In-network Aggregation,

    A. Sapioet al., “Scaling Distributed Machine Learning with In-network Aggregation,”arXiv preprint arXiv:1903.06701, 2019

    Pith/arXiv arXiv 1903

  38. [38]

    ATP: In-network Aggregation for Multi-tenant Learning,

    C. Laoet al., “ATP: In-network Aggregation for Multi-tenant Learning,” inNSDI’21. USENIX Association, Apr. 2021, pp. 741–761. [Online]. Available: https://www.usenix.org/conference/nsdi21/presentation/lao

    2021

  39. [39]

    Planter: Rapid Prototyping of In-Network Machine Learning Inference,

    C. Zhenget al., “Planter: Rapid Prototyping of In-Network Machine Learning Inference,”ACM SIGCOMM Computer Communication Re- view, vol. 54, no. 1, pp. 2–21, 2024

    2024

  40. [40]

    SwitchTree: In-network Computing and Traffic Analyses with Random Forests,

    J.-H. Lee and K. Singh, “SwitchTree: In-network Computing and Traffic Analyses with Random Forests,”Neural. Comput. Appl., pp. 1–12, 2020

    2020

  41. [41]

    Toward continuous threat defense: In-network traffic analysis for iot gateways,

    M. Zanget al., “Toward continuous threat defense: In-network traffic analysis for iot gateways,”IEEE Internet of Things Journal, vol. 11, no. 6, pp. 9244–9257, 2023

    2023

  42. [42]

    Automating In-Network Machine Learning,

    C. Zhenget al., “Automating In-Network Machine Learning,”arXiv preprint arXiv:2205.08824, 2022

    Pith/arXiv arXiv 2022

  43. [43]

    Machine Learning for Microstructure Data-Driven Execution Algorithms,

    P. Nagy, J. Powrie, and S. Zohren, “Machine Learning for Microstructure Data-Driven Execution Algorithms,”Handbook of Artificial Intelligence and Big Data Applications in Investments, p. 100, 2023

    2023

  44. [44]

    Deep Learning for Market by Order Data,

    Z. Zhang, B. Lim, and S. Zohren, “Deep Learning for Market by Order Data,”Applied Mathematical Finance, vol. 28, no. 1, pp. 79–95, 2021

    2021

  45. [45]

    Limit Order Books,

    M. D. Gouldet al., “Limit Order Books,”Quantitative Finance, vol. 13, no. 11, pp. 1709–1742, 2013

    2013

  46. [46]

    Limit Order Markets: A Survey,

    C. A. Parlouret al., “Limit Order Markets: A Survey,”Handbook of financial intermediation and banking, vol. 5, pp. 63–95, 2008

    2008

  47. [47]

    IIsy: Hybrid In-Network Classification Using Pro- grammable Switches,

    C. Zhenget al., “IIsy: Hybrid In-Network Classification Using Pro- grammable Switches,”IEEE/ACM Transactions on Networking, 2024

    2024

  48. [48]

    Compiling P4 to eBPF,

    “Compiling P4 to eBPF,” https://github.com/iovisor/bcc/tree/master/src/ cc/frontends/p4

  49. [49]

    BF6064X-T Advanced Programmable Switch,

    APS Networks, “BF6064X-T Advanced Programmable Switch,” https: //www.aps-networks.com/wp-content/uploads/2021/07/210712 APS BF6064X-T V04.pdf[Online, accessed Feb-2023]

    2021

  50. [50]

    A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research,

    F. Hauseret al., “A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research,”Journal of Network and Computer Applications, p. 103561, 2022

    2022

  51. [51]

    Nasdaq ITCH Data Source,

    “Nasdaq ITCH Data Source,” 2020. [Online]. Available: https: //emi.nasdaq.com/ITCH/Nasdaq%20ITCH/

    2020

  52. [52]

    Nasdaq TotalView-ITCH 5.0,

    “Nasdaq TotalView-ITCH 5.0,” 2014. [Online]. Available: https://www.nasdaqtrader.com/content/technicalsupport/specifications/ dataproducts/NQTVITCHSpecification.pdf

    2014

  53. [53]

    martinobdl/ITCH: ITCH50Converter,

    M. Bernasconi-De-Lucaet al., “martinobdl/ITCH: ITCH50Converter,”

  54. [54]

    Scikit-learn: Machine Learning in Python,

    F. Pedregosaet al., “Scikit-learn: Machine Learning in Python,”JMLR, vol. 12, pp. 2825–2830, 2011

    2011

  55. [55]

    SMOTE: Synthetic Minority Over-sampling Technique,

    N. V . Chawlaet al., “SMOTE: Synthetic Minority Over-sampling Technique,”JAIR, vol. 16, pp. 321–357, 2002

    2002

  56. [56]

    Latency and Liquidity Provision in a Limit Order Book,

    J. Bonart and M. D. Gould, “Latency and Liquidity Provision in a Limit Order Book,”Quant. Finance, vol. 17, no. 10, pp. 1601–1616, 2017

    2017

  57. [57]

    DINC: Toward Distributed In-Network Computing,

    C. Zhenget al., “DINC: Toward Distributed In-Network Computing,” Proceedings of the ACM on Networking, vol. 1, no. CoNEXT3, pp. 1–25, 2023

    2023

  58. [58]

    JAX-LOB: A GPU-Accelerated Limit Order Book Simulator to Unlock Large Scale Reinforcement Learning for Trading,

    S. Y . Freyet al., “JAX-LOB: A GPU-Accelerated Limit Order Book Simulator to Unlock Large Scale Reinforcement Learning for Trading,” inICAIF, 2023, pp. 583–591

    2023

  59. [2021]

    Available: https://zenodo.org/record/5209267

    [Online]. Available: https://zenodo.org/record/5209267

    arXiv