Ouroboros Frequently Asked Questions: Difference between revisions

From Ouroboros
Jump to navigation Jump to search
No edit summary
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= General Remarks =
Ouroboros is a project with the capacity to make fundamental changes to the way we share information in the digital world. When encountering this project for the first time, plenty of people have questions: what it is, how it works, and how it compares to other projects. This is where you'll find the answers to some of the most common questions.


=== A new model should demonstrate new capabilities instead of just existing ones. ===
== Q: How does Ouroboros compare to [Tor, CJDNS, I2P, Wireguard, etc.]? ==
The goal of Ouroboros is to tackle problems in the world of information transfer by re-establishing network architecture at a system level.


Of course, we understand the sentiment, and we are convinced the Ouroboros prototype will prove to have some exciting capabilities, such as hot-swapping a complete underlying network without breaking an end-to-end application connection. But that is not our primary objective -- yet. As of now, we don't have enough critical components fully implemented to demonstrate such advanced features, let alone evaluate them copared to currrnt technology.
As such, comparing Ouroboros to projects which rely on existing network architecture (IP/TCP, TLS, DNS) is akin to comparing a concrete foundation to a pre-existing structure. It is possible to move these structures onto the foundation (or build new ones!), but it is ineffective to compare Ouroboros to any existent networking protocol before any practical implementations have been built.


At this point, we are more concerned with building a solid basic understanding of the fundamental principles underlying networks. Finding the minimal conditions that make or break certain network functionalities. The current model (OSI / TCP layering) has little predictive value about what the consequences are going against the 5/7 layers, and the current Internet does not neatly consist of 5 or 7 layers.
Until implementations exist which properly leverage the capacity of Ouroboros as an infrastructure, it is difficult to make a comparison to the specific use cases addressed by existing network paradigms.


The model we are developing should first explain _why_ the networks that we already have actually work. The Ouroboros model has a different conceptual view, different basic building blocks, put together in a conceptually different way. This is a bit orthogonal to the work carried out by engineers building features. Erwin Schrodinger put it as follows: ''The task is ... not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees.''
== Q: Why are you using C instead of rust / golang / zig / ... ==
Our previous experience was building a RINA stack in C in Linux kernel space (IRATI), so we had a few years of experience developing in a spartan C environment. Since the Ouroboros project was initially targeting a user-space RINA stack that should be portable to constraint IoT devices, we hoped to leverage some of the work/code from IRATI. When we started early in 2016, rust was not really a thing, definitely not on small COTS IoT boards. Today we may or may not choose something else, but even in rust, the nature of what we are designing will require a lot of unsafe code.


= Paper Remarks =
== Q: Do you guys think you can replace TCP/IP? ==
 
No-one can replace TCP/IP. We think the TCP/IP stack is - from a modern day perspective - incredibly rickety. All we can do is take what we learned over the past 25 years and try to come to a better integrated solution for secure and reliable end-to-end packet networking. We have no control over technology adoption, all we can do is provide a possible path for it. Ouroboros runs fine as an overlay on top of TCP/IP. There is no need to throw out your routers and switches. Replacing TCP/IP is not up to us, it's completely up to you.
=== Ouroboros claims Unicast and Multicast must be distinct mechanisms. However, these mechanisms interact seamlessly for existing protocols such as IP/ARP and IPv6 (where, in particular, IPv6 packets are transmitted as Ethernet multicast until MAC learning occurs). Isn't this contradictory? ===
 
It's not because they are distinct mechanisms, that they can't interact seamlessly. In the case of Ethernet MAC learning, IPv6 doesn't expose this multicast operation to the application. Ethernet itself doesn't even reveal this to IPv6. On the one hand, as far as IPv6 is concerned, Ethernet is always sending that packet in unicast, but before MAC learning, Ethernet is doing it in a very inefficient way (sending to all, and dropping at all but one). This is just a hidden implementation aspect of IPv6/Ethernet. On the other hand, some parts of IPv6 multicast will leverage Ethernet broadcast, but that is a known intentional optimization of which the IPv6 implementation is aware.
 
