Data-Plane Shim for Optimized Data Transfer

• Data-plane shim is a lightweight host-level module that intercepts and optimizes data transfers by dynamically selecting suitable mechanisms like in-memory links or IPC.
• It bridges default I/O and inter-sandbox communication in serverless and storage systems, reducing latency and resource use through policy-driven decisions.
• Empirical studies show data-plane shims can cut latency by up to 95% and boost throughput by up to 30×, underscoring their importance in edge-cloud architectures.

A data-plane shim is a lightweight, host-level process or userspace module that mediates and optimizes the movement of data along the critical path between application- or function-level sandboxes and the underlying communication or storage substrate. In contemporary serverless and storage systems, the data-plane shim replaces or interposes on default I/O and inter-sandbox communication mechanisms, providing policy-driven, dynamic selection of transfer mechanisms—such as in-memory links, local IPC, or networked buffers—and encapsulating performance optimization, resource management, and protocol bridging in a portable, application-transparent manner. Data-plane shims are distinct from control-plane components: while control planes orchestrate placement and lifecycle, shims execute in the hot path, directly transforming and relaying function inputs and outputs (Marcelino et al., 30 Apr 2025, Purandare et al., 1 Jan 2025).

1. Formal Definition and Core Responsibilities

A data-plane shim is formally defined as a small, per-function or per-application host-level process that (1) mediates all data exchange and I/O requests leaving a sandboxed execution context, (2) dynamically applies locality- and policy-driven selection functions to determine the fastest or most suitable transfer mechanism, and (3) shuttles payloads via shared memory, local IPC (e.g., Unix-domain sockets), or remote networked stashes as appropriate (Marcelino et al., 30 Apr 2025). For storage, a shim may override system file or device I/O, passing operations through modular placement logic and direct device coordination without kernel or application modification (Purandare et al., 1 Jan 2025).

Fundamental data-plane shim functions include:

• Intercepting system or network calls (e.g., WASI, POSIX) at runtime.
• Serializing and deserializing payloads, memory copying with minimal overhead.
• Bridging standard APIs to optimized backends or dynamic communication modes.
• Enabling context-aware optimization (e.g., direct call if functions co-reside in a trusted namespace).

2. Data-Plane Shims in Serverless and Edge-Cloud Systems

Data-plane shims are particularly prevalent in modern serverless-at-the-edge and hybrid edge–cloud deployments, where they address the high latency and resource waste inherent in default remote storage or external messaging layers. A representative example is the CWASI shim, deployed within the Open Container Initiative (OCI) WebAssembly stack (Marcelino et al., 30 Apr 2025):

1. Containerd (or a similar CRI) launches per-function OCI bundles, invoking the CWASI shim rather than a native process.
2. The shim implements the OCI Shim API, configures the WebAssembly runtime (e.g., WasmEdge) in a hardened deny-by-default mode, and registers host functions for intercepting WASI/system I/O.
3. Data exchange attempts (e.g., function invocations, remote storage access) are trapped and handled by the shim, which selects among in-VM linking, kernel-local IPC, or networked buffers, according to real-time policy and placement.

This approach reifies the “data-plane” abstraction: a dedicated runtime tier, separate from coordination logic, that delivers direct optimization of the data-flow path for serverless compositions.

3. Multi-Mode Communication and Decision Logic

CWASI exemplifies the three-mode communication model for function-to-function data transfer, with mode decisions driven by locality, trust, and measured or modeled latencies (Marcelino et al., 30 Apr 2025):

• Function Embedding (F): Trusted, co-namespace functions are statically linked and co-resident in a single Wasm VM. The resulting inter-call latency is $L_F \approx \varepsilon \ll 1$ ms.
• Local Buffer (L): Co-located but isolated functions communicate via ephemeral Unix-domain sockets or shared memory, incurring latency $L_L = t_\text{uds} + t_\text{copy}$ in the 10–100 μs range.
• Networked Buffer (N): Cross-host or untrusted communication falls back to network channels (TCP, Redis pub/sub), with $L_N = t_\text{net\_rtt} + t_\text{ser/deser}$.

Selection is formalized by: $\delta = \frac{L_{N}}{L_{L}}$ and embedding predicates over namespace and trust. The minimal-latency mode is chosen: $$m = \begin{cases} F, & \text{if } \mathtt{trusted\_namespace}(f_\text{src}, f_\text{dst}) \ L, & \text{else if } \mathtt{co\_located}(f_\text{src}, f_\text{dst}) \land \delta > 1 \ N, & \text{otherwise} \end{cases}$$ Throughput follows $T_F \gg T_L \gg T_N$.

The operational logic is captured in the following pseudocode:

def invoke_next(src, dst, payload): if in_same_trusted_ns(src, dst): return direct_call(dst, payload) elif co_located(src, dst): delta = measure_LN_over_LL(src, dst) if delta > 1: return send_via_uds(socket_path(src, dst), payload) else: return send_via_network(dst, payload) else: return send_via_network(dst, payload)

