{"id":"9ac16bbe-3f39-4dcf-ab96-90ba52cb2ed0","arxiv_id":"2507.11929","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Proteus's decision workflows let developers customize serverless function scaling and scheduling, and a prototype shows better query performance and shared resource use.","lead":"Proteus is a serverless platform that lets developers write small custom rules for how functions are scaled and scheduled, instead of forcing them to choose between a slow general platform or building a specialized one from scratch. The paper shows a prototype speeding up a data analytics query and filling idle CPU time with background tasks.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section 4's control-plane/data-plane dichotomy is asserted, not demonstrated; the single-query evaluation cannot rule out that analytics performance depends on domain-specific data-plane mechanisms.","rationale":"The paper is a clearly written vision-plus-preliminary-prototype. The decision workflow abstraction and the Join decision node in Fig. 6 are concrete and useful, and the paper appropriately labels results as preliminary. However, the central argument depends on a strong dichotomy: domain-specific optimizations live in the control plane; the data plane is application-agnostic and shared. This is not a standard-systems assumption that can be taken on faith; the paper's own related work includes systems whose core contributions are data-plane mechanisms tied to analytics (SONIC, MinFlow, Ditto, Pocket). The prototype's evaluation is too narrow to resolve the dichotomy: one TPC-DS sub-query, no external baselines, three internal strategies, and an optimized shared-memory data plane that is itself a data-plane optimization. Consequently, the 'effectively optimizes' and 'fine-grained resource sharing' results cannot be cleanly attributed to the extensible control plane. The proposed ablation test would determine whether the data plane or the control plane is responsible for the gains and whether the data plane is truly domain-agnostic. Because the concern is addressable with additional experiments and does not disprove the vision, CONDITIONAL is appropriate; if the test shows the dichotomy fails, the verdict would move toward REJECT.","tokens_in":11537,"tokens_out":6635,"duration_ms":78545,"concrete_test":"Run the 6 GB TPC-DS case from Fig. 7 on two builds of Proteus: build A uses the prototype's shared-memory data exchange; build B replaces only the data plane with TCP/object-store shuffling while keeping the DYN decision workflow and all control-plane logic identical. If the build A vs B latency gap is comparable to or larger than the DYN-vs-static gap in Fig. 7, then data-plane implementation is a first-order contributor and the paper's attribution of performance to control-plane extensibility is unsupported. Then repeat both builds on a second domain (e.g., a video-processing pipeline); if the data-plane design that is best for analytics is not best for video, the application-agnostic data-plane claim in Section 4 is empirically falsified.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"Section 4's 'key insight' is the keystone: Proteus must make the control plane extensible while keeping an application-agnostic data plane. If analytics-relevant performance leverage actually lives in data-plane mechanisms that are domain-specific, Proteus reduces to a scheduling API and does not resolve the generality/specialization tradeoff. The paper's own citations undermine the dichotomy: SONIC [33] is 'application-aware data passing'; Ditto [21] and MinFlow [26] redesign storage/data passing for analytics; Pocket [24] provides analytics-specific storage. The prototype does not test the assumption: Fig. 7 compares only three Proteus-internal control strategies on one TPC-DS sub-query, and the prototype's shared-memory data exchange is itself a data-plane optimization. No comparison to a general-purpose FaaS platform or a specialized analytics system is provided, so the claimed 'effectively optimizes' cannot be attributed to the control-plane abstraction rather than the data plane. The concern is therefore load-bearing: if the dichotomy fails, the central design principle must be revised to expose or co-design data-plane extensions, which the current prototype neither supports nor evaluates.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an extensible design principle for serverless computing: keep a shared general-purpose FaaS platform but let developers customize control-plane behaviors (scaling and scheduling) through a new decision-workflow abstraction. Proteus is a prototype implementing this principle, with a decentralized control plane and a data plane using shared-memory data exchange. The authors evaluate Proteus on a single TPC-DS sub-query on a 6-node cluster, comparing three internally defined strategies (static merge join, static hash join, dynamic), and report CPU allocation under co-running background functions. They discuss generalization to other domains and integration with existing FaaS as future work.","tokens_in":11775,"tokens_out":5097,"duration_ms":53712,"significance":"If the central design principle is validated, it offers a useful way to mitigate the tradeoff between general-purpose FaaS and specialized serverless systems. The decision-workflow abstraction is a clean interface for embedding domain knowledge into scaling and scheduling, and the decentralized controller design with global and private controllers is reasonable. The paper honestly frames results as preliminary and discusses limitations. However, the evaluation as presented does not establish the key attribution claim: it lacks external baselines, tests only one query, and the dynamic strategy's thresholds appear fitted to the motivating measurements. The significance is therefore conditional on a stronger experimental demonstration.","major_comments":[{"comment":"Section 4 asserts the key insight that application-specific optimizations occur mainly in the control plane while data-plane behaviors are 'largely independent of application semantics.' This dichotomy is load-bearing but not demonstrated. The evaluation in §6 cannot isolate the effect of the extensible control plane: Fig. 7 compares only three Proteus-internal control policies, and the prototype itself uses shared-memory data exchange, which is a data-plane optimization. Moreover, the paper's own related-work discussion lists analytics-specific data-plane mechanisms (SONIC [33] 'application-aware data passing'; Ditto [21] and MinFlow [26] redesigned data passing; Pocket [24] analytics-specific storage). The authors should provide a comparison against a general-purpose FaaS platform (e.g., AWS Lambda with PyWren) and a specialized analytics system (e.g., Ditto or MinFlow), or otherwise show that the observed gains are attributable to the control-plane abstraction rather than to data-plane mechanisms.","section":"§4, §6"},{"comment":"The experimental evaluation is too narrow to support the abstract's claim that Proteus 'effectively optimizes analytical query execution.' Fig. 7 reports one TPC-DS sub-query on a 6-node cluster, and the only comparators are two static strategies defined by the authors within Proteus. There is no comparison to an existing general-purpose serverless platform or to an analytics-specialized serverless system, and no error bars or repeated runs are reported. At minimum, the paper should either add such baselines and additional queries, or scale back the claim to demonstrating the feasibility of the decision-workflow abstraction on a single workload.","section":"§6, Fig. 7"},{"comment":"The dynamic strategy's advantage over static strategies is partly by construction. The thresholds T1 and T2 in Fig. 6 are described as 'predefined,' and the text says the decision rule is 'based on observations in Fig. 4,' meaning the same measurements that motivate the design are used to fit the policy. The evaluation in Fig. 7 then tests this fitted policy on the same join scenario. To break the circularity, the authors should report the values of T1 and T2 and the scaling parameter 'a', and validate DYN on held-out data sizes, distributions, and cluster configurations, or derive the thresholds from an independent model.","section":"§5.1, Fig. 6; §6"},{"comment":"There is a factual inconsistency in the experimental setup. Section 3 states that Fig. 4 was produced 'using a 12-node cluster (detailed testbed described in §6),' but §6 says the prototype is deployed on a 6-node cluster of c5.2xlarge instances. Since the DYN decision thresholds in Fig. 6 are justified by the Fig. 4 measurements, it matters which cluster size generated Fig. 4. Please correct the inconsistency and state the testbed for each figure.","section":"§3, §6"},{"comment":"The resource-sharing experiment shows CPU allocation rates but does not report the query completion-time overhead relative to running the query alone, nor the throughput or utility of the background functions. The text claims Proteus improves resource efficiency 'without compromising the performance of critical workloads,' but Fig. 8 alone does not establish that no compromise occurred; the query time under co-tenancy is not shown. Please add a quantitative comparison (query latency with and without background tasks, background task progress, and a baseline sharing policy).","section":"§6, Fig. 8"}],"minor_comments":[{"comment":"The caption contains a typo: 'Join exmaple' should be 'Join example.'","section":"Fig. 3"},{"comment":"Fig. 7 shows only aggregate bars per data size; consider adding standard deviations or per-run markers to indicate variance.","section":"§6, Fig. 7"},{"comment":"The interface example uses an undefined scaling denominator 'a' and undefined thresholds T1 and T2; please define these or clearly mark them as illustrative placeholders.","section":"§5.1, Fig. 6"},{"comment":"The term 'normalized cost (measured as resource-time)' is not defined; specify the formula and units used in Fig. 4 (b) and (d).","section":"§3"},{"comment":"The discussion of complexity is qualitative; a quantitative measurement of decision-node execution overhead would strengthen the argument.","section":"§7.1"},{"comment":"The abstract says 'preliminary results show that Proteus's prototype effectively optimizes analytical query execution'; consider wording this as 'can effectively optimize' or 'demonstrates feasibility' to match the limited evaluation.","section":"Abstract"}],"recommendation":"major_revision","confidential_remarks":"The paper reads more like a vision/position statement with a preliminary prototype than a complete systems paper. For the current venue, I would recommend accepting a significantly revised version with the experimental additions above, or explicitly reframing the paper as a vision paper. There is also a notable number of self-citations and preprints in the reference list; this is not a problem by itself, but it may warrant editorial awareness."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: this is a vision paper with a thin but real prototype. The decision workflow abstraction—letting developers customize scaling and scheduling through explicit control-plane nodes—is a genuinely new framing for the general-purpose vs specialized serverless tradeoff. The paper is worth reading for that idea alone. But the evaluation is far too narrow to back the claim that Proteus 'effectively optimizes analytical query execution.'\n\nWhat's good: the positioning is clear. Frameworks on general-purpose FaaS treat the platform as a black box; specialized systems like Ditto and MinFlow rebuild the platform. Proteus sits between, exposing control-plane decisions while keeping an efficient shared data plane. The join example in Fig. 6 is concrete and the API is simple enough to follow. The authors are honest that this is preliminary, and the discussion of future work is proportionate.\n\nWhere it's soft: the load-bearing assumption in Section 4—that analytics-specific optimizations live almost entirely in the control plane and the data plane can stay generic—is asserted, not demonstrated. Several cited papers (Pocket, SONIC, Ditto, MinFlow) put analytics performance leverage precisely in data-passing and storage, i.e., the data plane. The prototype's shared-memory data exchange is itself a data-plane optimization. So the evaluation can't isolate the control-plane contribution. The only query experiment uses one TPC-DS sub-query on 6 nodes, compares three Proteus-internal strategies, and has no external baselines, no error bars, and no artifacts. The DYN strategy's thresholds T1 and T2 come from the same measurements shown in Fig. 4, so part of its win is fitted by construction. These are real gaps, but they are gaps a full paper can close. For a workshop-style preliminary report, the evidence is acceptable; for the broad claims in the abstract, it is not.\n\nWho it's for: people working on serverless platforms, analytics-on-FaaS, and extensible schedulers. The abstraction is a useful lens even if the specific prototype doesn't prove it yet. I'd send it to peer review—a serious referee would demand external baselines and a test of the control/data-plane split, but the idea deserves that attention.\n\nYes, engage with it.\n\nBest.","headline":"A clear vision for an extensible serverless control plane, backed by a thin prototype; the abstraction is genuinely new, but the evaluation is too narrow to carry the broad claims.","tokens_in":12256,"tokens_out":2398,"would_cite":true,"duration_ms":24106,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper argues that serverless platforms can avoid the choice between general-purpose ease and application-specific performance by making the control plane (scaling and scheduling) extensible while keeping the data plane shared.","keywords":["serverless computing","FaaS","extensible design","control plane","serverless data analytics","decision workflows","function scheduling","resource sharing"],"falsifier":"Run a data-movement-heavy analytical query, such as a large multi-way join with heavy shuffle, on a platform where developers customize only scaling and scheduling while the data plane is fixed and generic, then apply a data-plane-only optimization such as serialization-free state transfer; if that optimization yields a speedup no control-plane decision can match, the control-plane-only hypothesis fails. A simpler check: compare a dynamic custom strategy against a static strategy that is optimal for each data size, and verify whether the dynamic strategy's advantage persists across distributions and cluster sizes.","tokens_in":1790,"feed_emoji":"☁️","tokens_out":4164,"duration_ms":140890,"temperature":0.7,"pith_summary":"The paper argues that the standard dilemma in serverless computing — general-purpose platforms underperform on complex workloads, while application-specific systems sacrifice ease of use and shared resource efficiency — can be resolved by making the platform extensible. Its central claim is that for serverless analytics, the optimizations that matter are control-plane decisions: how many function instances to scale, which join algorithm to use, and how to schedule functions onto nodes, all driven by data distribution and node state. Proteus is a prototype that exposes these decisions to developers through a decision-workflow abstraction, while keeping a general-purpose data plane for data sharing and function startup. Preliminary measurements on a TPC-DS subquery show that a developer-customized dynamic strategy outperforms static hash and merge join strategies, and that low-priority background functions can fill idle CPU during shuffle phases. If the claim holds, domain-specialized performance and shared, easy-to-use serverless operation are not mutually exclusive.","feed_headline":"Extensible serverless: customize scheduling, share the data plane","feed_subtitle":"Proteus lets developers tune scaling and scheduling while the data plane stays shared.","key_machinery":"The mechanism carrying the argument is the decision workflow, an abstraction in the control plane that represents a group of functions as a decision node and an entire application as a workflow of such nodes. Each decision node takes runtime system knowledge — data distribution, node status, available slots — as input and outputs a decision tuple specifying which function to invoke, how many instances to scale, and which scheduling policy to apply, such as round-robin or packing. Decision workflows extend ordinary function workflows by letting developers embed application-specific scaling and scheduling logic that executes dynamically during query runs. Supporting this is a decentralized control plane: one global controller coordinates resource allocation and maintains a system-wide view, while per-application private controllers run the custom decision logic and manage application-level information. The data plane itself is deliberately left generic and shared, relying on existing data-plane optimizations as complementary to the control-plane extensibility.","core_discovery":"The core discovery is a design principle: a serverless platform can meet ease of use, generality, and satisfactory performance simultaneously by making only its control plane extensible. The paper's key insight is that application-specific optimizations for analytics — choosing between sort-merge join and broadcast hash join, setting the degree of function parallelism, and selecting round-robin versus packing scheduling — depend on system-level knowledge such as data sizes, node slots, and data distribution, and all of that lives in the control plane. Data-plane behaviors such as data sharing and function startup are largely independent of application semantics, so they can be provided once in a shared, efficient form. Proteus realizes this with decision nodes and decision workflows: each decision node consumes runtime data distribution and node status and emits a tuple of function, scale, and schedule, executed as part of the end-to-end workflow at runtime. The prototype's experiments show a dynamic custom strategy switching between join implementations and scheduling policies improves query completion time over static strategies, and that a global-and-private controller arrangement lets low-priority tasks use idle resources during query shuffle phases.","pith_inferences":["The control-plane/data-plane split predicts which applications will benefit from Proteus: workloads whose performance is governed by scaling and scheduling, such as analytics joins, inference batching, and graph partitioning, should transfer with little loss, while workloads whose performance hinges on specialized data movement will not; the paper does not run that comparison.","Exposing data distribution and node status to developers creates a cross-tenant information channel that the paper does not address: a developer could infer other tenants' data sizes or resource topology from the system knowledge Proteus provides, raising isolation questions.","A natural, testable extension is quantifying developer effort: if decision workflows are sufficient, implementing an analytics operator on Proteus should require much less code than building a specialized serverless system, a claim the prototype's construction suggests but does not measure.","The same abstraction should carry to machine-learning inference serving, where the control-plane choices are batch size, model placement, and swapping; the paper lists this as future work, so it remains an untested inference rather than a demonstrated result."],"forward_implications":["Application developers can encode domain knowledge directly into the platform through a small interface — for instance, when to switch between hash join and sort-merge join, how many function instances to scale, and whether to pack or round-robin — instead of building a separate scheduling layer.","Because the data plane is shared and general, existing data-plane optimizations can be integrated into Proteus without rearchitecting each application, so the platform can accumulate improvements across domains.","In multi-tenant operation, low-priority delay-tolerant functions can be scheduled into the CPU idleness left by data-shuffle phases, raising overall resource utilization without delaying the query.","Proteus's control plane can be layered on existing FaaS systems that already separate control from data plane, making the extensibility idea portable to production platforms.","For simple workloads with no customization need, Proteus falls back to default function workflows and behaves like a standard FaaS platform, preserving ease of use."],"supporting_citations":[{"why":"Defines the approach of running analytics frameworks atop a general-purpose serverless platform while treating the platform as a black box; this is the first horn of the tradeoff the paper targets.","marker":"[22]"},{"why":"Represents analytics-specialized serverless systems that redesign the underlying platform for performance; this is the second horn of the tradeoff.","marker":"[21]"},{"why":"Provides another specialized analytics system whose built-in data passing shows both the performance gains of specialization and the generality losses Proteus tries to avoid.","marker":"[26]"},{"why":"Supplies an external scheduling approach for serverless analytics, the kind of control-plane logic that Proteus lets developers customize instead of building externally.","marker":"[56]"},{"why":"Provides the decentralized scheduling model of shared cluster state with private schedulers that Proteus adapts for multi-application resource sharing.","marker":"[40]"},{"why":"Documents a production FaaS platform with separated control and data planes and delay-tolerant low-priority workloads, grounding Proteus's resource-sharing experiment and integration discussion.","marker":"[38]"},{"why":"Supplies an example of data-plane-oriented ephemeral storage for serverless analytics, used to show that data-plane optimizations are complementary to Proteus's control-plane extensibility.","marker":"[24]"}],"fun_headline_variants":["Control plane: the key to serverless extensibility","Proteus: tune serverless scheduling, share the data plane","Serverless: extend control, keep data plane shared","Customize serverless control without losing simplicity"],"cache_read_input_tokens":14464,"weakest_assumption_plain":"The design stands on the assumption that for serverless analytics the performance-critical optimizations are all in the control plane — how many function instances run and where they run — so the shared data plane can stay generic; if significant speedups require application-specific data movement or startup behavior, or if exposing system state to developers breaks tenant isolation, the claimed combination of performance and generality collapses.","fun_headline_variants_meta":{"raw":{"variants":["Control plane: the key to serverless extensibility","Proteus: tune serverless scheduling, share the data plane","Serverless: extend control, keep data plane shared","Customize serverless control without losing simplicity"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000172,"raw_usage":{"total_tokens":1256,"prompt_tokens":904,"completion_tokens":352,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":520,"completion_tokens_details":{"reasoning_tokens":288}},"tokens_in":520,"tokens_out":352,"duration_ms":5108,"temperature":1.0,"reasoning_tokens":288,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T16:58:21.914629+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a data-movement-heavy analytical query, such as a large multi-way join with heavy shuffle, on a platform where developers customize only scaling and scheduling while the data plane is fixed and generic, then apply a data-plane-only optimization such as serialization-free state transfer; if that optimization yields a speedup no control-plane decision can match, the control-plane-only hypothesis fails. A simpler check: compare a dynamic custom strategy against a static strategy that is optimal for each data size, and verify whether the dynamic strategy's advantage persists across distributions and cluster sizes.","supporting_citations":[{"cited_title":"Occupy the cloud: Distributed computing for the 99%","cited_arxiv_id":null,"evidence_quote":"Defines the approach of running analytics frameworks atop a general-purpose serverless platform while treating the platform as a black box; this is the first horn of the tradeoff the paper targets."},{"cited_title":"Ditto: Efficient serverless analytics with elastic parallelism","cited_arxiv_id":null,"evidence_quote":"Represents analytics-specialized serverless systems that redesign the underlying platform for performance; this is the second horn of the tradeoff."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides another specialized analytics system whose built-in data passing shows both the performance gains of specialization and the generality losses Proteus tries to avoid."},{"cited_title":"Caerus: NIMBLE task scheduling for serverless analytics","cited_arxiv_id":null,"evidence_quote":"Supplies an external scheduling approach for serverless analytics, the kind of control-plane logic that Proteus lets developers customize instead of building externally."},{"cited_title":"Omega: flexible, scalable schedulers for large compute clusters","cited_arxiv_id":null,"evidence_quote":"Provides the decentralized scheduling model of shared cluster state with private schedulers that Proteus adapts for multi-application resource sharing."},{"cited_title":"XFaaS: Hyperscale and low cost serverless functions at meta","cited_arxiv_id":null,"evidence_quote":"Documents a production FaaS platform with separated control and data planes and delay-tolerant low-priority workloads, grounding Proteus's resource-sharing experiment and integration discussion."},{"cited_title":"Pocket: Elastic ephemeral storage for serverless analytics","cited_arxiv_id":null,"evidence_quote":"Supplies an example of data-plane-oriented ephemeral storage for serverless analytics, used to show that data-plane optimizations are complementary to Proteus's control-plane extensibility."}],"review_version":1}