Copper and Wire: Bridging Expressiveness and Performance for Service Mesh Policies

Reviewer: The Guardian

Summary

This paper presents Copper and Wire, a new service mesh architecture designed to improve policy expressiveness and performance. The authors introduce Abstract Communication Types (ACTs) to decouple policies from specific dataplane implementations, a new policy language (Copper) that uses "run-time contexts" to specify policies over request sequences, and a control plane (Wire) that uses a MaxSAT formulation to optimize the placement of sidecars. A key component of the proposed system is a novel eBPF-based mechanism for propagating these run-time contexts without modifying application code. The evaluation, conducted on three microservice benchmarks, claims significant reductions in policy code complexity (up to 6.75x fewer lines), tail latency (up to 2.6x smaller), and resource consumption (up to 39% fewer CPU resources) compared to standard Istio deployments.

While the proposed abstractions are intriguing and the performance gains appear notable, a rigorous examination reveals several methodological weaknesses, questionable assumptions about the dataplane, and claims that may not hold under real-world conditions. The core contribution of transparent context propagation, in particular, seems to rely on a non-transparent protocol modification, and the evaluation may be based on an oversimplified cost model.

Strengths

1. Well-Motivated Problem: The paper correctly identifies significant, widely acknowledged pain points in current service mesh frameworks: poor policy expressiveness for sequential operations, high resource overhead, and challenges with dataplane heterogeneity.
2. Principled Optimization Approach: The use of a MaxSAT solver (Section 5, p.8) to determine sidecar placement is a formal, principled approach to the resource optimization problem, moving beyond the naive "deploy everywhere" default of many current systems.
3. Decoupling Abstractions: The concept of Abstract Communication Types (ACTs) (Section 4.1.1, p.5) is a sound architectural principle for addressing dataplane heterogeneity. It provides a clear path for integrating new proxies without requiring changes to the central control plane logic.

Weaknesses

1. The Context Propagation Mechanism is Fundamentally Non-Transparent: The paper’s claim to transparency is questionable. The eBPF add-on (Section 6, p.9) works by "add[ing] the raw bytes of the context in outgoing requests as a new CTX HTTP/2 frame." This is a direct modification of the L7 protocol. It breaks the contract of a truly transparent sidecar, which should interoperate with any compliant client/server. This approach will fail for any service that does not expect or cannot parse this custom frame. Furthermore, the paper completely omits any discussion of how this mechanism functions in the presence of inter-service TLS encryption. If traffic is encrypted, the eBPF hook cannot inspect or inject headers/frames without TLS termination, which would re-introduce significant overhead and complexity at every hop, undermining the entire performance premise.

2. Oversimplified and Potentially Unrealistic Cost Model: The Wire optimizer's MaxSAT formulation relies on a static, user-provided cost c for each sidecar type (Section 5, p.8). This is a gross simplification. In reality, the overhead (cost) of a sidecar is not a static value; it is a complex function of the specific policies it enforces, the request rate, and the request payload size. A SetHeader operation is not free, yet the "free-policy" classification (Section 5, p.8) allows the optimizer to treat it as such for placement purposes, which could artificially inflate the perceived benefits of the Wire optimizer.

3. Scalability Concerns for Dynamic Environments: The evaluation reports that the MaxSAT solver can take up to 9.8 seconds to find an optimal placement for the largest production graphs (Section 7.2.3, p.13). While this may be acceptable for initial deployment, it raises serious concerns about the system's agility. In a dynamic cloud-native environment with frequent deployments, scaling events, and policy updates, does every minor change require a full, multi-second re-solve? The paper does not address the latency of reconfiguration, a critical metric for production control planes.

4. The "Istio++" Baseline is Insufficiently Strong: The authors introduce an "Istio++" baseline to represent an optimized state (Section 7.2.1, p.11). While better than the naive default, it is still a weak adversary. A skilled operator could use existing Istio/Envoy features (e.g., Lua filters or custom WASM extensions) to achieve context propagation without application modification. This would be complex, but it is the true state-of-the-art for such problems. By not comparing against such a configuration, the paper fails to demonstrate superiority over what is currently possible, albeit difficult.

