A new model should demonstrate new capabilities instead of just existing ones.
Of course, we understand the sentiment, and we are convinced the Ouroboros architecture 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 the critical components fully implemented to demonstrate such advanced features, let alone evaluate them to existing technology.
At this point, we are more concerned to craft a solid basic understanding of the fundamental principled underlying networks. What the minimal conditions are that make or break certain network functionalities. The current model (OSI / TCP layers) just doesn't cut it. It has little predictive value about what the consequences are going against the 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 best: *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?
We need to make a distinction here. The claim which we are making is that the process that is doing either multicast or unicast needs to be aware that it is doing so. In the example given, the application uses IPv6, and IPv6 is doing multicast until MAC learning occurs. It is not the application that is using IPv6 that is a multicast application. The IPv6 protocol
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?