Mesh data paths: trace the sockets before counting the proxies

For an Istio-style sidecar deployment with interception enabled on both workloads, trace an ordinary application request from the client socket through local redirection to its outbound proxy. That proxy chooses an upstream and establishes the configured transport to the destination's inbound proxy, which forwards to the destination application. The applications and proxies can use separate connections; an HTTP proxy may multiplex requests rather than preserving a one-to-one connection mapping. The exact redirect method, excluded ports, and application protocol determine whether this trace applies to a particular flow.

On Kubernetes, containers in a pod normally share its network namespace, so a sidecar can listen on addresses reachable through pod-local redirection. An init container or CNI integration can install the interception rules, depending on the deployment. Traffic excluded from interception, unsupported protocols, host-network workloads, or direct bypass paths require separate analysis. The control plane supplies configuration and identity material; it does not ordinarily relay each application request. Confirm the path through listener configuration, socket observations, and matching traffic counters rather than the mere presence of an injected container.

Istio's documented ambient architecture separates a node-local ztunnel process from optional Layer 7 waypoints. Its in-pod redirection model lets the CNI agent provide workload-network-namespace context so ztunnel can establish listeners associated with that namespace, despite the proxy process being node-local. Traffic can be encapsulated and encrypted at the source pod's namespace boundary and decapsulated at the destination's. Describing this merely as a packet taking a detour through one unrelated node socket misses both the interception mechanism and the workload identity boundary.

For two enrolled ambient workloads without a waypoint, the intended path provides Layer 4 transport and identity policy. A destination configured for a waypoint can add a separate Layer 7 processing hop for supported traffic paths. Same-node traffic can still traverse the local proxy mechanism. Ztunnel's identity is not simply substituted as every workload's peer identity; it manages authorized workload identities. These statements describe the documented Istio ambient variant, not every product using node proxies. Enrollment, source type, destination type, and bypass prevention must be checked before claiming equivalent policy coverage.

Mark where plaintext exists, which component authenticates the remote workload, and where an HTTP-aware authorization rule is enforced. A Layer 4 proxy cannot automatically enforce an HTTP path rule it never parses. Mark DNS resolution, endpoint selection, connection reuse, and any gateway explicitly. Then ask what happens if each component is unavailable or misconfigured. A source application can be healthy while its outbound proxy is CPU-throttled, and a destination proxy can accept transport while the application rejects requests. Those are different failure boundaries with different evidence.

The queue lab isolates one intermediary's service capacity. Reset, set λ=4 and μ=3, predict backlog increases by one request unit per second, then Play or Step. Separately Reset, set λ=2 and μ=3, predict the restored four-unit backlog drains in four seconds, then Play or Step. The fluid model has no namespaces, sockets, TLS, or routing. It supports the limited claim that a forwarding component with insufficient service capacity can accumulate waiting work. Use the packet-path drawing, rather than the animation, to identify which real component the model would need to represent.