5. Evidence for Expressiveness is Limited to Simple Cases: The paper claims Copper simplifies writing "complex policies" (Abstract, p.1), but the examples provided (P1-P4 in Table 3, p.10) are primarily simple header manipulations, routing, and access control based on request paths. It is not demonstrated how Copper would handle truly complex, stateful policies, such as conditional request throttling based on a prior authentication flow's outcome, or dynamic request shadowing based on payload content. The regex-based context matching could become unwieldy and unmaintainable for such scenarios.

Questions to Address In Rebuttal

1. Regarding context propagation (Section 6, p.9): Please clarify how the eBPF mechanism handles encrypted (TLS) traffic between services. Does it require service mesh-level TLS termination at every hop where context might be needed, and if so, have you measured the performance impact of this requirement? Furthermore, please justify how introducing a custom, non-standard HTTP/2 frame constitutes a "transparent" solution.

2. Regarding the optimization model (Section 5, p.8): The MaxSAT solver takes up to 9.8s on large graphs. In a dynamic environment, what is the expected reconfiguration latency when a single policy is updated or a single service is scaled? Does this trigger a full re-solve of the entire graph?

3. Regarding the "free-policy" definition (Section 5, p.8): Please justify the classification of policies that perform actions like SetHeader as "free." While they may not require cross-request state, they are not zero-cost in terms of CPU. Could this classification lead to suboptimal placements in scenarios where a "free" policy is placed on a hot-path service, creating a bottleneck?

4. Regarding dataplane heterogeneity: The paper's core eBPF mechanism appears tightly coupled to HTTP/2. How would the Copper/Wire system propagate context for other L7 protocols commonly found in microservice environments, such as Thrift, Kafka, or raw TCP streams, without requiring a separate, custom-built eBPF parser for each?

Paper Title: Copper and Wire: Bridging Expressiveness and Performance for Service Mesh Policies
Reviewer Persona: The Synthesizer (Contextual Analyst)

Summary

This paper presents Copper and Wire, a novel, co-designed service mesh architecture aimed at solving two of the most pressing problems in the field: the difficulty of expressing complex, cross-service communication policies and the significant performance overhead imposed by current mesh implementations. The core contribution is a holistic rethinking of the abstractions used for mesh policy. The authors introduce Abstract Communication Types (ACTs) to decouple policies from specific dataplane implementations, and more importantly, they elevate the "run-time context"—the causal sequence of requests—to a first-class citizen in their policy language, Copper. This allows developers to write intuitive policies over entire request chains. This high-level specification is then consumed by Wire, a performance-oriented control plane that leverages policy semantics and the application graph to generate an optimal, minimal deployment of sidecar proxies. The system is enabled by a lightweight eBPF add-on for efficiently propagating context without requiring a sidecar at every service.

In essence, the work recasts service mesh policy from a per-service, endpoint-centric configuration problem into a holistic, application-aware optimization problem, akin to compiling a high-level program down to efficient machine code.

Strengths

1. A Powerful Central Abstraction: The most significant contribution of this work is the conceptual leap of making the request "context" a primary primitive for policy specification (Section 4.1.2, page 5). This directly maps to the mental model developers have of their applications, where a user action triggers a cascade of internal service calls. By allowing policies to be written as regular expressions over these service chains (e.g., "frontend.*catalog"), Copper elegantly sidesteps the brittleness and complexity of today's approaches, where developers must manually stitch together multiple per-service policies and even modify application code to propagate context (as illustrated beautifully in Figure 1). This is a fundamental shift that connects the service mesh policy layer to the well-established domain of distributed tracing, using trace context not just for observability but for active policy enforcement.

2. Elegant Co-design of Language and System: The paper's strength lies in its holistic design. This is not merely a new DSL, but a complete system where each component complements the others. The semantics of the Copper language (e.g., [Egress] annotations on actions, as described in Section 4.1.3) provide crucial information that the Wire control plane's optimizer directly uses in its MaxSAT formulation (Section 5, page 8). This tight coupling between the high-level language and the low-level optimizer is what enables the impressive performance gains. It's a classic example of how raising the level of abstraction can unlock new optimization opportunities that are impossible when working with low-level, imperative configurations.

