Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Closing the HPC-Cloud Convergence Gap: Multi-Tenant Slingshot RDMA for Kubernetes

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read This paper extends HPE Slingshot's RDMA stack so Kubernetes containers get secure, per-tenant network isolation at under 1% communication overhead and roughly 1.6–3.5% job admission overhead.

desk verdict A well-built engineering contribution to multi-tenant Slingshot RDMA in Kubernetes, but the paper's 'secure' claim rests on an untested netns-inode identity assumption. read the letter →

arxiv 2508.09663 v1 pith:W5PIBWYX submitted 2025-08-13 cs.DC cs.NI

Philipp A. Friese , Ahmed Eleliemy , Utz-Uwe Haus , Martin Schulz This is my paper · ORCID
classification cs.DCcs.NI
keywords HPESlingshotRDMAKubernetesmulti-tenantnetworkingnetworknamespacesCNIpluginconvergedHPC-Cloudvirtualisolation
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

Converged HPC-Cloud systems want both cloud-style tenant isolation and HPC-grade communication speed, and HPE Slingshot — the 200 Gbps RDMA interconnect used in leading supercomputers — was built for only one of those: its access control authenticates users by Linux UID/GID, an identity that means nothing in Kubernetes, where every container runs under a single cluster-wide user. The paper claims to close this gap with a three-layer extension to the Slingshot stack: a driver and library change that authenticates RDMA endpoint creation by network namespace instead of user ID, a CNI plugin that creates and destroys per-container access services, and a VNI Service that manages Slingshot Virtual Networks as Kubernetes custom resources. On an evaluation cluster, the integration shows under 1% overhead in RDMA throughput and latency and 1.6–3.5% overhead in job admission time. If these numbers hold, converged clusters can co-locate mutually isolated tenants on a shared high-speed fabric without sacrificing RDMA performance.

What carries the argument

The load-bearing mechanism is the netns CXI service member type: a third membership class in the Slingshot access model that identifies authorized users by their network namespace inode, read from procfs, instead of by Linux UID/GID. Kubernetes runs every container under one UID, so only a per-container kernel identity such as the network namespace can serve as a tenant principal; the netns check happens once, at RDMA endpoint creation, and preserves kernel-bypass afterwards. Two further components carry that identity through the cluster: the CXI CNI plugin, which creates and deletes per-container CXI services, and the VNI Service, whose controller and database expose Virtual Network IDs as

What would settle it

Give a pod CAP_SYS_ADMIN and let it enter the network namespace of a neighbor pod, then attempt a Slingshot RDMA endpoint creation: if the CXI service for the neighbor's namespace admits it, the netns authentication is bypassable. A second test: delete a Slingshot-enabled pod, wait for its namespace inode to be recycled, create a new pod, and check whether its RDMA endpoint unexpectedly inherits the deleted pod's VNI and can see its traffic.

Watch

Extended reading notes

Core claim

On the paper's own terms, the core claim is that container-granular RDMA isolation can be layered onto Slingshot by changing the identity that grants access. A new netns member type in the CXI driver stores a container's network namespace inode; at endpoint creation the extended driver reads the caller's namespace ID from procfs and admits the endpoint only on a match. A CNI plugin creates one CXI service per container on ADD and removes it on DEL, and a VNI Service allocates Virtual Network IDs through a database-backed Kubernetes controller with two ownership models: one VNI per job, or one shared VNI per claim. The evaluation puts the cost at under 1% in throughput and latency and 1.6–3.5

Load-bearing premise

The entire isolation guarantee rests on the claim that a container cannot alter or forge its network namespace identifier; if a container could join or create another namespace, the CXI service check would admit the wrong tenant.

Editorial extensions

If this is right

  • A single Kubernetes annotation (vni: true or vni: <claim-name>) is enough for a job to request its own isolated Slingshot network; no privileged per-user onboarding is needed.
  • Pods inside one job — or several jobs redeeming the same VNI Claim — can communicate over Slingshot, while pods of unrelated jobs cannot, because each job's pods are admitted only to their own VNI.
  • HPC workloads running in containers keep host-level RDMA throughput and latency (overhead within run-to-run jitter, under 1%), so the isolation layer does not force a slowdown.
  • Job admission overhead stays near 3.5% for ramp-shaped load and 1.6% for 500-job spikes, with most admission delay attributed to Kubernetes itself rather than the new stack.
  • The VNI Service's atomic database transactions make concurrent VNI allocation race-free, so two jobs cannot be handed the same VNI even under admission bursts.

