Ouroboros multicast conjecture: Difference between revisions
(→Origin) |
|||
Line 23: | Line 23: | ||
== Examples == | == Examples == | ||
IP and Ethernet networks specify multicast/broadcast using a separation in the address space | IP and Ethernet networks specify multicast/broadcast using a separation in the address space. |
Revision as of 11:53, 10 October 2023
The Ouroboros multicast conjecture (apologies, but we had to give it some name) states that unicast is not equal to 1:1 multicast. Similarly, it is not possible to make unicast or multicast/broadcast transparent to the entity that directly engages in the unicast or multicast communication. Or, in yet another way, it is not possible to have a single API for multicast and unicast.
This seems like a rather trivial fact, but we didn't find this stated explicitly in literature.
The current formulation is rather intuitive, it would be interesting to have an adequate precise description of this conjecture, preferably with a formal proof.
Origin
We came to this conjecture when starting to implement multicast in the prototype, starting from the whatevercast concept proposed in RINA. During the implementation, it became clear that to implement it, we were re-implementing a lot of concepts that were already present for unicast layers, most particularly enrollment and the code for disseminating link-state routing packets. It also became clear that we could not devise an API that somehow was oblivious to the destination being a single node or a (dynamic) group of nodes, in other words: there is a distinction between 1:1 multicast and unicast. Intuitively, when starting a unicast flow, there is no way to add new nodes to that conversation; it has to start as a different kind of flow with certain limitations on authentication, encryption and QoS characteristics.
This led us to conclude that multicast is actually a process that consists of two phases:
- The creation of a network (and nodes can join and leave at will)
- Broadcasting the packets on that network
We call this network a "broadcast Layer".
So, given that insight, we had the option to either
- use different functions towards unicast and multicast
- use the same function, but make a distinction between unicast and multicast names
We opted for the latter, but in any case, the application "knew" whether it was doing multicast or unicast when it was using the API.
Examples
IP and Ethernet networks specify multicast/broadcast using a separation in the address space.