3. Addressing Dataplane Heterogeneity: The paper correctly identifies the tight coupling between control planes and dataplanes as a major limitation in the current ecosystem. The introduction of Abstract Communication Types (ACTs) and dataplane-provided interfaces is a thoughtful solution. It provides a principled path towards a truly "pluggable" dataplane, allowing operators to mix-and-match proxies (e.g., a feature-rich Envoy with a lightweight Cilium-proxy) based on the specific policy requirements of different services. This is a practical and important contribution that could have a significant impact on the evolution of the service mesh landscape.

4. Strong and Convincing Evaluation: The evaluation in Section 7 is comprehensive and effectively supports the paper's claims. By comparing against both standard Istio and an improved Istio++ baseline, the authors demonstrate that their performance gains are not just from avoiding naive deployments but from fundamentally better optimization. The results showing up to 6.75x fewer lines of policy code (Table 3), 2.6x lower tail latency, and 39% lower CPU usage (Figures 9 and 10) are substantial. The inclusion of an evaluation on real-world production traces from Alibaba (Section 7.2.2) further grounds the work in reality, showing its potential effectiveness on large, complex application graphs.

Weaknesses

While the technical vision is compelling, its path to real-world impact faces some challenges that could be discussed further.

1. The "Clean Slate" Adoption Barrier: The work proposes a ground-up redesign, which, while technically elegant, presents a significant adoption hurdle. The ecosystem is heavily invested in existing APIs like Istio's. The paper touches on migration in Section 8, suggesting dataplane vendors would need to provide Copper interfaces and compilers. This is a very high bar. The work would be even more impactful if it explored a more gradual migration path. Could the Copper abstractions be used to generate configurations for existing control planes like Istio as an intermediate step, providing the expressiveness benefits while the optimization framework is adopted later?

2. Scope of Context Propagation: The current eBPF-based context propagation mechanism (Section 6, page 9) is cleverly designed for synchronous, RPC-style communication (like gRPC over HTTP/2). However, modern microservice architectures are increasingly reliant on asynchronous communication via message queues and event buses (e.g., Kafka, RabbitMQ). It is unclear how the notion of a causal "run-time context" would be defined and propagated across these asynchronous boundaries. This is not a flaw in the current work but a significant question about the generalizability of the proposed mechanism to a broader class of distributed applications.

3. Implicit Handling of Policy Conflicts: The paper proposes a very expressive policy language, which naturally raises the question of how to handle conflicting policies. For instance, what happens if one policy applies a RouteToVersion action and another applies a Deny action to the same request? The authors acknowledge this as an interesting future direction in their conclusion (Section 8). While understandable to scope out, the lack of a defined semantics for policy composition or conflict resolution is a notable omission for a system intended for production use. The richness of the language makes this problem more acute than in simpler systems.

Questions to Address In Rebuttal

1. Regarding the adoption challenge: Could the authors elaborate on a potential incremental adoption path? For instance, could the Copper/Wire architecture coexist with an existing Istio control plane, perhaps managing a subset of services, to allow organizations to migrate gracefully rather than requiring a "rip and replace" approach?

2. Regarding the scope of context: How do the authors envision extending the concept of "run-time context" and the corresponding eBPF propagation mechanism to applications that use asynchronous communication patterns, such as event buses or message queues, which do not have a direct request-response structure?

3. Regarding policy conflicts: The paper acknowledges this as future work. However, could the authors comment on whether the proposed abstractions (ACTs, contexts) might themselves offer a more principled way to detect or even resolve such conflicts, perhaps by defining policy priorities or composition rules as part of the language itself?

Reviewer: The Innovator (Novelty Specialist)

Summary

This paper presents Copper and Wire, a co-designed service mesh architecture aimed at improving policy expressiveness while minimizing performance overhead. The authors identify three core novel contributions:

1. Abstract Communication Types (ACTs): A new abstraction layer for network communication primitives (requests, responses, connections) and their associated actions, designed to decouple policy logic from specific dataplane implementations.
2. Context-based Policies (Copper): A new policy language, Copper, that operates on these ACTs. Its central feature is the ability to define policies over "run-time contexts," which represent the causal sequence of service interactions leading to a communication event. These contexts are expressed as regular expressions over service names.
3. Optimized Control Plane (Wire): A new control plane, Wire, that leverages semantic information from the ACT interfaces (e.g., [Ingress]/[Egress] annotations) and the application's communication graph to formulate a sidecar placement problem as a MaxSAT instance. This allows it to deploy a minimal set of sidecars to enforce policies correctly.

