diff options
| -rw-r--r-- | content/en/docs/Overview/_index.md | 94 |
1 files changed, 53 insertions, 41 deletions
diff --git a/content/en/docs/Overview/_index.md b/content/en/docs/Overview/_index.md index 9fd9970..9e648b0 100644 --- a/content/en/docs/Overview/_index.md +++ b/content/en/docs/Overview/_index.md @@ -9,72 +9,84 @@ description: > 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. +networking model -- from the programming API almost to the wire -- +without compromises. While the prototype not directly compatible with +IP or sockets, it has some interfaces to be interoperable with common +technologies: we run Ouroboros over Ethernet or UDP, or create +IP/Ethernet tunnels over Ouroboros by exposing tap or tun devices. -From an application perspective, Ouroboros network operates as a "black -box" with a -[very simple interface](https://ouroboros.rocks/man/man3/flow_alloc.3.html). -Either it provides a _flow_, a bidirectional channel that delivers data -within some requested operational parameters such as delay and +From an application perspective, an Ouroboros network is a "black box" +with a +[simple interface](https://ouroboros.rocks/man/man3/flow_alloc.3.html). +Either Ouroboros will 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. +channel to a set of joined programmes. 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](https://ouroboros.rocks/man/man8/ouroboros.8.html). -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: +Some of the main characteristics are: -* Ouroboros is minimal: it only sends what it needs to send to operate. +* Ouroboros is <b>minimalistic</b>: it has only the essential protocol + fields. It will also try to use the lowest possible network layer + (i.e. on a single machine, Ouroboros communicates directly over + shared memory, over a LAN it will communicate over Ethernet, over IP + it will communicate over UDP), in a completely transparent way to + the application. -* 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](/docs/concepts/protocols/). +* Ouroboros enforces the _end-to-end_ principle. Packet headers are + <b>immutable</b> between the 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](/docs/concepts/protocols/). This immutability can be enforced + through authentication (not yet implemented). + +* The Ouroboros end-to-end protocol performs flow control, error + control and reliable transfer and is implemented as part of the + _application library_. This includes sequence numbering, ordering, + sending and handling acknowledgments, managing flow control windows, ... * 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 + performs an ECDHE key exchange. The end-to-end protocol is based on + Delta-t and [doesn't need a handshake](/docs/concepts/protocols/#operation-of-frcp). -* 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. +* Ouroboros allows encrypting everything before handing it to the next + 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 implemented. Unlike TLS, the end-to-end header (sequence number + etc) can be fully encrypted. + +* Ouroboros congestion control operates at the network level. It does + not (_can not!_) rely on acknowledgements. This means all network + flows are automatically congestion controlled. * 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_. + is offered. This allows the layer to implement shaping 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](https://arxiv.org/pdf/2001.09707.pdf). 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](https://archive.fosdem.org/2018/schedule/event/ipc/) (it's over -two years old, so not entirely up-to-date anymore), and have a quick -read of the [flow allocation](/docs/concepts/fa/) and [data -path](/docs/concepts/datapath/) sections. +presentation at +[FOSDEM 2018](https://archive.fosdem.org/2018/schedule/event/ipc/) +but note that this presentation is over three years old, and +very outdated in terms of what has been implemented. +The next things to do are to have a quick read of the +[flow allocation](/docs/concepts/fa/) +and +[data path](/docs/concepts/datapath/) +sections. {{< youtube 6fH23l45984 >}} |