Post Sockets workshop in Zürich
I visited ETH Zürich on 13-14 February 2017, for a meeting to discuss evolution of Internet transport protocols and their programming interfaces. We considered what transport services existing protocols (e.g., TCP, UDP, SCTP, HTTP, etc.) offer, what interface they expose to applications programmers, and how the protocols and their API should change to support future needs. The goal was to make the design of our Post Sockets interface more concrete, taking input from the IETF TAPS working group, the EU H2020 NEAT project, and the experience of the workshop participants.
We're fortunate that there's a lot of complementary work happening in parallel to our Post Sockets design, that we can build upon. In the IETF, the TAPS working group has developed an excellent taxonomy of the features of existing transport protocols, and the NEAT project has a made an initial attempt to design a new transport API, with particular focus on the complex policy issues.
Based on this prior work, and the workshop discussions, the key concepts we consider in our Post Sockets API design are:
- Messages: we believe any future transport interface should be explicitly message oriented, rather than stream-based. TCP offers a stream API, but is unusual in this regard, and most transports, including those implemented over TCP, deliver messages - structured application data units - rather than byte streams. Accordingly, Post Sockets will offer a message abstraction by default, and handle TCP-like streams as a special case, rather than being oriented around streams.
- Associations: ephemeral connections are unusual - there's increasingly need to either resolve and discover the remote endpoint (e.g., to discover NAT bindings or to race IPv4 and IPv6 connections) or maintain cryptographic identity state between connections. Some form of long-lived association, that spans transport flows instances (e.g., TCP connections, UDP flows), seems essential.
- Asynchrony: we note that accepting incoming connections and packet reception are inherently asynchronous operations. The API should reflect this.
- Multiple paths: similarly, modern devices are increasingly multi-homed and can make use of multiple paths through the network (the common case might be a phone that can use 4G and Wi-Fi interfaces simultaneously). The transport API needs to expose this, partly to make good use of the available capacity across multiple interfaces, but also because different interfaces can have very different capabilities that might affect the choice of transport protocol. In part, this is features such as bandwidth, latency, and MTU, but it's also availability of ECN or DiffServ, differences in DNS resolution, or availability of underlying protocols such as IPv4 and IPv6.
Putting this together, an outcome of the meeting is that we design the Post Sockets API in terms of Message Carriers that use long-lived Associations to establish Transients (e.g., TCP connections) over Paths between Local and Remote end-points. This decomposes the parts of a Berkeley Socket, giving flexibility to support the needs of modern applications - with hopefully not too much additional complexity.
We also spent a lot of time discussing implementation of the protocol stack instances underlying the Post Sockets interface. In particular, we believe it important that the API expose strongly typed messages where possible, rather than byte arrays, so we must offer a way of pushing parsing and serialisation code into the protocol stack. We couple the transport protocol stack instance and the application more closely than is done in the Berkeley Sockets API, to gain insight into the application semantics, and the ability to manage message transmission, with appropriate reliability, priority, and deadlines. This suggests that the Post Sockets API is better suited to a high level language, like C++, Rust, Go, or Swift, than it is to a plain C interface.
I found the meeting extremely useful and productive, leading to a much better understanding of the design space for transport protocols and their interface. The result should be a greatly improved Post Sockets API specification for the coming IETF meeting in Chicago.
An alternative write-up of this meeting, written by Brian Trammell, is available on the MAMI project website.