1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
---
title: "FAQ"
date: 2019-06-22
draft: false
description: >
Frequently Asked Questions.
weight: 85
---
Got a question that is not listed here? Just pop it on our IRC channel
or mailing list and we will be happy to answer it!
[What is Ouroboros?](#what)\
[Is Ouroboros the same as the Recursive InterNetwork Architecture
(RINA)?](#rina)\
[How can I use Ouroboros right now?](#deploy)\
[What are the benefits of Ouroboros?](#benefits)\
[How do you manage the namespaces?](#namespaces)\
### <a name="what">What is Ouroboros?</a>
Ouroboros is a packet-based IPC mechanism. It allows programs to
communicate by sending messages, and provides a very simple API to do
so. At its core, it's an implementation of a recursive network
architecture. It can run next to, or over, common network technologies
such as Ethernet and IP.
[[back to top](#top)]
### <a name="rina">Is Ouroboros the same as the Recursive InterNetwork Architecture (RINA)?</a>
No. Ouroboros is a recursive network, and is born as part of our
research into RINA networks. Without the pioneering work of John Day and
others on RINA, Ouroboros would not exist. We consider the RINA model an
elegant way to think about distributed applications and networks.
However, there are major architectural differences between Ouroboros and
RINA. The most important difference is the location of the "transport
functions" which are related to connection management, such as
fragmentation, packet ordering and automated repeat request (ARQ). RINA
places these functions in special applications called IPCPs that form
layers known as Distributed IPC Facilities (DIFs) as part of a protocol
called EFCP. This allows a RINA DIF to provide an *IPC service* to the
layer on top.
Ouroboros has those functions in *every* application. The benefit of
this approach is that it is possible to multi-home applications in
different networks, and still have a reliable connection. It is also
more resilient since every connection is - at least in theory -
recoverable unless the application itself crashes. So, Ouroboros IPCPs
form a layer that only provides *IPC resources*. The application does
its connection management, which is implemented in the Ouroboros
library. This architectural difference impact the components and
protocols that underly the network, which are all different from RINA.
This change has a major impact on other components and protocols. We are
preparing a research paper on Ouroboros that will contain all these
details and more.
[[back to top](#top)]
### <a name="deploy">How can I use Ouroboros right now?</a>
At this point, Ouroboros is a useable prototype. You can use it to build
small deployments for personal use. There is no global Ouroboros network
yet.
[[back to top](#top)]
### <a name="benefits">What are the benefits of Ouroboros?</a>
We get this question a lot, and there is no single simple answer to
it. Its benefits are those of a RINA network and more. In general, if
two systems provide the same service, simpler systems tend to be the
more robust and reliable ones. This is why we designed Ouroboros the
way we did. It has a bunch of small improvements over current networks
which may not look like anything game-changing by themselves, but do
add up. The reaction we usually get when demonstrating Ouroboros, is
that it makes everything really really easy.
Some benefits are improved anonymity as we do not send source addresses
in our data transfer packets. This also prevents all kinds of swerve and
amplification attacks. The packet structures are not fixed (as the
number of layers is not fixed), so there is no fast way to decode a
packet when captured "raw" on the wire. It also makes Deep Packet
Inspection harder to do. By attaching names to data transfer components
(so there can be multiple of these to form an "address"), we can
significantly reduce routing table sizes.
The API is very simple and universal, so we can run applications as
close to the hardware as possible to reduce latency. Currently it
requires quite some work from the application programmer to create
programs that run directly over Ethernet or over UDP or over TCP. With
the Ouroboros API, the application doesn't need to be changed. Even if
somebody comes up with a different transmission technology, the
application will never need to be modified to run over it.
Ouroboros also makes it easy to run different instances of the same
application on the same server and load-balance them. In IP networks
this requires at least some NAT trickery (since each application is tied
to an interface:port). For instance, it takes no effort at all to run
three different webserver implementations and load-balance flows between
them for resiliency and seamless attack mitigation.
The architecture still needs to be evaluated at scale. Ultimately, the
only way to get the numbers, are to get a large (pre-)production
deployment with real users.
[[back to top](#top)]
### <a name="namespaces">How do you manage the namespaces?</a>
Ouroboros uses names that are attached to programs and processes. The
layer API always uses hashes and the network maps hashes to addresses
for location. This function is similar to a DNS lookup. The current
implementation uses a DHT for that function in the ipcp-normal (the
ipcp-udp uses a DynDNS server, the eth-llc and eth-dix use a local
database with broadcast queries).
But this leaves the question how we assign names. Currently this is
ad-hoc, but eventually we will need an organized way for a global
namespace so that application names are unique. If we want to avoid a
central authority like ICANN, a distributed ledger would be a viable
technology to implement this, similar to, for instance, namecoin.
|
