blog: Small update to loc-id-split

1 files changed, 49 insertions, 38 deletions

diff --git a/content/en/blog/20221207-loc-id-split.md b/content/en/blog/20221207-loc-id-split.md
index 6544837..bad82ac 100644
--- a/content/en/blog/20221207-loc-id-split.md
+++ b/content/en/blog/20221207-loc-id-split.md
@@ -5,10 +5,10 @@ linkTitle: "On Loc/Id split"
 author: Dimitri Staessens
 ---
 
-A few weeks back I had a drink with a Thijs who is now doing a
-master's thesis on Loc/Id split, so we dug into the concepts behind
-Locators and Identifiers and see if matches or in any way interferes
-with the Ouroboros network model.
+A few weeks back I had a drink with Thijs who is now doing a master's
+thesis on Loc/Id split, so we dug into the concepts behind Locators
+and Identifiers and see if matches or in any way interferes with the
+Ouroboros network model.
 
 For this, we started from the paper _Locator/Identifier Split
 Networking: A Promising Future Internet Architecture_[^1].
@@ -113,15 +113,19 @@ on that destination laptop. Then there is no way for the incoming
 laptop to know where to deliver the packets to. Unless the identifier
 is in the packet header. But host-based Loc/Id split had them
 optional?  This seems to hint that host-based Loc/Id split supports
-device mobility but not real application mobility[^3].
+device mobility but cannot fully support application mobility[^3].
+
+So, what is that identifier actually naming? Well, all that moved was
+the application state, and the identifier seemed to move with
+it... And since the routers in the example don't run "end-host"
+applications, they don't need identifiers.
 
 # What does the Ouroboros model say?
 
-Now, Ouroboros does things a little bit differently, but it maps quite
-well. Ouroboros[^4] gives each application process a name, which (well
-its hash) is mapped to a network address. That application name
-basically maps to the _identifier_, and the network address maps to
-the _locator_.
+Ouroboros[^4] gives each application process a name, which is mapped
+to an IPCP's address[^5]. The O7s application name basically
+corresponds to the _identifier_, and the IPCPs address maps to the
+_locator_.
 
 {{<figure width="30%" src="/blog/20220228-flm-app.png">}}
 
@@ -134,30 +138,33 @@ TCP without congestion avoidance) and a network end-to-end layer that
 includes the _flow allocator_.
 
 The _flow allocator_ in O7s performs the name <--> address mapping
-that is similar to id <--> loc mapping. Interesting to note is that
-the Flow allocator is present in every network host, which is needed
-for Congestion Notifications. Given that identifiers are mapping to
+that is similar to id <--> loc mapping. Interesting to note is that in
+O7s, the Flow allocator is present in every IPCP, which is needed for
+Congestion Notifications. Given that identifiers are mapping to
 application names, resolving in name <--> address in other nodes than
 the source, like in network-based Loc/Id split, is not violating the
 O7s architecture. But we haven't considered this as it doesn't look
 feasible from a scalability perspective.
 
 Now, the differences. First, the naming. The "identifier" in Ouroboros
-is a network-wide unique application name[^7]. Processes[^7] can be
-_bound_ to an application name. If a single process binds to an
+is a network/globally unique application name[^6]. Processes[^7] can
+be _bound_ to an application name. If a single process binds to an
 application name it's unicast, if multiple processes on the same
-server, it provides per-connection load-balancing between these
-processes. If multiple processes on different servers bind to the same
-name, it's anycast.
-
-Ouroboros endpoint identifiers (EIDs) are only known to the Flow
-Allocator. This allows allocating a new flow (including new EIDs)
-while keeping the connection state in the process (FRCP) intact, and
-thus allowing application mobility in addition to device mobility.
-
-Taking another look at the Loc/Id split figure, note that Ouroboros
-splits "network" from "application" just above the "Sub-layer", instead
-of above the transport layer.
+server bind to the same name, it provides per-connection
+load-balancing between these processes. If multiple processes on
+different servers bind to the same name, it provides a form of anycast
+name-based load-balancing.
+
+Second, Ouroboros endpoint identifiers (EIDs) are only known to the
+Flow Allocator at the endpoint and specify the application. The O7s
+EID can be viewed as a combination of the L3 _protocol_ field and the
+L4 _port_ field into a single field that sits in between L3 and L4
+(the Loc/Id proposed sublayer). This allows O7s to allocate a new flow
+(assigning new EIDs) while keeping the connection state in the process
+(FRCP) intact, and thus allowing full application mobility in addition
+to device mobility. Taking another look at the Loc/Id split figure,
+note that Ouroboros splits "network" from "application" just above the
+"Sub-layer", instead of above the "transport layer".
 
 # Wrapping up
 
@@ -167,9 +174,9 @@ strikes me most is that LoC/Id split is still not very well-defined as
 a _model_. What exactly _are_ identifiers? What exactly _are_
 locators? The thing that sets O7s apart is that the model consists of
 a limited amount of objects (forwarding elements and flooding
-elements, which form Layers[^7], application, process, ...) that have
-well-defined names[^8] that are immutable and exist only for as long
-as the object exists. But that's a whole post by itself.
+elements, which form Layers[^8], application, process, ...) that have
+well-defined names[^9] that are immutable and exist only for as long
+as the object exists.
 
 
 [^1]: https://doi.org/10.1109/COMST.2017.2728478
@@ -187,18 +194,22 @@ as the object exists. But that's a whole post by itself.
 [^4]: This, and a lot of other things in O7s, were proposed in the
       RINA architecture, that's where the credit should go.
 
-[^5]: We might change that to "service name" but terminology is hard
-      to get right.
+[^5]: To be accurate: we hash the application name.
+
+[^6]: At least, for a public Internetwork, they should be globally
+      unique.
 
-[^6]: In O7s, processes are named with a process name (which in the
+[^7]: In O7s, processes are named with a process name (which in the
       implementation maps to the linux process id (pid). Process names
-      are only local (system) scope and live until the process dies.
+      are only local (system) scope.
 
-[^7]: I capitalize layers, as these are have a different meaning than
-      the layers in the figure above. Maybe we should call them
-      _strata_ instead of layers. Again, terminology is hard.
+[^8]: I capitalize Layers, as these Layers that are made up of
+      forwarding elements (unicast Layers) or flooding elements
+      (broadcast Layers) have a different meaning than the layers in
+      the discussion above. Maybe we should call them _strata_ instead
+      of Layers...
 
-[^8]: Synonyms are allowed, but they serve no function in the
+[^9]: Synonyms are allowed, but they serve no function in the
       architecture. As an example, application names are hashed (a
       synonym) which has practical implications for security and
       implementation simplicity, but the architecture is theoretically