Reading between the lines

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

  • Editorial extension: the netns-isolation guarantee presumes a container cannot change its namespace identity; a pod granted CAP_SYS_ADMIN can create or enter namespaces, which would let it authenticate as another tenant — a case the paper states but does not test.
  • Editorial extension: network-namespace inodes are recycled by the kernel after deletion, so a new container could inherit the inode — and with it any stale CXI service and VNI — of a departed tenant if the CNI plugin's DEL path fails or the 30-second VNI-release window is violated.
  • Editorial extension: the netns-as-principal pattern is not Slingshot-specific; the same driver-level trick could give InfiniBand or other UID-authenticated RDMA stacks a Kubernetes tenant model, though the paper demonstrates it only for Slingshot.
  • Editorial extension: the 30-second grace period before VNI reuse, paired with the enforced termination grace period, is what keeps straggling pods from leaking into a new tenant's VNI; node failure or a hung pod past the grace window would be the stress case that determines whether the guarantee holds in production.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper presents an extension of the HPE Slingshot RDMA software stack for multi-tenant Kubernetes deployments. The contributions are: (A) a new network-namespace (netns) member type for CXI services in the driver/libs, (B) a CNI plugin that creates and destroys CXI services for containers, and (C) a Kubernetes VNI Service that manages VNI allocation and lifetime via CRDs and a database. The evaluation reports RDMA communication overhead within 1% and job admission overhead of 3.5% (ramp) and 1.6% (spike) compared to a non-integrated Kubernetes baseline. The abstract claims the integration provides 'secure, container-granular, and multi-tenant access to Slingshot RDMA networking capabilities at minimal overhead.'

Significance. If the security claim were substantiated, this would be a valuable step toward converged HPC-cloud systems, since it addresses a real gap in the Slingshot access model. The performance evaluation is a clear strength: it uses standard OSU benchmarks, multiple runs, percentile intervals, and a plausible job-admission workload; the open-source release of code and measurement data further supports reproducibility. However, the central security assertion is not evaluated at all, and the design rests on an identity-binding assumption that is not established and is, in fact, questionable. The work is therefore only partially supported: the performance contribution is credible, but the security contribution needs substantial additional work before the stated central claim can be accepted.

major comments (3)
  1. [Section III.A] The security of the netns-based CXI service authentication is load-bearing. The paper states that 'malicious users inside a container cannot modify their network namespace ID.' This conflates the immutability of an inode number with the ability of a process to change its network namespace. A container with CAP_SYS_ADMIN can call unshare(CLONE_NEWNET) or setns() and thereby present a different netns at endpoint-creation time. If an attacker can enter another tenant's netns, CXI authentication will succeed under the victim's membership. No threat model is given, and Section IV contains no security experiments. The 'secure, container-granular' claim needs either a restriction to containers without CAP_SYS_ADMIN, a mechanism that binds CXI services to a stronger identity, or an explicit security evaluation demonstrating that namespace switching is not possible in the target environment.
  2. [Section III.B, III.C] The lifecycle of CXI services is not safe under inode reuse or plugin unavailability. The manuscript itself acknowledges in Section III.B that automatic cleanup 'only occur[s] if the CXI CNI plugin is available throughout the lifetime of all Slingshot-enabled containers.' Linux netns inode numbers can be reused after the namespace is destroyed. If a stale CXI service remains keyed to a freed inode, a new container whose netns happens to reuse that inode can inherit the prior tenant's VNI and CXI service. The 30-second VNI release grace period in Section III.C does not address this case because the stale service is not tied to the VNI database record; it is tied only to the inode. This is a concrete isolation-breaking scenario, and it should be either fixed (e.g., by storing a generation counter or pod reference in the CXI service) or explicitly analyzed and tested.
  3. [Section IV] The evaluation measures performance only. Figures 5-12 quantify throughput, latency, and admission delay, but there is no isolation or security evaluation whatsoever. Since the abstract's central claim is security, the absence of any adversarial test for namespace isolation, CXI service identity spoofing, or inode reuse is a major omission. Please add at least a threat model and a small set of experiments that attempt cross-tenant endpoint creation, namespace joining, and stale-service inheritance. Without such evidence, the paper's title and abstract overstate what is demonstrated.
