Ouroboros multicast conjecture: Difference between revisions

From Ouroboros
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
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 Ouroboros multicast conjecture (apologies, but we had to give it some name) states that it's not possible to see unicast as (non-distinct) 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 similarly, it is not possible to unknowingly 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.
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.
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 __a set of rules to resolve the destination addresses__.
We came to this conjecture when starting to implement multicast in the prototype, starting from the [[Glossary#Whatevercast|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 opaque to the destination being a (dynamic) group of nodes, in other words: there is a distinction between 1:1 multicast and unicast. As an intuitive example: when starting with the setup of a unicast connection, there is no way to add new nodes to that conversation.


So, basically the proposed API is allocate(whatevercastname) and the network will resolve things for you.
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


Now, this 'set of rules to resolve the destination' wipes a lot under the rug.
We call this network a "broadcast Layer".


== Discussion ==
So, given that insight, we had the option to either
Why n:m multicast where n=m=1 is not unicast.
# 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, more particularly

Revision as of 11:44, 10 October 2023

The Ouroboros multicast conjecture (apologies, but we had to give it some name) states that it's not possible to see unicast as (non-distinct) 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 similarly, it is not possible to unknowingly 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

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 opaque to the destination being a (dynamic) group of nodes, in other words: there is a distinction between 1:1 multicast and unicast. As an intuitive example: when starting with the setup of a unicast connection, there is no way to add new nodes to that conversation.

This led us to conclude that multicast is actually a process that consists of two phases:

  1. The creation of a network (and nodes can join and leave at will)
  2. Broadcasting the packets on that network

We call this network a "broadcast Layer".

So, given that insight, we had the option to either

  1. use different functions towards unicast and multicast
  2. 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, more particularly