Transport protocols in the age of In-Network Computing

Today’s Internet uses reliable and efficient end-to-end communication provided through transport protocols, such as TCP or QUIC.

The underlying end-to-end principle demands that hosts directly address each other while the network is kept simple and only forwards data without changing it. In practice, this principle is often violated by middleboxes (such as NATs or firewalls), as they, for example, rewrite or drop packets. Further, the recent emergence of In-Network Computing (INC) adds a new dimension to this issue as packet modifications are now encouraged.

In this context, the Internet Research Task Force (IRTF) Computing in the Network (COIN) Research Group stimulates research on how to use the benefits of INC while at the same time harmonizing its effects on the general Internet architecture.

One aspect of particular interest are challenges regarding the use of traditional transport protocols.

This post illustrates some of these challenges to raise awareness for potential changes that COIN can have on transport protocols.

Note that I’ve focused on INC in the sense of computations on networking hardware on the direct data path, while COIN generally also includes other concepts, such as edge computing.

In-Network Computing

INC generally refers to the idea of offloading computations from end-hosts (servers, PCs, smartphones, and so forth) onto networking devices such as switches and network interface cards.

The primary motivation is to use the unused computational capacities in the network and their (ideal) position on the direct data path to, for example, naturally reduce delays in collaborative computing scenarios.

Especially powered by the recent advent of programmable networking hardware (such as SmartNICs, P4-programmable switches, or FPGAs), many research approaches demonstrate the feasibility of INC in isolated settings.

What is it good for?

Natural fits for INC are traditional networking-related tasks, such as telemetry and load balancing. They have been shown to immensely profit from computations in the network, and they mostly keep changes to the packets to a minimum.

Other research, however, proposes more intrusive functionality, for example, performing extensive computations on the payload, or aggregating the information of several packets into a single one and dropping the others.

Consider the example shown in Figure 1. Instead of going the long way to the compute server first, the intermediate switch directly performs the required calculations and forwards the result to the receiver, thus reducing latencies and reaction times.

Yet, such radical approaches significantly violate the end-to-end principle and challenge our common understanding of how transport protocols operate.

In this context, we need to distinguish between reliable transport protocols, such as TCP, and unreliable ones, such as UDP.

Co-existence with unreliable transport

As an unreliable transport, UDP transmits datagrams in a best-effort manner without ensuring their successful transmission.

It is thus well-suited for INC as packets added in or changed/dropped by the network seamlessly fit into the existing semantics where the receiving entity must make sense of the received packets.

One major challenge that needs to be solved is how packets find their way to the INC functionality/node.

How to address INC devices?

The key aspect of the end-to-end principle is that communication is explicit and both participating entities are directly addressed.

Transferring this notion to INC, functionality in the network should also be addressed explicitly so that the end-hosts are aware of it. Consequently, pure end-to-end communication might no longer be suitable for INC.

Instead, the intent of the end-to-end principle could be extended to end-to-(intermediate-to-)*end communication with explicit addressing of the involved platforms, which could enable native multi-host communication schemes.

Trust relations in INC 

Other challenges are, for example, how changes made in the network can be authenticated or how INC could operate on encrypted traffic.

Addressing these challenges above all requires a trust architecture suitable for the inherent multi-host communication scenarios, so end-hosts can be made aware of ‘who’ made changes to the payload.

Can existing concepts such as public key infrastructures be used for this task, or do we need new concepts acknowledging the new diversity of communication? How can we validate that only the intended functions were executed and that the transmitted data was not used or moved elsewhere?

There are many open questions in this context, but even if they remain unanswered, unreliable transport mechanisms can conceptually still co-exist with INC in certain scenarios. Networks isolated from the Internet, for example, allow operators to carefully tune the overall communication schemes so that the in-network functionality is included in the application layer.

Mismatch with reliable transport

In contrast, there is an inherent conceptual mismatch between the goals of INC and the requirements of reliable transport protocols, such as TCP, which ensure that all transmitted segments are received and no changes have been made to them. They consequently require strict compliance with the end-to-end principle as any segments changed or added on the transmission path will be discarded.

Therefore, one question is whether INC scenarios require reliable transport mechanisms and, if yes, how changes made by the network can be incorporated into the reliability mechanisms.

Where to for INC and transport protocols?

In the current state of INC, there is a general mismatch between its goals and what is provided by today’s transport protocols. Consequently, INC solutions typically have to be carefully tailored to their deployment scenarios.

However, such an approach does not seem feasible for large-scale deployment scenarios.

Further advances in INC will thus have to account for these mismatches with transport protocols.

They might even choose to systematically depart from the traditional end-to-end principle, potentially enabling true multi-host communication schemes.

Ike Kunze is a PhD student at the Chair of Communication and Distributed Systems at RWTH Aachen University in Germany.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.