NSDI '26#

Core#

Matryoshka: Realizing Hyperscale Data Center Network Design for the AI Era#

Abstract Paper Slides Recording

Yan Cai, Jialong Li (Max Planck Institute for Informatics), Kutalmis Akpinar, Tianxiang Li, Hany Morsy, Jason Wilson, Sunil Khaunte (Meta), Yiting Xia (MPI), Ying Zhang (Meta), et al.

• Why: The gap this paper names — between logical DCN designs and the concrete switch configurations that realize them — is exactly the "last mile" problem anyone running multi-generation fabric automation knows. It's also the clearest public account yet of how a hyperscaler's DCN tooling strains under AI-cluster growth.
• What: Meta's production DCN design system, operational for 6+ years, that compiles high-level design intent (physical connectivity, addressing, routing policy) into working switch configurations. It has guided the design of nearly 900 DCs across 18 distinct types, including Meta's latest 100K-GPU training supercluster.
• How: Intent-based, model-driven compilation: DCN designs are expressed as machine-readable models and systematically compiled down to per-switch configs, so design, addressing, and routing evolve together and heterogeneous cluster types are treated as first-class variants rather than snowflakes.
• Where applicable: Meta-specific production experience, but the architecture pattern (model-driven intent-to-config compilation for rapidly evolving, heterogeneous AI fabrics) generalizes to any operator building multi-generation DCNs. The 6-year production track record and ~900-DC scale make the claims firmly substantiated.

OpenOptics: Enabling Open Research and Implementation of Optical Data Center Networks#

Abstract Paper Slides Recording

Yiming Lei, Federico De Marchi (Max Planck Institute for Informatics), Jialong Li (Shenzhen University of Advanced Technology), Raj Joshi (Harvard), Shu-Ting Wang (UC San Diego), Xiaoqi Chen (Purdue), Balakrishnan Chandrasekaran (VU Amsterdam), Yiting Xia (MPI)

• Why: Optical DCNs have been stuck as closed, hardware-tied ecosystems — every research prototype is bespoke. This is the first serious open framework, and it lowers the cost of experimenting with circuit-switched fabrics to "Python script" level. If you track OCS-based DC designs, this is the platform to watch.
• What: An open research/implementation framework that decouples optical DCN software from optical hardware. It implements six optical DCN architectures and seven routing schemes on a real testbed (108 ToRs) and achieves a 2 µs minimum optical circuit duration on commodity devices — a record for circuit-switched DCN granularity.
• How: Three pieces: a time-flow table abstraction as the common hardware/software interface, a unified workflow + Python API for defining optical DCNs, and a backend that re-architects queue management around time-flow tables so packets are staged for rapidly reconfiguring circuits.
• Where applicable: Broadly applicable to researchers and builders experimenting with optical/express-loop fabrics; requires programmable (P4-class) switches plus commodity optical hardware. Artifacts were evaluated and reproduced (available/functional/reproduced badges), so it is genuinely usable, not just described.

SyncWise: Error-Aware Time Synchronization for Reconfigurable Data Center Networks#

Abstract Paper Slides Recording

Yiming Lei (MPI for Informatics), Jialong Li (Shenzhen University of Advanced Technology), Zhengqing Liu (Imperial College London), Raj Joshi (Harvard), Yiting Xia (MPI)

• Why: As reconfigurable DCNs (OCS-based) shrink circuit durations to microseconds/sub-microseconds, accurate time sync becomes the correctness backbone of the whole fabric — and this paper shows the problem was previously unformalized. A foundational gap-fill for the reconfigurable-fabric subfield.
• What: The first time-synchronization protocol designed specifically for reconfigurable DCNs. It formalizes the RDCN sync problem, builds an RDCN-specific error model, and achieves provably optimal sync — sub-10 ns maximum sync error, well beyond what the most accurate traditional-DC protocols achieve.
• How: Uses the RDCN error model (sources of error specific to dynamic optical circuits) to guide "wise" selection of sync parents — choosing the peers whose sync exchanges will be least corrupted by circuit reconfiguration dynamics.
• Where applicable: Specific to OCS-based reconfigurable DCNs; prototyped on an Intel Tofino2 + OCS testbed with large-scale simulations backing the testbed numbers. Not relevant to static packet fabrics, but core reading for anyone evaluating express-loop/circuit-switched designs.

