1. The Claim
As single ports head toward 1.6Tbps, a long-shelved question returns to the center of networking research: can the endpoints still digest it?
The arithmetic (Presto's framing): saturating 1.6Tbps at 8K MTU requires 25Mpps; at 1500B, several times that. The kernel TCP stack's per-packet cost is fixed — measurements cited by Presto show applications spending 48% of per-packet CPU cycles inside the protocol stack even on state-of-the-art kernel-bypass stacks (FlexTOE). Alibaba's production numbers are blunter: kernel-TCP socket operations consume 50–90% of application CPU time (SMC-R). Every bandwidth generation doubles this protocol-stack CPU tax.
SIGCOMM 2026's response is a complete roadmap: seven papers on four routes — programmability (Presto moves the TCP state machine into the switch pipeline), kernel bypass (SMC-R's four-year production lessons), compression (Flow.ZIP header slimming), re-semantics (PacketExpress large MTUs and Capybara's microsecond connection migration) — plus a measurement base map (Host Stack Latency) and Google's incremental signal patch (CSIG). Together with RS15, **the host stack is the most systematically answered of the classical areas AI workloads re-questioned this year (four routes + measurement base map + signal layer)
2. What the Papers Actually Do: Four Routes and One Base Map
2.1 Presto: the TCP state machine moves into the switch pipeline
The contradiction Presto (UW + MPI-SWS, Best Student Paper) attacks was long pronounced unsolvable: TCP's state updates are complex and interdependent — reordering requires read-then-write on the same state — while an RMT (reconfigurable match-action) switch pipeline is one-way, stage-locked, no write-back. Putting a state machine into such a pipeline is asking one-way, no-writeback hardware to execute interdependent state updates. The standing consensus: RMT suits stateless or lightly stateful forwarding; stateful transport protocols do not fit.
Presto dissolves the U-turn with three mechanisms: optimistic concurrency — speculative updates with downstream validation and compensation; pseudo-segment injection — injected dummy packets break cyclic write dependencies without stalling; bump-in-the-wire — single pass, no recirculation. The full TCP stack (retransmission, reordering, flow control, congestion control) lands on a Tofino 2 pipeline.
The numbers (Tofino 2 testbed): 25Mpps/core, saturating 1.6Tbps at 8K MTU; near-1Bpps in scale tests with ~20us 99.99p tails; 16 fewer CPU cores than kernel-bypass TAS while exceeding its peak throughput; KV-store throughput per watt 2x; an FPGA port at 3x Tonic's packet rate under identical timing constraints.
The significance is the capability boundary, not the numbers: RMT's programmability frontier is pushed far outward — stateful transport protocols can live in pipelines. "RMT only forwards" was a design principle; it is now a historical conclusion. Deployability is long-term: waiting for post-Tofino or domestic RMT silicon at production volume.
2.2 SMC-R: four production years of transparent replacement
SMC-R is transparent TCP replacement (RDMA-accelerated shared-memory communication) with four years of production practice at Alibaba Cloud: point_select throughput 1.52x and read_write 1.28x over TCP in production-default configuration. But the paper's value is the lesson, not the numbers.
Over four years, SMC-R's biggest engineering cost was not the stack; it was the fight with every application-configuration combination. The conclusion: applications and system configurations — not protocol-stack optimizations — dominate or amplify the performance problem. Thread counts, buffer policies, and fallback-triggering configuration combos fail at the cross-component level, and "conventional test suites validate isolated spec compliance, not coordinated cross-component behavior". The authors propose LLM-assisted compatibility testing as a way out.
This draws the real boundary of the transparent-replacement route: the protocol can be transparent; the ecosystem cannot. Any RDMA-replacement project should read this paper as a configuration-audit checklist before writing a line of code.
2.3 Flow.ZIP: re-pricing header overhead for the 1.6T era
Header overhead is packet networking's oldest inefficiency: tunneled encapsulation stacks (VXLAN/NVGRE) can exceed 100B per packet. Negligible at small ports; a per-packet tax at 1.6T. Flow.ZIP (UPenn + MSR + Politecnico di Milano + UCL + Broadcom) does hop-agnostic header compression, re-quantifying the marginal cost of per-packet overhead in the 1.6T ledger. The author list is worth noting: UPenn with Vincent Liu on it, plus Broadcom's Ben Basat — header compression sits directly in a switch-silicon vendor's interest line.
(Flow.ZIP's specific compression-ratio and FCT headline numbers are cited qualitatively pending a full pass of its §6.)
2.4 PacketExpress: rewriting MTU semantics at the domain boundary
A defaulted parameter in private and enterprise networks: the 1500B MTU. It means every 9,000 bytes of data pays the per-packet tax six times. Seoul National University-led PacketExpress (PXGW gateway, SNU + KAIST + UT Austin) aggregates 90%+ of 1500B packets into 9000B jumbo frames inside the domain, de-aggregating at the edge.
The effect: unmodified middleboxes gain 4.3-5.1x, end hosts up to 2.5x, with packet-processing counts dropping to at most 1/6 (9000/1500). The clever part is the deployment path: middleboxes untouched, hosts untouched, the change confined to one gateway device — the least invasive of the re-semantics route.
2.5 Capybara: microsecond-scale TCP connection migration
The classic L4 load-balancer dilemma: established connections cannot be rebalanced, because TCP state binds the 4-tuple. Imbalanced connections just have to be endured until they break. The standing consensus: TCP migration necessarily introduces perceptible disruption.
NUS-led Capybara (with ETH + Red Hat/Harvard + UPenn + MSR) rewrites the consensus: a fast L4 LB, a host-switch co-designed migration protocol, and an application-level state-migration interface — a three-tier architecture moving connections without disruption. The numbers: tail latency down up to 149x, 1.47Tbps on 8 CPU cores (three real applications, including TLS). For hyperscale LB operators, this is a mid-term replicable architecture.
2.6 Host Stack Latency: the autopsy all four routes share
Beyond the four exits, this paper (UVA + SKKU + Cornell) answers the shelved basic question — "why does the Linux network stack have millisecond-scale tails?" — with a systematic decomposition of tail-latency sources: the measurement base map every route cites. It forms an evidence chain with Presto: the 48% per-packet protocol-stack CPU figure Presto cites comes from kernel-bypass measurements (FlexTOE); this paper dissects the kernel stack's pathology itself. The four routes treat symptoms; this one does the autopsy — know where the disease is before choosing the therapy.
2.7 CSIG: Google's incremental answer
The star lineup — Cardwell (BBR), Dukkipati, Karp, Vahdat — takes the route opposite to Presto's: no stack change, no offload, just carry multi-bit bottleneck congestion signals (microsecond-granularity switch metrics such as available bandwidth) in a fixed-length Ethernet header. Precision between ECN/RTT (coarse) and P4-INT (hardware-heavy) — high precision with zero hardware dependency. Production result: unclaimed bandwidth down 60%.
3. Route Analysis: The Economics of Four Routes
Placed in a cost × benefit-radius matrix:
(SMC-R does not sit in the matrix: its cost profile shifts across years — protocol replacement is patch-level, ecosystem configuration fights are year-level; its position depends on which layer "change" is defined at.)
Three structural observations:
Observation 1: Google and academia chose opposite answers to the same question. Presto means "solve it completely" (CPU tax to zero); CSIG means "keep stanching" (better signals). Google owns its hardware and protocol-evolution rights (BBR's deployment history) yet still chooses the incremental path — because the replacement cost of production stacks (SMC-R's four years are the evidence) far exceeds algorithmic gains. The divergence is itself the prediction: for the next five years, datacenter traffic runs on "kernel/bypass stacks + better signals"; full offload is the switch/DPU vendors' incremental story, not a stock replacement.
Observation 2: the CPU tax is reaching a qualitative threshold. The 48% (FlexTOE-cited) and 50–90% (SMC-R production) figures mean that at 1.6T ports, protocol-stack CPU costs are the same order as network bandwidth costs. In MaaS unit-cost models, "CPU cost per Gbps" becomes its own line item — the "one H100 sold to a thousand people" ledger from our MaaS series needs a new row.
Observation 3: the routes are not exclusive; they are layering. PacketExpress (domain-boundary MTU) + Flow.ZIP (per-hop compression) + CSIG (signals) can stack; Presto and SMC-R substitute for each other by workload (ultra-low-latency RPC vs general cloud). The endgame is plausibly: large in-domain packets + compressed headers + precise signals + dedicated stacks on critical paths (Presto-class hardware offload or kernel bypass).
4. Evidence Check
| Claim | Number | Source |
|---|---|---|
| 8K MTU at 1.6Tbps = 25Mpps | arithmetic framing | Presto §1 |
| 48% of per-packet CPU in the stack on kernel-bypass | FlexTOE measurement, cited | Presto §1 |
| Kernel TCP socket ops consume 50–90% CPU | Alibaba production | SMC-R §1 |
| SMC-R 1.52× / 1.28× | point_select (32 threads) / read_write (16), production defaults | SMC-R §5 |
| PacketExpress 90%+ 1500→9000B; middleboxes 4.3–5.1×; hosts 2.5× | PXGW gateway | PacketExpress abstract/§5 |
| Capybara tail latency −149×; 1.47Tbps on 8 cores | three applications incl. TLS | Capybara abstract |
| CSIG unclaimed bandwidth −60% | production framing | CSIG abstract |
| Header overhead can exceed 100B (VXLAN/NVGRE stacking) | Table 1 aggregate | Flow.ZIP §1 |
| Presto 25Mpps/core, ~1Bpps, −16 cores, 2× perf/W, ~20μs 99.99p | Tofino 2 testbed | Presto abstract/§5 |
Provenance notes: Flow.ZIP's specific compression-ratio/FCT-improvement numbers are cited qualitatively in this piece pending a full pass of its §6; Presto's numbers are anchored to its fact card from the original text.
5. Assessment and Predictions
1. "Protocol-stack CPU tax" becomes an explicit cost line in 2027–2028. Seven papers besiege the same tax from four directions — production is already hurting. Predictable next moves: clouds writing stack overhead into instance specs (vCPU-bandwidth coupled pricing), and DPU offload graduating from premium feature to default (Azure is already there — the ROE paper is the evidence; AWS/Meta following).
2. TCP will not die; it will stratify. Presto proves TCP semantics can live in hardware pipelines — which extends TCP's life (cheaper than replacing the protocol). Capybara's migration and SMC-R's transparent replacement point to an intermediate state: TCP's external semantics preserved, its internal implementations diversified (kernel / bypass / switch / DPU each holding a segment). That middle state further compresses QUIC's window inside datacenters.
3. CSIG is the BBR team's next move — track it separately. From BBRv1 (2016) to CSIG (2026), Google's congestion-control decade has followed endpoint deployability first. CSIG lifts signal precision to multi-bit/μs granularity with zero hardware requirements — if it enters the Linux mainline (BBR's old path), its deployment count in five years could exceed the vast majority of SIGCOMM congestion-control papers. Small academic footprint, large industrial footprint: conferences systematically undervalue this kind of paper.
4. Deployability in four tiers. Immediate: CSIG's approach (kernel/driver patch level), Flow.ZIP-class header compression (NIC firmware). Mid-term: PacketExpress in-domain jumbos (network-ops retrofit), SMC-R's lessons (a configuration-audit checklist for any RDMA-replacement project). Long-term: Presto full offload (awaiting post-Tofino/domestic-RMT silicon at volume); Capybara's connection migration is mid-term replicable for hyperscale LB operators.
5. Ledger against earlier locsic analysis. The Tomahawk-6 piece judged that "the kernel stack must exit in the 51.2T→102.4T era" — this year's four routes are the complete answer to "exit to where." The MaaS cost ledger needs the CPU-tax row (Observation 2). And reading Presto (Best Student Paper) alongside λλ (Best Paper): both awards point at the same meta-theme — re-dividing labor between abstraction layers and implementation layers. Optics delegates to a type system; transport delegates to a match-action pipeline.
Disclosure: Based on a full close read of Presto plus full text or abstracts of Host Stack Latency, Flow.ZIP, PacketExpress, Capybara, SMC-R, and CSIG. Flow.ZIP's compression-ratio and FCT headline numbers were not located in the sections read and are cited qualitatively; SMC-R's 50-90% and 1.52x/1.28x are Alibaba production figures. Data as of August 22, 2026.
Piece 5 of 6 (final) in the SIGCOMM 2026 close-reading series. The full series: overview (0), KV cache as network citizen (1), collectives become a runtime (2), scale-up as the new datacenter network (3), the photonic software stack (4), protocol stacks at 1.6T (5).