A bird’s eye view of Ouroboros.

Ouroboros is a prototype distributed system for packetized network communications. It is a redesign ab initio of the current packet networking model – from the programming API (“Layer 7”) almost to the wire (“Layer 1”) – without compromises. This means it’s not directly compatible with anything currently available. It can’t simply be “plugged into” the current network stack. Instead it has some interfaces into inter-operate with common technologies: run Ouroboros over Ethernet or UDP, or create tunnels over Ouroboros using tap or tun devices.

From an application perspective, Ouroboros network operates as a “black box” with a very simple interface. Either it provides a flow, a bidirectional channel that delivers data within some requested operational parameters such as delay and bandwidth and reliability and security; or it provides a broadcast channel.

From an administrative perspective, an Ouroboros network is a bunch of daemons that can be thought of as software routers (unicast) or software hubs (broadcast) that can be connected to each other; again through a simple API. Each daemon has an address, and they forward packets among each other. The daemons also implement their own internal name-to-address resolution.

Some of the main features are:

  • Ouroboros is minimal: it only sends what it needs to send to operate.

  • Ouroboros adheres to the end-to-end principle. Packet headers are immutable between the program components (state machines) that operate on their state. Only two protocol fields change on a hop-by-hop (as viewed within a network layer) basis: TTL and ECN.

  • Ouroboros can establish an encrypted flow in a single RTT (not including name-to-address resolution). The flow allocation API is a 2-way handshake (request-response) that agrees on endpoint IDs and performs an ECDHE key exchange. The end-to-end protocol doesn’t need a handshake.

  • The Ouroboros end-to-end protocol performs flow control, error control and reliable transfer and is implemented as part of the application library. Sequence numbers, acknowledgments, flow control windows… The last thing the application does (or should do) is encrypt everything before it hands it to the network layer for delivery. With this functionality in the library, it’s easy to force encryption on every flow that is created from your machine over Ouroboros regardless of what the application programmer has requested. Unlike TLS, the end-to-end header (sequence number etc) is fully encrypted.

  • The flow allocation API works as an interface to the network. An Ouroboros network layer is therefore “aware” of all traffic that it is offered. This allows the layer to shape and police traffic, but only based on quantity and QoS, not on the contents of the packets, to ensure net neutrality.

For a lot more depth, our article on the design of Ouroboros is accessible on arXiv.

The best place to start understanding a bit what Ouroboros aims to do and how it differs from other packet networks is to first watch this presentation at FOSDEM 2018 (it’s over two years old, so not entirely up-to-date anymore), and have a quick read of the flow allocation and data path sections.

Last modified October 21, 2019