The core novelty claim is not any single one of these components in isolation, but rather their synergistic integration, creating a "semantic bridge" from high-level policy expression down to low-level, optimized resource deployment.

Strengths (in terms of novelty)

1. The Semantic Bridge between Policy and Placement: The most significant novel contribution is the co-design of the policy language and the control plane optimizer. Current control planes like Istio treat dataplane configurations as an opaque target. In contrast, Wire uses the semantic annotations ([Ingress], [Egress], "free-policy" classification) derived from the ACT interfaces (Section 4.1.3, page 6) to reason about where a policy action can be validly enforced. This allows for a principled optimization that is not possible in existing systems. This tight coupling between the language's semantics and the control plane's optimization logic is genuinely new.

2. Novel Policy Abstraction and Representation: While the desire for more expressive policies is not new, the specific abstractions proposed are. The concept of a context pattern expressed as a regular expression (Section 4.2, page 7) is an elegant and novel way to specify policies over complex request sequences without requiring developers to write separate rules for each intermediate service. This is a distinct and arguably more flexible representation than the explicit tree structures proposed in prior work.

3. Pragmatic and Novel Implementation of Context Tracking: The system's viability rests on low-overhead context tracking. The choice to use an eBPF add-on is not novel in itself (Cilium is built on eBPF). However, the specific implementation detailed in Section 6 (page 9) is novel. The technique of adding the context as a raw custom HTTP/2 frame to avoid complex L7 header parsing within the constraints of eBPF is a clever piece of engineering that makes the high-level concept of contexts practical.

Weaknesses (in terms of novelty and differentiation from prior art)

1. Conceptual Overlap with Prior Work on Expressive Policies: The paper positions itself against mainstream service meshes like Istio but does not sufficiently differentiate its core ideas from recent academic work. Specifically, Grewal et al. (HotNets '23) [24] also proposed a system for "Expressive Policies For Microservice Networks" using "service tree" abstractions to capture request flows. The "run-time context" in this paper appears to be a linear/string-based representation of a similar concept. The paper's novelty would be strengthened by a direct and detailed comparison, articulating why the regex-based context is a significant advancement over service trees, beyond syntactical differences.

2. The Goal of Dataplane Heterogeneity is Not New: The paper claims to better support dataplane heterogeneity. ServiceRouter (OSDI '23) [32] was also an attempt to use multiple dataplanes in a single mesh. While the mechanism proposed here (ACTs as a formal interface) is a cleaner and less intrusive approach than ServiceRouter's common RPC library, the foundational goal is not entirely novel. The contribution should be framed more precisely as a novel architecture for achieving heterogeneity, rather than claiming the goal itself is new.

3. Limited Exploration of the Abstraction's Expressiveness: The context is represented as a linear sequence of services. It is not clear if this abstraction is powerful enough to express policies that depend on non-linear or conditional paths (e.g., "apply policy if the request path included service A but not service B"). The novelty of the regex abstraction is tied to its expressiveness, and the limits of this are not fully explored.

Questions to Address In Rebuttal

1. Please provide a detailed comparison of Copper's context patterns with the "service tree" abstractions proposed by Grewal et al. [24]. What classes of policies can be expressed by one and not the other? Is the primary contribution a more ergonomic syntax, or is there a fundamental difference in expressive power?

2. The regex-based context appears to capture a linear path of execution. How would the Copper language express policies that depend on more complex path properties, such as branching (e.g., a request from A that goes to either B or C, but the policy at D depends on which one was chosen) or negative constraints (e.g., a path that did not include a specific service)?

3. The ACT abstraction relies on dataplane vendors to provide implementations that are semantically equivalent (e.g., SetHeader should behave identically across dataplanes). How does the framework handle subtle but important semantic differences in the implementation of actions across different proxies? For example, what if RouteToVersion in Dataplane A has different retry logic or failure semantics than the same-named action in Dataplane B? Does the abstraction leak?

4. The core optimization problem is framed around minimizing the number of sidecars. With the emergence of architectures like "ambient mesh" that move the proxy function to a shared node-level agent, how does the novelty of Wire's placement optimization hold up? Is the contribution fundamentally tied to the per-pod sidecar model, or can the semantic-driven optimization be adapted to these newer models?