aboutsummaryrefslogtreecommitdiff
path: root/content/en/docs
diff options
context:
space:
mode:
authorDimitri Staessens <dimitri@ouroboros.rocks>2021-02-07 16:30:13 +0100
committerDimitri Staessens <dimitri@ouroboros.rocks>2021-02-07 16:30:13 +0100
commit0eb0cb15342a54e36acfe4bd7f871760fab6c4b7 (patch)
tree53b55c97b7efbf042a5a6b6c704c1246047de186 /content/en/docs
parentea0d393eece95a66a0fd52063b0172cd62bf1c97 (diff)
downloadwebsite-0eb0cb15342a54e36acfe4bd7f871760fab6c4b7.tar.gz
website-0eb0cb15342a54e36acfe4bd7f871760fab6c4b7.zip
content: Update Overview page
Diffstat (limited to 'content/en/docs')
-rw-r--r--content/en/docs/Overview/_index.md94
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 >}}