Speed did not settle the argument
SlimTCP came out on top in the paper's one-connection test at larger segment settings, but that result does not answer the question the work set out to test. At the larger MSS settings used in the test - in other words, segment sizes of 1,024 bytes or more - SlimTCP sending to SlimTCP receiving was reported as the most performant, with 23.6 Gb/s of goodput, or useful data throughput, and a claim that it saturated the link. At smaller MSS values, mTCP sending to SlimTCP receiving was faster.
That gives SlimTCP a lead in one range of the benchmark, not a general verdict on simplified networking. The paper's question is whether simplifying the TCP/IP stack increases performance in data-centre networks. Its authors conclude that the simpler-stack performance claim remains ambiguous.
A deliberately reduced stack
SlimTCP uses a reduced feature set. It does not implement SACK, PAWS, TCP timestamps, congestion control, Fast Retransmit or reorder buffers. The design is the paper's test of whether a simpler TCP/IP stack can be faster in the target network setting.
Three stacks were benchmarked: SlimTCP, F-Stack and mTCP. They appeared in nine sender-receiver stack/protocol tuples. For the comparison, F-Stack and mTCP were patched to skip receive checksum verification and to remove LRO, TSO, RSS and timestamps.
What was actually measured
The work used a bare-metal testbed with two hosts connected by a switch. Each host had 10 cores and 32 GiB of RAM. The NICs allowed up to 25 Gb/s and 68 million packets per second per port, and only one port was used.
Two benchmarks were performed. The first varied transmitted segment size with one connection. The second fixed MSS at 1,400 and varied the connection count. The reported endpoints were achieved packet rate and goodput - the useful data rate - across those settings.
Larger segments, steadier totals
For SlimTCP sending to SlimTCP receiving, the segment-size table reports 1.9G at 64-byte segments, 6.8G at 256 bytes, 13.0G at 512 bytes and 23.7G at 1,460 bytes. The displayed row therefore rises as the segments get larger. The paper does not report a run count or variability measure for these figures.
There is a reporting mismatch at the high end. The results narrative gives 23.6 Gb/s for the large-segment SlimTCP-to-SlimTCP result, while the table lists 23.7G for that pairing at 1,460 bytes. The two values are not fully reconciled in the supplied analysis.
In the connection-count benchmark, the authors identify SlimTCP sending to SlimTCP receiving as the most scalable tuple. The table lists 23.7G at 1, 1,024 and 2,048 connections, and 23.6G at 4,096 connections for the same pairing.
On the displayed figures, total goodput stays almost flat as the connection count climbs from one to 4,096. But repeated-run information and variability estimates are not reported, so the result does not show how consistently the pattern would recur.
Why the result remains open
The authors' caution goes beyond the headline numbers. They report receive-path code sizes of around 1 KiB per TCP segment for both mTCP and SlimTCP, compared with L1 instruction-cache sizes on the order of tens of KiB. They use that comparison to argue that further code-size reduction would not by itself explain additional performance gains.
The mixed-stack results also included intermittent retransmission timeouts, or RTOs, when SlimTCP was the sender and another stack was the receiver. The paper's suggested explanation, involving a faster sender and overflowing NIC receive rings, is explicitly tentative.
Taken together, the tests show that SlimTCP can be fast in selected configurations, while leaving the reason for that advantage unsettled. Performance changed with segment size, the displayed connection-count values stayed nearly level, and mixed-stack pairings sometimes produced RTOs. The authors therefore leave the simpler-stack claim open rather than treating the benchmark as a final answer.
The document is marked as arXiv version 1, dated 26 August 2026. No funding source is reported in the document.
Paper data and sources
Original title: SlimTCP: It's fast, but not because it's slim
Authors: Mihai Drosi Caju, Costin Raiciu
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-26
DOI: Not available
Original paper · Full text