From c154e3eaedc81a31c266894bd781d70751818201 Mon Sep 17 00:00:00 2001 From: Dimitri Staessens Date: Sat, 2 May 2020 12:07:14 +0200 Subject: content: Removed Faq section --- content/en/docs/Faq/_index.md | 124 ------------------------------------------ 1 file changed, 124 deletions(-) delete mode 100644 content/en/docs/Faq/_index.md (limited to 'content/en/docs') diff --git a/content/en/docs/Faq/_index.md b/content/en/docs/Faq/_index.md deleted file mode 100644 index f5599e3..0000000 --- a/content/en/docs/Faq/_index.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -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)\ - -### What is Ouroboros? - -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)] - -### Is Ouroboros the same as the Recursive InterNetwork Architecture (RINA)? - -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)] - -### How can I use Ouroboros right now? - -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)] - -### What are the benefits of Ouroboros? - -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)] - -### How do you manage the namespaces? - -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. -- cgit v1.2.3