aboutsummaryrefslogtreecommitdiff
path: root/content/en
diff options
context:
space:
mode:
Diffstat (limited to 'content/en')
-rw-r--r--content/en/docs/Concepts/ouroboros-model.md47
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_.