(Marcelino et al., 30 Apr 2025)

4. Data-Plane Shims for Host-Device Storage Coordination

In storage-intensive systems, the data-plane shim constructs an optimized path for file operations, separating placement and management logic from kernel, application, or device internals. Reshim demonstrates this architecture (Purandare et al., 1 Jan 2025):

• I/O Interceptor (LD_PRELOAD-based): A userspace library (libreshim.so) intercepts POSIX I/O via LD_PRELOAD, requiring no kernel or application changes. It maintains file ↔ UUID and UUID ↔ fd mappings and supports both hint-based and host-managed inversion.
• Placement Engine: Determines per-operation “hint” tuples (stream $s$, lifetime-group $\ell$) via hand-tuned mapping or workload-driven mini-batch $k$-means clustering.
• Resolver: Translates hints into device-level abstractions (multi-stream hints, ZNS zone IDs).
• Device Manager: For host-managed SSDs, coordinates writable zones, extent allocation, and lazy garbage collection.

The I/O path consists of dynamic interception, hint computation $(s, \ell)$, resolve to device ID, and buffered write or zone allocation. Algorithms factor for both data affinity (mapping I/O streams to device resources) and lifetime grouping (grouping blocks by temporal proximity for more efficient GC).

5. Quantitative Performance and Overhead

Empirical evaluation substantiates the data-plane shim's impact on both communication-intensive and storage-intensive workloads.

Serverless Edge-Cloud (CWASI) (Marcelino et al., 30 Apr 2025)

Workflow	Latency (CWASI)	Latency (OF)	Latency (WE)	Throughput (CWASI)	Throughput (OF)	Throughput (WE)
Sequential (100MB)	0.14 s	0.37 s	4.43 s	6.96	2.76	0.17
Fan-out (100, 2MB)	0.0066 s	0.0169 s	0.195 s	211	61	5
Fan-in (100, 2MB)	0.0032 s	0.0079 s	0.117 s	314	131	8

• Latency reduction up to 95% and throughput improvements up to $30\times$ for co-located serverless functions when switching to in-memory or local buffer modes.
• RAM usage reduced by up to 30% versus WasmEdge; CPU usage comparable to state-of-the-art control-plane orchestrators.

Host-Device Storage (Reshim) (Purandare et al., 1 Jan 2025)

• RocksDB: Write throughput matches zns-tuned ZenFS and is 2–3$\times$ higher than F2FS; latency p99.99 is 20 μs (Reshim) vs. 100 μs (ZenFS).
• MongoDB: Write throughput 3$\times$ and read throughput 6$\times$ higher than F2FS; p50 read latency 31 μs (Reshim) vs. 195 μs (F2FS).
• CacheLib: 8% higher throughput over F2FS; improved tail latencies ($p_{90{-}99}$).
• Device-side write amplification $=1$ for host-managed ZNS with Reshim; zero live-data relocation in long-running update tests.
• Memory footprint: sub-1 MiB user memory (hint-only); $\sim$73 MiB for extended buffering and zone mapping. Reference kernel-based filesystems can use $>$200 MiB in comparable scenarios.

6. Limitations, Trade-offs, and Portability

Several intrinsic limitations and practical trade-offs are observed:

• Runtime Support: CWASI currently supports only the WasmEdge runtime; additional runtime integrations require further engineering (Marcelino et al., 30 Apr 2025).
• Process Overhead: Local Buffer mode uses a per-function UDS server, which can induce higher kernel and context-switch overhead at high densities.
• Isolation vs. Performance: Function Embedding mode reduces isolation, suitable only for trusted namespaces, and is not ideal for strict multi-tenant scenarios.
• Scalability: In distributed or highly elastic serverless deployments, network path costs or launch latency can offset local optimization gains.
• Multi-threading: WASI’s lack of true shared-memory threading necessitates explicit copying for cross-VM transfers.
• Storage Compatibility: Reshim’s logic is applicable to dynamically linked POSIX binaries; statically linked binaries or alternative OSes may not receive interception (Purandare et al., 1 Jan 2025).
• Interface Generality: Both CWASI and Reshim are designed to support flexible plugin approaches for transfer or placement rules, aiding extensibility as substrates evolve.

7. Scientific and Practical Significance

Data-plane shims, as demonstrated by CWASI (Marcelino et al., 30 Apr 2025) and Reshim (Purandare et al., 1 Jan 2025), have become essential abstractions for bridging the semantic gap between legacy APIs, application behaviors, and evolving hardware or deployment models. By encapsulating complexity, enforcing runtime policy, and maximizing context-aware data-path efficiency without requiring kernel or application changes, data-plane shims enable both robust system evolution and near-optimal performance in diverse domains. Their modularity and generality, as highlighted in empirical studies with RocksDB, MongoDB, CacheLib, WasmEdge, and OpenFaas, indicate their criticality in future serverless, edge-cloud, and storage architectures.