Starfish: A Topology-Routing Co-Design for Small-Scale Data Centers#

Abstract Paper Slides Recording

Anchengcheng Zhou (Princeton), Vipul Harsh (Conviva), Sangeetha Abdu Jyothi (UC Irvine), Maria Apostolaki (Princeton), Brighten Godfrey (UIUC)

• Why: Almost all DC topology research targets hyperscalers, yet most real data centers run hundreds to a few thousand servers on leaf-spine with painful cost/oversubscription tradeoffs. This is a rare, rigorous design for that population — directly useful if your fleet is enterprise/colo-scale rather than 100K-GPU.
• What: A topology-routing co-design (DRing topology + adaptive routing) that supports 56% more traffic than an equal-cost leaf-spine on real traces with the same equipment. The routing scheme also generalizes to expander topologies, where it yields 52% more traffic than leaf-spine — fixing expander designs' biggest deployment hurdle (no practical routing).
• How: DRing spreads servers across all switches to raise per-server egress capacity and expose diverse near-shortest paths; routing exploits DRing's structural properties and adapts to traffic using standard hardware and protocols — no exotic switching required.
• Where applicable: Small-to-mid data centers (hundreds–thousands of servers); uses standard equipment and protocols, making it unusually deployable for a topology paper. Artifact evaluated (available/functional/reproduced).

Learning to Tune Optical WANs: A Field Deployment of Noise Models in Optical Networks#

Abstract Paper Slides Recording

Bhaskar Kataria, Howard Hua (Cornell), Andrea D'Amico (NEC Labs), Bill Owens (NYSERNet), Rachee Singh (Cornell)

• Why: Rare example of physical-layer optimization (amplifier gain tuning) actually deployed in a live ISP backbone with measured results — the kind of ground-truth that usually stays inside vendor tooling.
• What: A Gaussian Noise model of a New York state ISP's optical backbone covering amplifiers, fiber spans, ROADM s, and transceivers; hyperparameter search over this model identifies amplifier gain settings that improve end-to-end SNR. In a live field deployment, the tuned settings achieved a 2 dB SNR improvement on a single wavelength.
• How: Model the full optical chain to predict end-to-end SNR accurately, then treat the model as an opaque box and run ML-style hyperparameter search over amplifier configurations under practical network constraints.
• Where applicable: Small/mid ISP optical backbones (NYSERNet-scale); the 2 dB single-wavelength result is modest but real. Techniques are broadly reusable for any operator that wants model-driven optical tuning instead of vendor-blessed defaults; not a hyperscale DWDM result.

BURST: Seeking High-performance, Interoperability and Scalability in Soft-RDMA#

Abstract Paper Recording

Huijun Shen (Hunan University), Zelong Yue, Jian Yang, et al. (ByteDance), Xijin Yin, et al. (Hunan University)

• Why: Heterogeneous pods — commercial RNICs, plain Ethernet NICs, in-house hardware — are now the norm, and non-RNIC↔RNIC traffic keeps falling back to TCP. ByteDance attacks exactly the interoperability wall that limits RDMA estate scaling during LLM-infra buildouts.
• What: A user-space software RDMA stack that runs unmodified Verbs applications on ordinary Ethernet NICs at 400G: 98.7% line-rate bandwidth, 3.2–6.3x kernel RXE throughput, LLM inference latency at 25.2% of TCP, and 12x faster connection setup than native RDMA CM.
• How: Runs as an independent user-space process with full Verbs API compatibility; lock-free DPDK data plane for line-rate packet processing; Intel DSA offload to cut CPU cost; kernel-bypass connection manager.
• Where applicable: Data centers with mixed NIC estates, especially where RNIC hardware can't be everywhere (storage-attached hosts, upgraded clusters). x86-specific today (DPDK + Intel DSA); ByteDance production-workload validation, academic authors.

