Ouroboros Frequently Asked Questions

General Remarks

A new model should demonstrate new capabilities instead of just existing ones.

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.

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.

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.

Paper Remarks

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. The claim which we are making is that there is no single abstraction that unifies multicast with unicast.

For the Ethernet/ARP,

In the case of MAC learning, IPv6 doesn't expose this multicast operation to the application. Ethernet itself doesn't even reveal this to IPv6. As far as IPv6 is concerned, Ethernet is doing unicast, only in a very inefficient way (sending to all, and dropping at all but one). This is just a hidden implementation aspect of IP and has little to do with our claim.