The claim which we are making is that there is no single abstraction that unifies multicast with unicast from the point of view of the process that sends the packets. Multicast and unicast are not transparently interchangeable. Taking an arbitrary unicast program and swapping out unicast for multicast or vice-versa will in almost all cases break that program. It should not be a controversial statement: the proof is pretty straightforward: try to run TCP on top of IP multicast: it won't work because its acknowledgement mechanism depends on one-to-one communication.
 
Giving things with very different semantics (unicast and multicast) a similar syntax, like Ethernet and IP multicast try to do with a "broadcast address", is just a bad idea that causes more problems (and confusion) than it solves. Ouroboros states that a broadcast address is equivalent to a "layer name", and the construction of "multicast groups" is equivalent to adding nodes to a layer and is governed by the layer management primitives, which are common to both unicast and broadcast layers.
 
=== Ouroboros seems to ignore how names are used to distinguish multicast/unicast without applications ever knowing (sometimes via name aliases, e.g., DNS) ===
 
 
=== Some physical layers natively support multicast and some protocols rely on that very feature, how is this accounted for in Ouroboros? ===
 
 
=== The definitions in the paper only mention link weights, what about node weights and weights that are not just a scalar value? ===
 
 
=== The authors seem to claim that forwarding is a single hop in a routing table, but it’s the *process* of relaying packets to the next hop that involves selecting ONE of those hops; it isn’t just the set of possible hops ===
 
=== The authors seem to claim that the opposite of flat names are hierarchical names. Non-flat names can have many structures, only one of which is hierarchical, e.g., hypercube names are not hierarchical but are structured and routable based on name content. How do you account for this? ===
 
 
=== Can the “forwarding layer” can manage congestion control (instead of the protocol performing flow control)? ===
 
=== TCP over TCP is known to perform very badly unless the impact of operating retransmission, reordering, flow control, and congestion control at different layers on top of each other is carefully managed. How will Ouroboros overcome this? ===

Latest revision as of 20:29, 12 August 2024

Ouroboros is a project with the capacity to make fundamental changes to the way we share information in the digital world. When encountering this project for the first time, plenty of people have questions: what it is, how it works, and how it compares to other projects. This is where you'll find the answers to some of the most common questions.

Q: How does Ouroboros compare to [Tor, CJDNS, I2P, Wireguard, etc.]?

The goal of Ouroboros is to tackle problems in the world of information transfer by re-establishing network architecture at a system level.

As such, comparing Ouroboros to projects which rely on existing network architecture (IP/TCP, TLS, DNS) is akin to comparing a concrete foundation to a pre-existing structure. It is possible to move these structures onto the foundation (or build new ones!), but it is ineffective to compare Ouroboros to any existent networking protocol before any practical implementations have been built.

Until implementations exist which properly leverage the capacity of Ouroboros as an infrastructure, it is difficult to make a comparison to the specific use cases addressed by existing network paradigms.

Q: Why are you using C instead of rust / golang / zig / ...

Our previous experience was building a RINA stack in C in Linux kernel space (IRATI), so we had a few years of experience developing in a spartan C environment. Since the Ouroboros project was initially targeting a user-space RINA stack that should be portable to constraint IoT devices, we hoped to leverage some of the work/code from IRATI. When we started early in 2016, rust was not really a thing, definitely not on small COTS IoT boards. Today we may or may not choose something else, but even in rust, the nature of what we are designing will require a lot of unsafe code.

Q: Do you guys think you can replace TCP/IP?

No-one can replace TCP/IP. We think the TCP/IP stack is - from a modern day perspective - incredibly rickety. All we can do is take what we learned over the past 25 years and try to come to a better integrated solution for secure and reliable end-to-end packet networking. We have no control over technology adoption, all we can do is provide a possible path for it. Ouroboros runs fine as an overlay on top of TCP/IP. There is no need to throw out your routers and switches. Replacing TCP/IP is not up to us, it's completely up to you.

Retrieved from "https://ouroboros.rocks/mediawiki/index.php?title=Ouroboros_Frequently_Asked_Questions&oldid=1688"