CCC: Re-architecting Delay-based Congestion Control in Datacenter Networks#

Abstract Paper Recording

Wanchun Jiang, et al. (Central South University), Danfeng Shan (Xi'an Jiaotong), Fengyuan Ren (Tsinghua), Jiawei Huang, Jianxin Wang (Central South)

• Why: TIMELY/SWIFT-style delay CC runs in production, but the paper's key insight — that even perfectly measured delay can yield incorrect congestion-information deduction under certain conditions — explains instability modes practitioners see and haven't had a framework for.
• What: A re-architecture of delay-based CC that makes rate adjustments depend not just on congestion state but on trustworthiness of the deduction from delay signals. The resulting CCC matches INT-based CCs (HPCC, PowerTCP) using only delay — no INT headers, no special switch support — and beats DCQCN, TIMELY, and SWIFT.
• How: Demarcates operating regions where delay-derived congestion info is untrustworthy (using congestion criteria plus system inertia), applies probing-style rate adjustment there, and applies analytical adjustment elsewhere to reach the target state while keeping the deduction trustworthy.
• Where applicable: Standard datacenter fabrics — the whole point is needing nothing beyond RTT signals. Validated with DPDK testbeds and large-scale simulation. General technique, no hardware prerequisites; a serious competitor to deployable delay-based schemes like SWIFT.

OSCAR: O(1)-Step Convergence and Readily-deployable Congestion Control#

Abstract Paper Slides Recording

Zhaochen Zhang, Feiyang Xue, Rui Ning (Nanjing University), Keqiang He (SJTU), Gianni Antichi (Politecnico di Milano & QMUL), et al. — Awarded Outstanding Paper

• Why: The outstanding-paper pick of the congestion-control cluster. It removes the main barrier to fast-converging CC (precise INT headers that commodity high-speed hardware can't parse) while keeping constant-time convergence.
• What: The first CC achieving O(1)-step convergence — reaching fair share in constant time regardless of network conditions — without specialized network features. In large-scale simulations with realistic workloads it beats precise-INT-based CCs by 12–48% on average FCT and 40–74% on tail FCT.
• How: Insight that delay and delay gradient carry precision comparable to INT; then three techniques: accurate low-overhead delay-gradient estimation, eliminating overreaction in MIMD updates, and coordinating independent control loops toward a single target.
• Where applicable: Commodity datacenter hardware (no INT support needed); testbed evaluation under real-world noise plus large-scale simulation. Pairs naturally with CCC above — the two papers collectively argue delay signals can replace INT for the next generation of deployable DC CC.

Bifrost: Alibaba's Next-Generation VPC Network with High-Performance Multipath Reliable Transport#

Abstract Paper Slides Recording

Zihao Fan (SJTU and Alibaba Cloud), Xing Li (Zhejiang University and Alibaba Cloud), Ye Yang, et al. (Alibaba Cloud), Rong Wen (Fudan and Alibaba Cloud), Shunmin Zhu (Alibaba Cloud), et al.

• Why: This is the logical endpoint of the "TCP in the guest can't survive cloud-network instability" argument: Alibaba moved reliable, multipath transport into the VPC overlay infrastructure itself, tail-latency problem included. An operational-systems paper with 26x-scale production evidence.
• What: Next-gen VPC networking delivering reliable transport as an infrastructure service: up to 307x tail-latency reduction for Redis and 66x for Nginx, millisecond-level failure recovery, and O(100k) concurrent connections per SmartNIC.
• How: RTT-aware multipath packet spraying across the underlay (bypasses failures, spreads elephant flows), in-place reordering in the guest for in-order delivery, delayed bitmap ACKs for end-to-end reliability, and reliability-state management engineered for SmartNIC deployment at scale.
• Where applicable: Alibaba Cloud production (operational systems paper); requires SmartNIC-capable tunnel endpoints, so it presumes a cloud provider's level of control over the hypervisor/SmartNIC layer. The architecture — reliable multipath overlay as a tenant-transparent service — is the transferable idea.

ZooRoute: Enhancing Cloud-Scale Network Reliability via Candidate Path Provisioning and Overlay Proactive Rerouting#

Abstract Paper Slides Recording

Xiaoqing Sun (Alibaba Cloud), Xing Li (Zhejiang University and Alibaba Cloud), Xionglie Wei, et al. (Alibaba Cloud), Yang Xu (Fudan), Shunmin Zhu (Alibaba Cloud), et al.

• Why: Fast, deterministic failure recovery offered by the cloud provider instead of pushing HA plumbing onto tenants — an explicit product decision worth understanding. The mechanism is a clever use of an oft-ignored header field.
• What: A tenant-transparent, underlay-agnostic failure-recovery service, deployed 26 months in Alibaba Cloud: cumulative outage time reduced 93.19%, and 98.21% of failures masked from tenant awareness.
• How: Reroutes traffic by varying the outer source port on VXLAN encapsulation — different source ports hash to different underlay paths. Tunnel endpoints proactively probe a set of healthy source-port candidates per destination IP, guaranteeing one-shot deterministic reroute onto a known-good path. Engineering challenges addressed: hypervisor probing overhead, Tofino-gateway memory limits, and stateful middlebox disruption.
• Where applicable: Planet-scale cloud overlays (Alibaba production, Tofino gateways). The source-port-as-path-selector trick is broadly reusable in any ECMP-overlay network; the full proactive-probing service assumes provider control of both tunnel endpoints.

Express Lane to Efficiency and Reliability: Multi-Dimensional Control in Meta’s Express Backbone Network#

Abstract Paper Recording

Faisal Iqbal, Vitaly Neganov, et al. (Meta), Aditya Akella (UT Austin), Ying Zhang (Meta)

• Why: Meta's EBB is one of the largest WANs on earth, and this is the follow-up evolution under AI-era traffic pressure — useful as a reference point for how far you can push a mature multi-plane SDN WAN design before adding new control dimensions.
• What: An operational account of evolving EBB's control plane along two new dimensions beyond per-plane TE: Unequal Cost Multi-Path (UCMP) for cross-plane load balancing and Fast Re-Route (FRR) for rapid local failure detection/recovery — meeting AI-era efficiency and resiliency demands without fundamental architectural change.
• How: UCMP extends control across planes so traffic can be split unevenly across parallel planes for utilization; FRR adds per-device, time-slice control for sub-second failure handling. Both are described with design, implementation, and production results.
• Where applicable: Meta-specific production WAN, but the multi-dimensional control framing (global-across-planes + local-per-device + existing per-plane TE) is a clean conceptual model for any large multi-plane backbone. Real deployment experience, not simulation.

Offloading Cloud Network Services at Production Scale with SONiC DASH SmartSwitch#

Abstract Paper Slides Recording

Shaofeng Wu (CUHK and Microsoft Research Asia), Zhixiong Niu (MSRA), Riff Jiang, et al. (Microsoft), Hong Xu (CUHK) — Community Award Winner

• Why: A decade of Azure offload lessons distilled into an open, community-governed architecture — and a concrete datapoint that the DPU pool is collapsing back into the T1 switch itself. Directly relevant to where cloud-network offload roadmaps are heading.
• What: SONiC DASH SmartSwitch, deployed at Azure production scale for stateful network services: 1.53 Tbps throughput, 19.2M CPS, 256M concurrent connections, ~1.8x power efficiency and ~2.7x space efficiency over the prior generation.
• How: Three design lessons encoded: an immutable, hardware-friendly DASH pipeline programming model (vs. overly flexible models that block acceleration); a "uni-box" SmartSwitch converging NPU and DPU resources inside a single T1 switch (vs. appliance-style DPU pools); and community-driven P4 behavior specifications (vs. vendor SDKs).
• Where applicable: Built on the open SONiC/DASH ecosystem rather than a proprietary fork, so this is the rare Microsoft-scale result a non-hyperscaler can actually build on. Requires SmartSwitch-class hardware (integrated NPU+DPU in the T1).

KRAKENGUARD: Towards Fine-Grained eBPF Isolation#

Abstract Paper Slides Recording

Jainil Patel (IIT Roorkee), Lucas Graeff Buhl-Nielsen (Quantco), Adrien Ghosn (Microsoft), Marios Kogias (Imperial College London)

• Why: eBPF's security model is the dirty secret of the ecosystem — CAP_BPF is all-or-nothing, which is untenable as multi-tenant eBPF/XDP programs from different parties land on the same host. This is a serious attack on exactly that gap.
• What: A trusted user-space manager enforcing fine-grained, policy-driven constraints on eBPF bytecode at load time: restricting helper usage, memory/map access, and return values. It demonstrably blocks misuse in real-world programs, detects existing CVEs, and enables an XDP-as-a-Service use case where tenants' XDP programs run directly on the host interface without mutual interference.
• How: Symbolic execution of program paths at load time to check compliance with policy; cross-program interference detection to make co-location on the same hook safe.
• Where applicable: General Linux/eBPF environments — any platform running third-party or tenant-supplied eBPF. Load-time analysis (not runtime) so the cost is per-load; the trusted-manager design makes assumptions about who controls the host. Highly relevant to Cilium-style deployments where programs multiply across hooks.

HybridMesh: A Hardware-software Hybrid Approach for Accelerating Service Mesh Ingress#

Abstract Paper Slides Recording

Myoungsung You (University of Seoul), Jaehyun Nam (Dankook University), Minjae Seo (ETRI), Taejune Park (Chonnam National University), Seungwon Shin (KAIST)

• Why: The ingress gateway is the spot where service-mesh overhead is worst, and the paper quantifies it: up to 4x throughput loss from CPU-intensive traffic analysis plus a convoluted forwarding path. A clean answer to the "sidecar or no sidecar" debate's ingress half.
• What: A hybrid ingress gateway that puts traffic analysis and routing on a SmartNIC, augmented by a lightweight CPU-side proxy for features that don't fit the hardware. 4.4x HTTP throughput over existing gateways; 2.3x cost-effectiveness and 2.8x power-efficiency versus software-only or hardware-only designs.
• How: Split the gateway data path — SmartNIC handles per-packet analysis and forwarding; the CPU proxy retains flexible traffic-management features — so neither the fully-software nor fully-hardware extreme is forced.
• Where applicable: Any Istio/Envoy-style service mesh with hardware offload available; research prototype (testbed evaluation, not production), so treat numbers as best-case. The hybrid split principle is the transferable part.

DDoS Detection at the Scale of One Hundred Tbps#

Abstract Paper Recording

Yunming Xiao (CUHK Shenzhen and Tencent), Xijun Luo, et al. (Tencent), Heng Yu, Jiahao Cao (Tsinghua), Yan Chen (Northwestern), Congcong Miao (Tencent)

• Why: Existing programmable-device DDoS detectors top out around Tbps per box; cloud incumbents see ~100 Tbps aggregate. This is the production answer to two orders of magnitude more traffic — with the scaling lessons made explicit.
• What: "Canopy," a DDoS detection system deployed in Tencent production that scales past 100 Tbps via distributed detection across many servers — dynamic load balancing that adapts to mice/elephant mixes, plus traffic compression at the programmable switch to shrink per-server workload.
• How: Instead of naive flow-level load balancing across detection servers (which skews badly), Canopy dynamically rebalances under fluctuating traffic patterns, and pre-aggregates/compresses traffic in the switch offload stage before it reaches the servers.
• Where applicable: Tencent-specific production deployment, but the architecture (switch-side compression + adaptive distribution over a detection-server fleet) generalizes to any large scrubbing/detection pipeline. Real-world attack mitigation in production validates it.

In Link We Trust: BFT at the Speed of CFT using Switches#

Abstract Paper Slides Recording

Lior Zeno, Naama Ben-David, Mark Silberstein (Technion)

• Why: Byzantine fault tolerance has always cost a large multiple of CFT performance; this paper erases that penalty using properties of the modern DC network itself. A genuinely novel trust model — trusting the network fabric, not cryptography — that reframes what "trusted network" means in a DC.
• What: SwitchBFT, a datacenter BFT consensus protocol matching the performance and fault tolerance of the fastest CFT protocols — attaining the speed of NOPaxos (an in-switch CFT) while tolerating Byzantine replicas.
• How: Exploits packet source authentication to eliminate cryptographic-signature overhead in the fault-free path, and switch programmability to enforce agreement decisions and verify safety, all within tight switch resource budgets. Handles packet loss and switch-crash faults as design cases.
• Where applicable: Data centers with programmable (Tofino-class) switches and source-authenticated links — the "trusted network" assumption is the constraint. For the identity-minded: this is an alternative to per-message cryptographic attestation, complementing rather than competing with workload-identity approaches like SPIFFE for different threat models.

Adjacent#

CrossCheck: Input Validation for WAN Control Systems#

Abstract Paper Slides Recording

Alexander Krentsel (UC Berkeley and Google), Rishabh Iyer (UC Berkeley), Isaac Keslassy (Technion and UC Berkeley), Bharath Modhipalli (Google), Sylvia Ratnasamy (UC Berkeley and Google), Anees Shaikh, Rob Shakir (Google)

• Why: WAN outages increasingly trace to bad inputs to the SDN controller (telemetry bugs, corrupted state) rather than bad control logic. CrossCheck guards that interface — a class of failure most validation work ignores.
• What: A shadow validation system for SDN-WAN controller inputs. Four weeks in a production WAN: it caught the single invalid-input incident that occurred with 0% false positives; simulation shows detection of demand perturbations as small as 5% at 100% accuracy, and zero false positives with up to 30% corrupted telemetry.
• How: Cross-validates controller inputs (demands, topology, telemetry) against consistency constraints before they drive TE decisions, alerting operators pre-outage rather than post-mortem.
• Where applicable: Google-scale WAN operator deployment; the pre-deployment shadow-mode evaluation pattern is what makes the 0%-FP claim credible. Concept transfers to any SDN-controlled WAN (or even large DCN controller) with telemetry-driven inputs.

Defending against Traffic Analysis Attacks with Flexible In-Network Obfuscation#

Abstract Paper Slides Recording

Guorui Xie, Qing Li (Pengcheng Laboratory), Zhenning Shi (Tsinghua Shenzhen), Gianni Antichi (Politecnico di Milano), et al.

• Why: Encrypted-traffic side channels (packet sizes, timing) keep working through TLS 1.3 and QUIC; existing defenses trade too much bandwidth or need unrealistic coordination. This makes in-network defense cheap enough to consider.
• What: "Securitas," an obfuscation framework that cuts traffic-analysis attack accuracy by up to 95.89% while consuming 42.69x less bandwidth than prior defenses; real-Internet tests show ~0.15s added web page load.
• How: A learning-guided mix of packet fragmentation and insertion, chosen adaptively rather than via fixed padding rules; implemented across four data planes — Tofino switch, FPGA, eBPF, and BMv2 — which is unusual deployability evidence.
• Where applicable: Any operator that can insert obfuscation on-path (switch, NIC, or eBPF host). The multi-dataplane implementation means the defense isn't tied to one vendor's silicon; evaluation includes real-world Internet paths, not just lab topologies.

Iris: Expressive Traffic Analysis for the Modern Internet#

Abstract Paper Slides Recording

Thea Rossman, Diana Qing, Gerry Wan, Zakir Durumeric (Stanford University)

• Why: Security/ops teams keep bolting one-off sniffers and Zeek scripts onto high-speed links; Iris asks what a framework for high-performance traffic analysis should look like and delivers one that composes hundreds of tasks on one box.
• What: A compiler-based framework that turns user-defined filters, stream transformations, and computations written in Rust into an optimized pipeline — executing hundreds of concurrent analysis tasks at 100 Gbps+ on a single commodity server.
• How: The compiler eliminates redundant logic across concurrent analysis tasks to produce one unified runtime minimizing aggregate work; users get connection- and application-layer semantics exposed as Rust types rather than a constrained DSL.
• Where applicable: General monitoring/security-analysis infrastructure, not tied to specific hardware. Artifact evaluated (available/functional/reproduced), so teams could realistically pilot it against existing Zeek/Graylog-style pipelines.

A Composable Emulation Framework for Whitebox Switches#

Abstract Paper Slides Recording

Congcong Miao (Tencent), Xianneng Zou (Tencent and Tsinghua Shenzhen), Chuwen Zhang (Tsinghua), et al., with Ang Chen (University of Michigan)

• Why: As switches disaggregate into vendor-mixed modules (data plane, control plane, optics), monolithic firmware emulators stop matching reality — and config errors slip through to production. This is the first emulation framework built for that composed world.
• What: "MirSwitch," a composable whitebox-switch emulation framework deployed in Tencent's production network; operators used it to troubleshoot 97.5% of 203 issues in a recent year, with 2.2x better forwarding-emulation performance.
• How: An adaptor-centric design that stitches together diverse emulator modules for data plane, control plane, and peripherals (including optical components), reconciling differing interface contracts across modules so mixed-vendor compositions can be emulated faithfully before deployment.
• Where applicable: Operators building disaggregated/whitebox switches from multiple vendors; the 97.5%-of-issues production statistic is unusually strong validation for an emulation paper.

Wildcard#

From Bits to Tokens: Knowledge-Driven Generative Communication of Multimodal Data#

Abstract Paper Recording

Xingyu Chen (UC San Diego), Zihao Feng (USC), Wuqiong Zhao (UCSD), Jianrong Ding (CUHK), Ke Sun (Michigan), Xinyu Zhang (UCSD)

• Why: Not your domain — and that's the point. This is the most complete systems argument yet that "the network should transmit task-relevant knowledge, not bits," backed by a working prototype rather than a position paper. It signals where edge/IoT/real-time communication research is going as foundation models meet the network stack.
• What: Knowledge-Driven Communication (KDC): a framework transmitting semantic tokens rather than raw bitstreams. A full prototype achieves high downstream task accuracy with a fraction of the transmitted data and degrades gracefully under wireless loss, beating state-of-the-art codecs and learned baselines.
• How: A task-aware transmitter uses multimodal foundation models to abstract source data into tokenized embeddings and prioritize semantically critical content (zero-shot, no task-specific retraining); the receiver reconstructs task-relevant information from pretrained knowledge bases plus incrementally updated context.
• Where applicable: Wireless, lossy, bandwidth-constrained multimodal settings today (sensors, video analytics at the edge). Long-horizon relevance rather than near-term deployability for DC networking — but the tokens-not-bits framing will increasingly show up in adaptive video and agentic-traffic contexts.

SPLIDT: Partitioned Decision Trees for Scalable Stateful Inference at Line Rate#

Abstract Paper Recording

Murayyiam Parvez (Purdue), Annus Zulfiqar (Michigan), Roman Beltiukov (UCSB), Shir Landau Feibish (University of Haifa), Walter Willinger (Northwestern), Arpit Gupta (UCSB), Muhammad Shahbaz (Michigan)

• Why: In-network ML keeps stalling on the same wall — hardware limits force tiny fixed feature sets per flow. SPLIDT's partitioning trick is a real mechanism (not an ML benchmark bump) for getting past that wall, and it generalizes to any stateful line-rate inference problem on switches and SmartNICs.
• What: A system for deploying decision trees in the data plane that supports up to 5x more stateful features than prior approaches (NetBeacon, Leo) at the same low time-to-detection, scaling to millions of flows with ≤0.05% recirculation overhead.
• How: Two ideas: group DT subtrees into partitions where each subtree gets its own feature set (instead of computing all features upfront for the whole tree), and use in-band recirculation as a control channel to reuse register/match-key resources across partitions at line rate. A training + design-space-exploration framework jointly optimizes feature allocation, partitioning, and depth.
• Where applicable: Programmable switches and SmartNICs doing traffic classification, security monitoring, or in-network decisions. Artifact evaluated (available/functional/reproduced), so the partitioning approach is reproducible, not vendor-locked.

Eywa: Automating Model-Based Testing using LLMs#

Abstract Paper Slides Recording

Rajdeep Mondal, Rathin Singha, Todd Millstein, George Varghese (UCLA), Ryan Beckett, Siva Kesava Reddy Kakarla (Microsoft Research)

• Why: Model-based testing finds real protocol bugs but has always been gated on humans hand-writing RFC-conformant models — months of expert effort. Eywa removes that gate and immediately found 16 previously-undiscovered bugs in DNS/BGP/SMTP implementations. This is the clearest signal yet of LLMs changing core network-engineering practice (spec → model → tests), with results that survived review.
• What: A protocol-testing framework that uses LLMs to automatically build models of intended protocol behavior from RFCs, blogs, and natural-language sources; case studies across DNS, BGP, and SMTP found 33 unique bugs, 16 novel despite extensive prior manual testing.
• How: LLM-synthesized models are combined with mitigation for hallucinations and the inability to monolithically generate complex models (decomposition, validation against spec behavior), then fed into standard model-based test generation to drive high-coverage conformance testing of real implementations.
• Where applicable: Protocol conformance testing broadly — DNS, BGP, and SMTP demonstrated; the approach is protocol-agnostic in principle where written specs exist. Artifact evaluated (available/functional/reproduced). If you own protocol conformance or interop testing, this is the paper to read this cycle.

Themes#

• AI-era fabric design is the gravitational center: Matryoshka's 100K-GPU superclusters, Express Backbone's AI-driven TE evolution, BURST's LLM-inference-driven RDMA interop, and the many GPU-cluster training papers (FLARE, EROICA, Arcadia, Checkmate) all reflect the network being redesigned around AI traffic — congestion control, topology, and even DCN tooling are being re-derived from AI workload assumptions.
• Chinese hyperscalers dominate operational-systems content: Alibaba (Bifrost, ZooRoute, CStar Gateway), Tencent (Canopy, MirSwitch, MirrorNet, Harp), ByteDance (BURST, Net-P4ct, Skyline), and Microsoft/Meta deliver production-validated systems with hard numbers (93% outage reduction, 26-month deployments, 100 Tbps) — unusually strong empirical grounding for NSDI, and a useful reality-check on academic claims.
• Delay signals are displacing INT in congestion control: Both OSCAR (outstanding paper) and CCC demonstrate that delay/delay-gradient can achieve precision comparable to INT-based schemes without special hardware support — a collective shift from "richer telemetry" to "deployability first" in DC transport.
• The DPU is collapsing into the switch: SONiC DASH SmartSwitch (NPU+DPU in one T1 box), Bifrost's SmartNIC-based VPC transport, and HybridMesh's SmartNIC ingress all push offload toward (or into) top-of-rack silicon — the "uni-box" consolidation is an architectural trend, not a one-off.
• Optical and reconfigurable DCNs got their tooling layer: OpenOptics (open framework, 2µs circuits), SyncWise (sub-10ns sync), and the NYSERNet field deployment suggest the OCS-based fabric subfield is maturing from bespoke demos toward a researchable, instrumentable ecosystem.
• LLMs entered the network-engineering loop — with evidence: Eywa's RFC-to-model synthesis finding novel bugs, alongside MoCE and the generative-traffic work, marks the shift from "ML for networking" (inference at line rate, e.g., SPLIDT) to "LLMs doing the engineering itself" (models, tests, diagnosis). Expect this thread to expand sharply next cycle.