diff options
| -rw-r--r-- | content/en/docs/Concepts/ouroboros-model.md | 47 |
1 files changed, 24 insertions, 23 deletions
diff --git a/content/en/docs/Concepts/ouroboros-model.md b/content/en/docs/Concepts/ouroboros-model.md index 299f758..87038b2 100644 --- a/content/en/docs/Concepts/ouroboros-model.md +++ b/content/en/docs/Concepts/ouroboros-model.md @@ -107,6 +107,8 @@ and destination * can involve packet duplication * will not have loops[^6] [^7] +{{<figure src="https://latex.codecogs.com/svg.latex?\Large&space;x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}">}} + ### The broadcast layer A broadcast layer is a collection of interconnected flooding @@ -212,26 +214,25 @@ protocols and functionality in computer networks. When taking the transformation into account the resulting layer(s) will follow the fundamental model as it is presented - above. Also observe that adding such tokens exponentially - increases the address space in the fundemental representation, - ensuring that such approaches inherently can't scale. - -[^8]: Some may think that it's possible to broadcast on a non-tree - graph by pruning in some way, shape or form. There are two - things to consider. First, if the pruning is done to eliminate - links in the graph, let's say in a way that STP prunes links on - an Ethernet or VLAN, then this is operation is equivalent - creating a new broadcast layer. We call this enrollment and - adjacency management. This will be explained in the next - sections. Second is adding the name of the (source) node plus a - token/identifier/cookie as a packet header in order to detect - packets that have traveled in a loop, and dropping them when - they do. This is pulling the wool over ones eyes in a similar - way as in [^6]. This solution can be transformed into a - fundamental broadcast layer by again considering the (token, - node name) space as the new name space and redrawing the graph, - in which the "cut off loops" will be arms in the tree. In the - same way as for unicast layers with loops, this will be an - exponential increase in the number of nodes in the representing - broadcast tree when compared to the starting graph, indicating - again that this kind of solution can not scale. + above. Also observe that adding such tokens may drastically + increase the address space in the fundemental representation. + +[^8]: Is it possible to broadcast on a non-tree graph by pruning in + some way, shape or form? There are some things to + consider. First, if the pruning is done to eliminate links in + the graph, let's say in a way that STP prunes links on an + Ethernet or VLAN, then this is operation is equivalent creating + a new broadcast layer. We call this enrollment and adjacency + management. This will be explained in the next sections. Second + is trying to get around loops by adding the name of the (source) + node plus a token/identifier/cookie as a packet header in order + to detect packets that have traveled in a loop, and dropping + them when they do. This kind of network doesn't fit neither the + broadcast layer nor the unicast layer. But the thing is: it also + _doesn't work_ at any reasonable scale, as all packets need to + be tracked, at least in theory, forever. Assuming packet + ordering is preserved inside a layer a big no-no. Another line + of thinking may be to add a decreasing counter to avoid loops, + but it goes down a similar rabbit hole. How large to set the + counter? This also doesn't scale. These solution may work for + some use cases, but they don't work _in general_. |