{"id":"b1f044f0-6237-430f-b964-889d9e7940a1","arxiv_id":"2504.21503","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A WebAssembly OCI runtime shim that automatically selects among three inter-function communication modes based on function locality, cutting co-located communication latency by up to 95% in the paper's measurements.","lead":"CWASI is a runtime shim that lets co-located serverless functions written in WebAssembly exchange data through local buffers and shared memory instead of always going through remote storage or message queues. The paper reports up to 95% lower communication latency and up to 30x higher throughput in experiments, but the fan-in throughput numbers are derived from fan-out tests rather than measured directly.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 30x throughput claim rests on a fan-in table derived from fan-out experiments (Section 7.5), not on an executed fan-in workload; if concurrent callers contending on one receiver behave differently, the headline claim is unsupported.","rationale":"The reader's weakest assumption identified the same load-bearing concern, and I agree with that assessment. I checked the central claim in the abstract: the 30x throughput figure is the headline quantitative result. The only table row supporting it is the Fan-in row of Table 2, and Section 7.5 explicitly admits that the fan-in workflow was not executed; instead, fan-out experiments were reused and responses were calculated. This limitation is flagged in the manuscript itself and is therefore in-scope evidence. The fan-in values in Table 2 differ from the fan-out source values, which means the derivation is not a trivial relabeling and is not documented. A true fan-in workload would exercise a single receiver with concurrent senders, causing socket-accept contention and a potential throughput bottleneck; the fan-out experiment cannot capture that behavior. The sequential and fan-out results are genuine and support more modest improvements, so the appropriate outcome is conditional acceptance pending a real fan-in measurement, not outright rejection. My recommendation does not change the reader's verdict of CONDITIONAL, so verdict_should_be is UNCHANGED.","tokens_in":20590,"tokens_out":3898,"duration_ms":39777,"concrete_test":"Implement an actual fan-in experiment: start one secondary function with a Local Buffer Receiver, then launch N=10, 50, 100, 200, 400, and 500 concurrent primary function invocations, each sending a 2MB payload over CWASI's Unix socket to the same receiver, and measure per-request latency and aggregate throughput. Compare against the fan-out-derived rows in Table 2 and the fan-out measurements in Fig. 8. If the measured fan-in throughput at N=500 is below the claimed ~314 req/s (or below WasmEdge's fan-in value by less than 30x), the headline throughput claim must be revised or re-benchmarked.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is \"throughput by up to 30x.\" The only result reaching 30x is the Fan-in row of Table 2 (CWASI 314.2019 req/s vs. WasmEdge 8.5336 req/s). Section 7.5 states explicitly: \"we use the fan-out experiments and calculate the responses, revealing a fan-in workflow.\" This is not a measurement: no fan-in workload with multiple concurrent callers sending to one receiver was executed. The paper also notes that if a function is called ten times, CWASI creates ten different functions, \"which means fan-in is the same as ten different sequential workflows\"; that description is itself inconsistent with fan-in semantics. Moreover, the Table 2 fan-in values (CWASI 0.0029/0.0032 s, 298.95/314.20 req/s) are not equal to the fan-out values (0.0045/0.0066 s, 203.73/211.20 req/s), so the \"calculation\" is undocumented and non-trivial. A true fan-in introduces a single receiver bottleneck and socket-accept contention; latency and throughput could be materially lower than fan-out-derived numbers. Since the abstract's 30x headline is specifically the fan-in/WasmEdge comparison, this missing measurement is load-bearing.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents CWASI, a container runtime shim for WebAssembly serverless functions that selects among three inter-function communication modes (Function Embedding, Local Buffer via Unix domain sockets, and Networked Buffer via Redis Pub/Sub) based on function locality and trust. The claimed benefit is reduced latency and increased throughput for co-located serverless functions. The authors evaluate CWASI against WasmEdge RunWasi shim and OpenFaaS across sequential, fan-out, and fan-in workflow patterns, measuring latency, throughput, CPU, and RAM, and report up to 95% latency reduction and up to 30x throughput improvement.","tokens_in":20775,"tokens_out":6704,"duration_ms":59852,"significance":"If the reported gains hold, CWASI would reduce reliance on remote storage and messaging for co-located serverless functions, lowering end-to-end latency and improving data-plane scalability in edge-cloud workflows. The paper contributes a concrete OCI-compliant shim design, pseudocode for mode selection, and an open-source implementation link, which are strengths for reproducibility. The direct sequential and fan-out measurements appear to support large latency gains, and the fan-out throughput gains versus WasmEdge are directly measured. The headline 30x throughput claim, however, rests on fan-in numbers that were not actually measured, and the throughput methodology itself needs clarification. The central idea is solid but the evidence for the strongest claim is incomplete.","major_comments":[{"comment":"The fan-in results in Table 2 are not measurements. Section 7.5 states: 'we use the fan-out experiments and calculate the responses, revealing a fan-in workflow.' The abstract and conclusion base the 'up to 30x' throughput claim on the Fan-in row (CWASI 314.2 req/s vs WasmEdge 8.53 req/s). A fan-in workload with concurrent callers contending on a single receiver introduces accept-queue contention and a potential receiver bottleneck that fan-out measurements cannot capture. Please either run a real fan-in experiment with multiple concurrent callers and report measured values, or remove or qualify the 30x claim.","section":"Section 7.5 (Fan-in Workflow) and Table 2"},{"comment":"The paper's own description of the fan-in proxy is internally inconsistent. It states that if a function is called ten times, CWASI creates ten different functions, 'which means fan-in is the same as ten different sequential workflows.' That is not fan-in; fan-in requires multiple callers to the same receiver. Moreover, the calculation that transforms the fan-out measurements into the Table 2 fan-in numbers is undocumented: the fan-in latency and throughput values (0.0029/0.0032 s, 298.95/314.20 req/s) differ from the fan-out values (0.0045/0.0066 s, 203.73/211.20 req/s), so this is not a trivial reuse of the same data. A derivation of the calculation or, preferably, an actual measurement is needed.","section":"Section 7.5 (Fan-in Workflow)"},{"comment":"The throughput measurement procedure is not a standard sustained-load measurement. The paper says: 'In cases where the executions are lower than one second, we extrapolate, e.g., if we send ten requests that take less than one second, we extrapolate the throughput by considering the rate of execution over a one-second timeframe.' This appears to derive throughput from per-request latency rather than from the number of requests completed under concurrency per unit time. Since the headline claim is about throughput, please describe the load generator, the concurrency level, and the measurement duration, and report throughput as measured under load.","section":"Section 7.1 (Metrics, Throughput)"},{"comment":"No variance is reported. The setup says experiments were repeated ten times and the average collected, but no standard deviation, confidence interval, or per-run values are given. Without variance, the reader cannot assess whether the smaller reported differences, such as the 1.3x throughput advantage over OpenFaaS in fan-out, are significant. Please include error bars or a statistical summary for the key tables.","section":"Section 7.2 (Experiment Setup)"}],"minor_comments":[{"comment":"The sentence 'It is implemented in Rust and currently supports WasmEdge runtime. source code is available on GitHub' is duplicated word-for-word; remove the duplicate.","section":"Section 6 (Implementation)"},{"comment":"'WebAssemly' is misspelled; it should be 'WebAssembly'.","section":"Keywords"},{"comment":"The text says 'CWASI shows around 3 ms, WasmEdge 115 ms, and OpenFaas 7 ms' and repeats this as 'According to Table 2', but the Fan-out rows in Table 2 list 0.0045/0.0066 s for CWASI and 0.1931/0.1950 s for WasmEdge. Please make the text consistent with the table.","section":"Section 7.4 (Fan-out Workflow)"},{"comment":"The opening sentence references 'as shown in Section 7.5' but the fan-in pattern is shown in Fig. 6c; correct the cross-reference.","section":"Section 7.5 (Fan-in Workflow)"}],"recommendation":"major_revision","confidential_remarks":"The paper appears to be an arXiv posting of the ACM SEC '23 paper. The main concern for the editor is that the headline 30x throughput claim depends on a fan-in experiment that was not run; I recommend requiring the authors to either supply real fan-in measurements or soften the claim. The direct sequential and fan-out measurements are useful despite the missing variance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things you should know. First, the core mechanism is real and worth understanding: CWASI is an OCI-compliant runtime shim that gives co-located WebAssembly functions three communication modes - static-link embedding, a Unix-socket local buffer, and a Redis pub/sub network fallback - and selects among them based on locality. That combination is genuinely new relative to SAND, SONIC, Floki, and Faasm. Second, the abstract's headline claim of 30x throughput is not backed by a measured fan-in experiment. Section 7.5 says the fan-in results were 'calculated' from the fan-out experiments, and the Table 2 fan-in numbers do not match the fan-out numbers, so the transformation is undocumented. A true fan-in with many concurrent callers hitting one receiver could behave differently, and the 30x number only appears in that fan-in row. The paper does solid work in the sequential and fan-out evaluations. Those are real measurements, on a single machine, comparing directly against a WASI HTTP baseline and OpenFaaS. CWASI's latency and throughput advantages there are large and consistent. The authors also openly admit the fan-in limitation, which counts in their favor, and the code is open source. The three-mode model is described clearly, and the implementation details are concrete enough to reproduce. The soft spots are the missing fan-in experiment, the complete absence of error bars or variance across the ten repetitions, and a baseline comparison that mixes transport choice with locality-aware selection - so the reported gains conflate the UDS transport with the shim's routing logic. The resource usage section honestly shows CWASI costs more CPU and RAM, but the OpenFaaS setup keeps functions warm while CWASI and WasmEdge start fresh per request, so the resource comparison is not apples-to-apples. None of these sink the paper; they just mean the quantitative claims should be read as provisional. This paper deserves a serious peer review. The fan-in measurement can be run, and the variance reporting is a fixable issue. If you work in serverless or Wasm runtimes, it is worth citing for the three-mode model and the shim design, not for the 30x number. I would bring it to a reading group and engage with it, but I would tell anyone quoting the abstract to check Section 7.5 first.","headline":"A plausible, well-scoped Wasm shim for co-located serverless communication, but the headline 30x throughput claim rests on a fan-in result derived from fan-out data rather than measured.","tokens_in":806,"tokens_out":1575,"would_cite":true,"duration_ms":34295,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"CWASI, a WebAssembly runtime shim, reduces inter-function communication latency between co-located serverless functions by up to 95% and raises throughput by up to 30x.","keywords":["WebAssembly","serverless functions","inter-function communication","runtime shim","function locality","edge-cloud continuum","Unix domain socket"],"falsifier":"Run an actual fan-in experiment with many concurrent source functions sending to a single receiver function on one host and compare measured throughput and latency to the paper's derived fan-in numbers; if they differ materially, the 30x claim is not reproduced. Additionally, re-run the sequential co-located experiment with independent instrumentation to verify the 95% latency reduction.","tokens_in":20326,"feed_emoji":"⚡","tokens_out":7293,"duration_ms":66926,"temperature":0.7,"pith_summary":"CWASI is a WebAssembly runtime shim that decides how two serverless functions exchange data based on whether they run on the same machine. For co-located functions, it bypasses remote object storage and key-value stores, instead using one of three mechanisms: statically embedding trusted functions into a single WebAssembly VM, passing data through a local Unix-domain socket buffer, or, for functions on different hosts, falling back to networked message passing. The paper argues this locality-aware selection is what allows CWASI to reduce communication latency between co-located functions by up to 95% and raise throughput by up to 30x compared to existing WebAssembly and container serverless runtimes. If correct, composed serverless workflows on edge-cloud systems would no longer need remote storage round-trips for every data exchange, lowering both latency and infrastructure cost.","feed_headline":"WebAssembly shim cuts serverless latency by 95%, throughput 30x","feed_subtitle":"A runtime shim routes co-located functions past remote storage for fast local data exchange.","key_machinery":"The load-bearing mechanism is the locality-aware inter-function communication (IFC) selection: a three-mode model—Function Embedding (statically linking multiple WebAssembly modules into one VM so they share memory), Local Buffer (Unix-domain socket data exchange between shims on the same host), and Networked Buffer (publish/subscribe over the network for remote functions)—chosen at runtime by the Function Coordinator (based on OCI annotations) and the Request Dispatcher (based on container-manager state). This machinery replaces remote storage round-trips for co-located functions, directly producing the reported latency and throughput gains.","core_discovery":"CWASI's central claim is that inter-function communication in WebAssembly-based serverless platforms can be optimized by exploiting function locality, and that a runtime shim can perform the mode selection transparently. The shim introduces a three-mode communication model: Function Embedding, where trusted functions from the same namespace are statically linked into a single WebAssembly VM and share memory; Local Buffer, where co-located functions in separate sandboxes exchange data through a Unix-domain socket in the host kernel; and Networked Buffer, which uses publish/subscribe messaging for remote functions. During startup and at runtime, the Function Coordinator and Request Dispatcher components read OCI annotations and container-manager state to pick a mode. The paper reports that in sequential, fan-out, and (derived) fan-in workflow measurements, CWASI lowers latency by up to 95% and raises throughput by up to 30x relative to the WasmEdge and OpenFaaS baselines.","pith_inferences":["A true fan-in experiment (many concurrent senders, one receiver) may expose contention that the paper's derived fan-in numbers miss; the 30x throughput headline should be re-tested with an actual fan-in workload before being taken at face value.","The same locality-aware dispatch idea could generalize to non-WebAssembly serverless runtimes: any shim with access to container-manager state could route co-located traffic through local IPC, though the paper only evaluates Wasm.","Function Embedding trades isolation for speed (shared address space for trusted functions); for multi-tenant edges, that trust assumption is the crux, and the paper's future work on programming models might let deployments express trust boundaries automatically.","If the derived fan-in numbers do hold, CWASI makes high-frequency fan-in aggregations (e.g., many frame processors reducing into one dataset builder) practical on a single node, reducing reliance on cloud-side aggregation services."],"forward_implications":["Co-located serverless workflows in edge-cloud deployments can bypass remote object storage and key-value stores for inter-function data exchange, reducing per-request latency and network overhead.","The mode selection is transparent to the functions: the same function interface works, but data moves through host memory or Unix sockets instead of the network when functions share a host.","In fan-out and derived fan-in patterns, CWASI sustains hundreds of requests per second on a single host, up to 30x the throughput of a plain WebAssembly runtime.","Sequential workflows pay no extra resource penalty: RAM usage drops by up to 30% versus WasmEdge and up to 15% versus OpenFaaS in the reported measurements.","Because the shim is OCI-compliant, it can slot into existing container-manager-based serverless stacks without changing the deployment model."],"supporting_citations":[{"why":"Baseline WebAssembly shim; CWASI's latency and throughput are measured against it.","marker":"[31]"},{"why":"Container-based serverless platform used as a baseline for latency, throughput, and resource comparisons.","marker":"[37]"},{"why":"Wasm runtime used both to implement CWASI and as the primary WebAssembly baseline in experiments.","marker":"[49]"},{"why":"Provides the standard network access that prior approaches used for remote data exchange; CWASI replaces this path for co-located functions.","marker":"[14]"},{"why":"Supplies the mechanism CWASI uses for Function Embedding (static linking of Wasm modules in one VM).","marker":"[25]"},{"why":"Prior serverless communication work with a local message bus; CWASI positions its Local Buffer as an improvement by avoiding a third-party broker.","marker":"[17]"}],"fun_headline_variants":["CWASI shim: 95% lower latency, 30x throughput in serverless","Serverless WebAssembly: CWASI cuts latency 95%, throughput 30x","CWASI: 95% less latency, 30x more throughput for WebAssembly","Runtime shim for WebAssembly serverless: 95% latency cut, 30x throughput"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The fan-in performance numbers in the paper are not measured; they are calculated from the fan-out experiments, so the 30x throughput claim depends on the assumption that a fan-in workflow's timing mirrors a fan-out workflow.","fun_headline_variants_meta":{"raw":{"variants":["CWASI shim: 95% lower latency, 30x throughput in serverless","Serverless WebAssembly: CWASI cuts latency 95%, throughput 30x","CWASI: 95% less latency, 30x more throughput for WebAssembly","Runtime shim for WebAssembly serverless: 95% latency cut, 30x throughput"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000895,"raw_usage":{"total_tokens":3851,"prompt_tokens":933,"completion_tokens":2918,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":2825}},"tokens_in":549,"tokens_out":2918,"duration_ms":20907,"temperature":1.0,"reasoning_tokens":2825,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:00:47.251342+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an actual fan-in experiment with many concurrent source functions sending to a single receiver function on one host and compare measured throughput and latency to the paper's derived fan-in numbers; if they differ materially, the 30x claim is not reproduced. Additionally, re-run the sequential co-located experiment with independent instrumentation to verify the 95% latency reduction.","supporting_citations":[{"cited_title":"Runwasi, 2023","cited_arxiv_id":null,"evidence_quote":"Baseline WebAssembly shim; CWASI's latency and throughput are measured against it."},{"cited_title":"Serverless functions, made simple, 2023","cited_arxiv_id":null,"evidence_quote":"Container-based serverless platform used as a baseline for latency, throughput, and resource comparisons."},{"cited_title":"Wasmedge, 2023","cited_arxiv_id":null,"evidence_quote":"Wasm runtime used both to implement CWASI and as the primary WebAssembly baseline in experiments."},{"cited_title":"Wasi, 2023","cited_arxiv_id":null,"evidence_quote":"Provides the standard network access that prior approaches used for remote data exchange; CWASI replaces this path for co-located functions."},{"cited_title":"How and why to link webassembly modules,","cited_arxiv_id":null,"evidence_quote":"Supplies the mechanism CWASI uses for Function Embedding (static linking of Wasm modules in one VM)."},{"cited_title":"SAND:TowardsHigh-Performance serverless computing","cited_arxiv_id":null,"evidence_quote":"Prior serverless communication work with a local message bus; CWASI positions its Local Buffer as an improvement by avoiding a third-party broker."}],"review_version":1}