Paper: Presto: A Match-Action TCP Stack for the Terabit Era
Authors: Rajath Shashidhara, Antoine Kaufmann, Simon Peter
Presenter: Yunxin Xu, Xiamen University
Guest of Honor: Rajath Shashidhara, Google
Q：Presto does not buffer all out-of-order packets in the switch. Instead, it uses O1 and O2 to track one or two out-of-order intervals. In a real deployment, if the degree of packet reordering increases significantly, what criteria should be used to choose the number of out-of-order intervals?
A：The number of pipeline stages in an RMT pipeline is limited, and each additional out-of-order interval consumes more pipeline resources, roughly two more state stages. At the same time, you can measure the marginal performance benefit of adding another out-of-order interval, for example by measuring the improvement in flow completion time. Therefore, the choice is a trade-off between resource consumption and the performance gain provided by additional out-of-order intervals. You can measure both and choose the optimal point.
Q：So in a real deployment, does Presto require empirical measurement before being deployed in the actual system?
A：Yes. Some empirical measurement is useful for choosing the appropriate configuration. The simulations in the paper already use real data-center workloads and traces, such as DCTCP-related traces, so some of the design has been evaluated using realistic access patterns. However, simulation still has limitations, so ideally the configuration should also be validated in the real deployment environment.
Q：Why did you choose a Tofino switch as the prototype platform? Are there any commercial RMT-based SmartNICs available?
A：There are commercial RMT-based SmartNICs, such as the Pensando SmartNIC. However, those platforms are generally not readily available for academic research. Other programmable NICs, such as NVIDIA BlueField or Netronome NICs, may support P4-like programming, but internally they often use general-purpose or RISC cores rather than a true RMT pipeline. Because their underlying hardware is much more capable and general-purpose, they do not demonstrate the same energy-efficiency characteristics as a real RMT pipeline. Tofino was therefore the most practical platform available for demonstrating the RMT-based design.
Q：Can this approach be used in today’s AI data centers? If so, what would be the main challenges or opportunities?
A：There are multiple possible use cases. One is the front-end network of an AI data center, where accelerators communicate with one another. Another is the back-end network connecting the AI cluster to storage services or other data centers, where TCP compatibility may still be required.
The techniques in Presto are not specific to TCP. They could potentially be applied to RDMA or other interconnect protocols used inside AI data centers. AI workloads are typically bandwidth-intensive, use relatively few connections with large payloads, and often have predictable communication patterns. Techniques such as multipathing and packet spraying could map naturally to Presto’s out-of-order interval abstraction. For example, if there are multiple paths, different out-of-order intervals could be used to track packets arriving through different paths.
Scale-up networks may also face packet loss, reordering, and congestion as they become larger. Presto’s core techniques for high-rate reassembly and retransmission could potentially be used for memory-semantic operations or memory transactions in these environments. The authors have not evaluated these use cases yet, but they appear promising.
Q：Would a message-based version of Presto be particularly useful in AI data centers?
A：Yes. A message-based version of Presto could potentially be useful in AI data-center environments, especially for communication patterns that are naturally message-oriented rather than traditional byte-stream TCP communication.
Q：What is the difference between Presto and FlexTO? Their overall design directions seem quite similar.
A：FlexTO does not fully decompose the core transport logic. In FlexTO, there is still a protocol module that contains the main TCP protocol code, and that module is protected by locks. Presto goes further by parallelizing the core TCP transport logic itself across different pipeline stages.
Therefore, while the overall goals of Presto and FlexTO are similar, the main contribution of Presto is the decomposition and parallelization of transport-protocol logic within the match-action pipeline.
Q：Is there any opportunity for co-design between Presto and FlexTO?
A：Yes. There are many possible co-design opportunities. For example, the core transport logic could remain on the RMT pipeline, while more flexible transport functions run on the SmartNIC. The SmartNIC could handle functions such as encryption, compression, RPC processing, load balancing across CPU cores, or even application offload. Because SmartNICs are more flexible than an RMT pipeline, they can execute functionality that would be difficult or impossible to place directly in the RMT data path.
Q：If server migration, failover, or load-balancing changes the network path, the new RMT device on the path may not contain the original TCP connection state. How should Presto handle this situation?
A：Presto is not proposing that the TCP stack should necessarily be placed on a network switch. The switch was used because it was the most practical RMT implementation platform available to the authors. The main contribution is demonstrating how TCP can be implemented on an RMT pipeline.
If an end-host RMT platform such as a suitable Pensando device were available, Presto could instead be deployed at the end host, which would avoid this particular problem.
It would also be possible to design migration or recovery protocols to transfer or reconstruct the state when paths change, but this is outside the scope of the paper.
Q：The evaluation shows that tracking only one out-of-order interval already captures most of the benefit. In a real deployment with multipathing or more severe packet reordering, how should reassembly fidelity be chosen? Could it be adapted per flow, or must the pipeline reserve a fixed number of intervals for every connection?
A：Different flows could use different levels of reassembly fidelity. You could build multiple RMT pipelines or pipeline configurations, with one providing low reassembly fidelity and another providing higher fidelity, and place a classifier in front of them to determine which flows require which level of reassembly.
For example, on an FPGA, multiple P4 pipelines could be implemented. One pipeline could provide low reassembly fidelity, while another provides higher fidelity. The appropriate number of out-of-order intervals can be determined empirically based on the data-center workload, balancing hardware resource consumption against performance improvement.
Q：So different workloads could use different pipeline configurations even if the reassembly fidelity is not changed dynamically for each individual flow?
A：Yes. Different workload classes can be mapped to different pipeline configurations or different levels of reassembly fidelity, even if the configuration itself is not dynamically changed for every flow.
Q：In a multi-tenant environment, different tenants may compete for connection state and other resources. How does Presto provide resource fairness and isolation among tenants?
A：The amount of state Presto uses inside the RMT pipeline is relatively small, so a large number of connections can be supported. The paper shows that even with around 32,000 connections, there is no significant performance degradation because state access is implemented using fixed-size array indexing.
DMA bandwidth is a separate issue. In the prototype, each application opens its own DMA channel to the data path. A DMA channel corresponds to one or more RDMA queue pairs to the switch. Therefore, Presto inherits the isolation and fairness guarantees provided by the RDMA NIC across different queue pairs.
In the evaluation, the server had 256 CPU cores and used 256 different queue pairs. The authors did not observe significant performance differences in this configuration. However, explicitly designing new mechanisms for DMA fairness across tenants was outside the scope of Presto.
Q：If a long flow and a short flow share the same queue pair, RDMA can suffer from head-of-line blocking. Could a similar head-of-line blocking problem occur in Presto?
A：Not for the same reason. RDMA head-of-line blocking is largely related to its loss-recovery behavior and mechanisms such as PFC. In Presto, loss recovery and retransmission are handled independently for each connection inside the data path. Therefore, different transport connections are independent from the perspective of Presto’s recovery mechanism.
RDMA is only used to transfer data between the CPU and the Presto data path in the prototype, rather than providing the transport semantics between end hosts.
Q：Looking at the evolution from user-space TCP stacks, kernel optimizations, and more recent hardware offloading and hardware-software co-design approaches, what do you think will be the next direction for high-performance network stacks?
A：Hardware offloading, or at least some form of hardware-software co-design, is almost inevitable. Network data rates are increasing very quickly, while CPU performance is no longer scaling at the same rate. Therefore, purely software-based approaches are unlikely to scale indefinitely.
At the same time, regular data-center networks still benefit from software flexibility because policies, protocols, and extensions need to evolve. Therefore, the likely direction is not complete hardware implementation, but a balance between hardware acceleration and software programmability. Both Presto and FlexTO explore this balance in different ways.
Q：What do you think is the best abstraction for hardware-software co-design of network stacks, considering platforms such as FPGAs, ASICs, RMT pipelines, and NPUs?
A：There probably will not be a single hardware platform that is optimal for everything. A hybrid architecture is more likely.
For example, NPU-like or CPU-like cores can provide software flexibility and execute more complicated offloaded functions or application logic. Core transport functionality, on the other hand, could run on an RMT pipeline or specialized FPGA logic to achieve very high packet-processing rates and better energy efficiency.
Therefore, the future architecture will likely combine multiple kinds of hardware rather than rely on a single platform.
Q：For a specific hardware platform, how can we find the right abstraction between software and hardware so that software does not need to understand the hardware details?
A：There are at least two possible approaches.
One approach is to build a cross-platform compiler that takes software code and translates it to different hardware accelerator architectures.
Another approach is to define a hardware abstraction language or programming language in which developers express the functionality they want, while the compiler maps that functionality onto the underlying hardware.
Both approaches are valuable. The accelerator landscape is evolving rapidly, so an abstraction that works well today may need to adapt as new hardware platforms appear.
Q：For new graduate students, what is the best way to get started in this area?
A：A hands-on approach is very useful. If possible, get access to a few hardware accelerator platforms and experiment with them. Try running open-source implementations, become familiar with the programming environment, and study existing papers to understand the software design principles used to make these platforms efficient.
Reading papers is useful, but combining reading with hands-on experience with real hardware or open-source systems is an even better starting point.