Ouroboros multicast conjecture: Difference between revisions
No edit summary |
(→Origin) |
||
| Line 5: | Line 5: | ||
== Origin == | == Origin == | ||
The RINA specifications have a rather interesting concept called [[Glossary#Whatevercast|whatevercast]], which claimed to be a single API for both unicast and multicast. The observation made is that communication is n:m and unicast is just the case where n=m=1. A 'whatevercast name' which is a destination associated with | The RINA specifications have a rather interesting concept called [[Glossary#Whatevercast|whatevercast]], which claimed to be a single API for both unicast and multicast. The observation made is that communication is n:m and unicast is just the case where n=m=1. A 'whatevercast name' which is a destination associated with _a set of rules to resolve the destination addresses_. | ||
So, basically the proposed API is allocate(whatevercastname) and the network will resolve things for you. | So, basically the proposed API is allocate(whatevercastname) and the network will resolve things for you. | ||
Now, this 'set of rules to resolve the destination' wipes a lot under the rug. | Now, this 'set of rules to resolve the destination' wipes a lot under the rug. | ||
== Discussion == | == Discussion == | ||
Why n:m multicast where n=m=1 is not unicast. | Why n:m multicast where n=m=1 is not unicast. | ||
Revision as of 10:55, 10 October 2023
The Ouroboros multicast conjecture (apologies, but we had to give it some name) states that it's not possible to make unicast or multicast/broadcast transparent to the entity that directly engages in the unicast or multicast communication. Or similarly, it is not possible to engage in multicast and unicast with the same API.
The current formulation is rather intuitive, it would be interesting to have an adequate precise description of this (seemingly trivial) conjecture, preferably with a formal proof.
Origin
The RINA specifications have a rather interesting concept called whatevercast, which claimed to be a single API for both unicast and multicast. The observation made is that communication is n:m and unicast is just the case where n=m=1. A 'whatevercast name' which is a destination associated with _a set of rules to resolve the destination addresses_.
So, basically the proposed API is allocate(whatevercastname) and the network will resolve things for you.
Now, this 'set of rules to resolve the destination' wipes a lot under the rug.
Discussion
Why n:m multicast where n=m=1 is not unicast.