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:

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.