minor comments (5)
  1. [Section IV.A] Figure 8 caption says '25 iterations' while the text says the OSU benchmarks were run 10 times. Please align these numbers.
  2. [Figure 9] The caption says 'green line shows the number of jobs launched per job'; this should read 'per batch.'
  3. [References] Reference [3] appears to contain a typo ('vDirect Direct Data Placement...'), and the formatting of 'V olcano' in Section IV.A should be fixed.
  4. [Section III.A] The description of retrieving the netns ID 'using procfs' is imprecise for a kernel driver; the driver should read the process's nsproxy directly. Clarify the mechanism.
  5. [Section III.C.1] The assumption that 'users are not allowed to create or modify VNI CRD instances directly' is an administrative security assumption. It should be stated explicitly as part of the threat model, since it is essential to the exclusivity of VNI allocation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: performance claims are externally benchmarked and no fitted input is repackaged as a prediction.

full rationale

The paper is a systems contribution with no mathematical derivation whose conclusion is equivalent to an input. The central claims are (1) a netns-based CXI member type, (2) a CNI plugin and VNI service, and (3) minimal overhead. Overhead is measured with OSU Micro-Benchmarks against a host baseline and a Kubernetes baseline without the integration; the reported <1% communication overhead and 3.5%/1.6% admission overhead are direct measurements, not fitted parameters called predictions. The only self-citation, OpenCUBE [16], identifies the pilot testbed and is not load-bearing for the design or security argument. The security reasoning does reduce tenant identity to the network-namespace inode, but that is an implementation definition rather than a circular derivation: the CXI driver is extended to compare the requesting process's netns inode to the member list. The statement that malicious users inside a container cannot modify their network namespace ID is an unverified assumption (e.g., CAP_SYS_ADMIN scenarios or inode reuse are not addressed), and the DEL cleanup caveat in Section III.B is a genuine limitation, but these are correctness/security risks, not circularity. No equation or construction forces the reported results to equal the inputs.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The design rests on several domain assumptions: netns inode as a stable identifier, correctness of procfs lookup, Kubernetes RBAC limitations, and hardware VNI enforcement. One hand-chosen constant (30s grace period) is introduced; no data-fitted parameters are used.

free parameters (1)
  • VNI reuse grace period = 30 seconds
    Hand-chosen in Section III.C to ensure pod termination grace periods do not exceed 30s, preventing VNI reuse before all pods are gone. Impact on admission overhead is measured but the value is not tuned to data.
assumptions (5)
  • domain assumption Network namespace inode is a stable, unforgeable identifier for a container's network isolation domain.
    Invoked in Section III.A to authenticate CXI service members; the paper argues malicious users cannot modify their netns ID, but does not analyze inode reuse or CAP_SYS_ADMIN namespace switching.
  • domain assumption CXI driver's netns lookup via procfs is correct and race-free.
    Section III.A: the driver extracts the netns ID from the requesting process via procfs; no race conditions or TOCTOU issues are discussed.
  • domain assumption Kubernetes users cannot create or modify VNI CRD instances, so only the VNI Controller manages VNI assignments.
    Section III.C: the authors assume users are only allowed to operate on their namespaces and not on VNI CRDs; this is an administrative assumption, not a technical guarantee.
  • domain assumption CXI hardware and Rosetta switches enforce VNI isolation at the switch level.
    Background Section II.B/C describes VNI enforcement as a hardware feature; the paper relies on this for isolation rather than demonstrating it.
  • standard math SQLite ACID transactions prevent VNI allocation races.
    Section III.C.2: all relevant database operations are atomic transactions, assumed to provide correct coordination.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Closing the HPC-Cloud Convergence Gap: Multi-Tenant Slingshot RDMA for Kubernetes." pith.science (2026). https://pith.science/paper/W5PIBWYX

@misc{pith2026250809663,
  author       = {Pith},
  title        = {Pith review of: Closing the HPC-Cloud Convergence Gap: Multi-Tenant Slingshot RDMA for Kubernetes},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W5PIBWYX}},
  note         = {Machine review of arXiv:2508.09663}
}
read the original abstract

