Ouroboros multicast conjecture: Difference between revisions
(→Origin) |
(→Notes) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The Ouroboros multicast conjecture | 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/broadcast communication. Or, in yet another formulation, it is not possible to have a single transparent API for multicast/broadcast and unicast. | ||
This seems like a rather trivial fact, but we didn't find this stated explicitly in literature. | This seems like a rather trivial fact, but we didn't find this stated explicitly in literature. | ||
| Line 7: | Line 7: | ||
== Origin == | == Origin == | ||
We came to this conjecture when starting to implement multicast in the prototype, starting from the [[Glossary#Whatevercast|whatevercast]] concept proposed in RINA. During | We came to this conjecture when starting to implement multicast in the prototype, starting from the [[Glossary#Whatevercast|whatevercast]] concept proposed in RINA. During this implementation work, it became clear that to implement multicast, we were re-implementing a lot of code that were already present for unicast layers, most particularly enrollment and the dissemination of link-state routing packets to all IPCPs in the Layer. It also became clear that we could not devise an API that somehow was oblivious to the destination being a single unicast 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: | 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) | # The creation of a network Layer (and nodes can join and leave at will) | ||
# Broadcasting the packets on that network | # Broadcasting the packets on that network Layer | ||
We call this network a ''Broadcast Layer''. | We call this network a ''Broadcast Layer''. | ||
| Line 18: | Line 18: | ||
# use different function calls towards unicast and multicast, or | # use different function calls towards unicast and multicast, or | ||
# use the same function call, but make a distinction between unicast and multicast names in some namespace. | # use the same function call, but make a distinction between unicast and multicast names in some namespace. | ||
We opted for the | We opted for the former (the [[Ouroboros unicast API|Unicast API]] and [[Ouroboros broadcast API|Broadcast API]]), but in any case, the application "has to know" whether it is doing multicast or unicast when it uses the API. | ||
== Examples == | == Examples == | ||
IP networks specify multicast/broadcast using a specific reserved range in their address spaces. There exist protocols to create a tree between members of an IP multicast group. According to the Ouroboros model, this multicast tree corresponds with a ''Broadcast Layer'', and IGMP is its enrollment protocol. An IP multicast address corresponds with the Broadcast Layer name. | IP networks specify multicast/broadcast using a specific reserved range in their address spaces. There exist protocols to create a tree between members of an IP multicast group. According to the Ouroboros model, this multicast tree corresponds with a ''Broadcast Layer'', and IGMP is its enrollment protocol. An IP multicast address corresponds with the Broadcast Layer name. | ||
== Notes == | == Notes == | ||
This conjecture does not imply that an application has to be aware of multicast communication | This conjecture does not imply that an application has to be aware of the use of multicast/broadcast communication further down the network/stack, such as IP unicast implemented over Ethernet may leverage broadcast as used by the Address Resolution Protocol (ARP). | ||
<references /> | <references /> | ||
Latest revision as of 10:08, 21 July 2024
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/broadcast communication. Or, in yet another formulation, it is not possible to have a single transparent API for multicast/broadcast 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 this implementation work, it became clear that to implement multicast, we were re-implementing a lot of code that were already present for unicast layers, most particularly enrollment and the dissemination of link-state routing packets to all IPCPs in the Layer. It also became clear that we could not devise an API that somehow was oblivious to the destination being a single unicast 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 Layer (and nodes can join and leave at will)
- Broadcasting the packets on that network Layer
We call this network a Broadcast Layer.
So, given that insight, we had the option to either
- use different function calls towards unicast and multicast, or
- use the same function call, but make a distinction between unicast and multicast names in some namespace.
We opted for the former (the Unicast API and Broadcast API), but in any case, the application "has to know" whether it is doing multicast or unicast when it uses the API.
Examples
IP networks specify multicast/broadcast using a specific reserved range in their address spaces. There exist protocols to create a tree between members of an IP multicast group. According to the Ouroboros model, this multicast tree corresponds with a Broadcast Layer, and IGMP is its enrollment protocol. An IP multicast address corresponds with the Broadcast Layer name.
Notes
This conjecture does not imply that an application has to be aware of the use of multicast/broadcast communication further down the network/stack, such as IP unicast implemented over Ethernet may leverage broadcast as used by the Address Resolution Protocol (ARP).