Converged HPC-Cloud computing is an emerging computing paradigm that aims to support increasingly complex and multi-tenant scientific workflows. These systems require reconciliation of the isolation requirements of native cloud workloads and the performance demands of HPC applications. In this context, networking hardware is a critical boundary component: it is the conduit for high-throughput, low-latency communication and enables isolation across tenants. HPE Slingshot is a high-speed network interconnect that provides up to 200 Gbps of throughput per port and targets high-performance computing (HPC) systems. The Slingshot host software, including hardware drivers and network middleware libraries, is designed to meet HPC deployments, which predominantly use single-tenant access modes. Hence, the Slingshot stack is not suited for secure use in multi-tenant deployments, such as converged HPC-Cloud deployments. In this paper, we design and implement an extension to the Slingshot stack targeting converged deployments on the basis of Kubernetes. Our integration provides secure, container-granular, and multi-tenant access to Slingshot RDMA networking capabilities at minimal overhead.

Figures

Figures reproduced from arXiv: 2508.09663 by the authors.

Figure 1
Figure 1. Slingshot Access Model — Virtual Networks (VNIs) [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Design of our Slingshot Software Stack — Red [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. VNI Service, comprises VNI Endpoint and VNI Con [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: Average Throughput via osu_bw — Baseline run-to￾run network jitter measured directly on the host in green. 10 iterations measuring 10k iterations of the respective MPI call. 1 B 2 B 4 B 8 B 16 B 32 B 64 B 128 B 256 B 512 B 1 kB 2 kB 4 kB 8 kB 16 kB 32 kB 64 kB 128 kB 2…
Figure 6
Figure 6. Figure 6: Average Throughput Overhead via osu_bw — Shaded regions indicate 10 % and 90 % percentile, baseline run-to￾run network jitter measured directly on the host in green. 10 iterations measuring 20k iterations of the respective MPI call. and 20 000 iterations for latency me…
Figure 7
Figure 7. Figure 7: Average Latency via osu_latency — Baseline run￾to-run network jitter measured directly on the host in green. 10 iterations measuring 20k iterations of the respective MPI call. 1 B 2 B 4 B 8 B 16 B 32 B 64 B 128 B 256 B 512 B 1 kB 2 kB 4 kB 8 kB 16 kB 32 kB 64 kB 128 kB…
Figure 8
Figure 8. Figure 8: Average Latency overhead via osu_latency — Shaded regions indicate 10 % and 90 % percentile, baseline run-to-run network jitter measured directly on the host in green. 25 iterations measuring 20k iterations of the respective MPI call. B. Job Admission Overhead We use t…
Figure 11
Figure 11. Figure 11: Number of actively Running Jobs during Spike Test [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 12
Figure 12. Figure 12: Admission Delay for Ramp and Spike Test — [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Multi-tenant Kubernetes Use Cases for AI, Secure Computing and Data Services, and More

    cs.DC 2026-08 conditional novelty 4.0 of 10

    Kubernetes with per-VNI Slingshot isolation is demonstrated on ARM64 Isambard-AI for a Trusted Research Environment and multi-node LLM serving, with ~0.9 us latency overhead.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages · cited by 1 Pith paper

  1. [1]

    HPE expands direct liquid-cooled supercomputing solutions, introduces two AI systems for service providers and large enterprises

    HPE, “HPE expands direct liquid-cooled supercomputing solutions, introduces two AI systems for service providers and large enterprises.” [Online]. Available: https://www.hpe.com/us/en/newsroom/press-relea se/2024/11/hpe-expands-direct-liquid-cooled-supercomputing-solutions -introduces-two-ai-systems-for-service-providers-and-large-enterprises .html

    work page 2024

  2. [2]

    Kubernetes

    The Kubernetes Authors, “Kubernetes.” [Online]. Available: https: //kubernetes.io/ [3]vDirect Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security

    work page

  3. [4]

    Enabling HPC workloads on cloud infrastructure using Kubernetes container orchestration mechanisms,

    A. M. Beltre, P. Saha, M. Govindaraju, A. Younge, and R. E. Grant, “Enabling HPC workloads on cloud infrastructure using Kubernetes container orchestration mechanisms,” in2019 IEEE/ACM International Workshop on Containers and New Orchestration Paradigms for Isolated Environments in HPC (CANOPIE-HPC). IEEE, 2019, p. 11–20

    work page 2019

  4. [5]

    Containers in HPC: a survey,

    R. Keller Tesser and E. Borin, “Containers in HPC: a survey,”The Journal of Supercomputing, vol. 79, no. 5, p. 5759–5827, 2023

    work page 2023

  5. [6]

    Container Network Interface Specification,

    CNI Authors, “Container Network Interface Specification,” 2021. [Online]. Available: https://www.cni.dev/docs/spec/

    work page 2021

  6. [7]

    Available: https://www.man7.org/linux/man-pages/man7/user namespaces.7.html

    [Online]. Available: https://www.man7.org/linux/man-pages/man7/user namespaces.7.html

    work page

  7. [8]

    The /proc Filesystem — The Linux Kernel documentation

    “The /proc Filesystem — The Linux Kernel documentation.” [Online]. Available: https://www.kernel.org/doc/html/latest/filesystems/proc.html

    work page

  8. [9]

    Libfabric

    OpenFabrics Interface Working Group, “Libfabric.” [Online]. Available: https://ofiwg.github.io/libfabric/

    work page

Show all 24 references
  1. [10]

    Mar. 2025. [Online]. Available: https://github.com/flannel-io/flannel

    2025

  2. [11]

    [Online]

    The Cilium Authors. [Online]. Available: https://cilium.io

  3. [12]

    [Online]

    The Kubernetes Authors. [Online]. Available: https://kubernetes.io/docs /concepts/extend-kubernetes/api-extension/custom-resources/

  4. [13]

    [Online]

    The Metacontroller Authors. [Online]. Available: https://metacontroller .github.io/metacontroller/

  5. [14]

    R. D. Hipp, “SQLite,” 2020. [Online]. Available: https://www.sqlite.o rg/index.html

    2020

  6. [15]

    K3s - Lightweight Kubernetes

    “K3s - Lightweight Kubernetes.” [Online]. Available: https://k3s.io

  7. [16]

    Opencube: Building an open source cloud blueprint with epi systems,

    I. Peng, M. Schulz, U.-U. Haus, C. Prunty, P. Marcuello, E. Danovaro, G. Schieffer, J. Wahlgren, D. Medeiros, and P. Friese, “Opencube: Building an open source cloud blueprint with epi systems,”Euro-Par 2023 Workshops and Minisymposia, 2023

    2023

  8. [17]

    OSU Micro-Benchmarks

    “OSU Micro-Benchmarks.” [Online]. Available: https://mvapich.cse.oh io-state.edu/benchmarks/

  9. [18]

    V olcano - Cloud native batch scheduling system for compute-intensive workloads

    V olcano Project Authors, “V olcano - Cloud native batch scheduling system for compute-intensive workloads.” [Online]. Available: https: //volcano.sh/en/

  10. [19]

    Harbor - An open source trusted cloud native registry project that stores, signs, and scans content

    Harbor Authors, “Harbor - An open source trusted cloud native registry project that stores, signs, and scans content. .” [Online]. Available: https://goharbor.io/

  11. [20]

    Bedrock: Programmable Network Support for Secure RDMA Systems,

    J. Xing, K.-F. Hsu, Y . Qiu, Z. Yang, H. Liu, and A. Chen, “Bedrock: Programmable Network Support for Secure RDMA Systems,” 2022, p. 2585–2600. [Online]. Available: https://www.usenix.org/conference/us enixsecurity22/presentation/xing

    2022

  12. [21]

    sRDMA - Efficient NIC-based Authentication and Encryption for Remote Di- rect Memory Access,

    K. Taranov, B. Rothenberger, A. Perrig, and T. Hoefler, “sRDMA - Efficient NIC-based Authentication and Encryption for Remote Di- rect Memory Access,” in2020 USENIX Annual Technical Conference (USENIX ATC 20), 2020, p. 691–704

    2020

  13. [22]

    k8s-rdma-shared-dev-plugin

    Mellanox Technologies Ltd., “k8s-rdma-shared-dev-plugin.” [Online]. Available: https://github.com/Mellanox/k8s-rdma-shared-dev-plugin/tr ee/master

  14. [23]

    InfiniBand SR-IOV CNI plugin,

    “InfiniBand SR-IOV CNI plugin,” Feb. 2025. [Online]. Available: https://github.com/k8snetworkplumbingwg/ib-sriov-cni

    2025

  15. [24]

    NVIDIA Network Operator,

    NVIDIA, “NVIDIA Network Operator,” Apr. 2025. [Online]. Available: https://github.com/Mellanox/network-operator

    2025

  16. [25]

    CXI Kubernetes device plugin,

    Hewlett Packard Enterprise Development LP, “CXI Kubernetes device plugin,” Mar. 2025. [Online]. Available: https://github.com/HewlettPa ckard/cxi-k8s-device-plugin

    2025

Pith tools

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