Ouroboros - Recent changes [en]

Ouroboros Prototype

Dimitri — Sat, 17 Oct 2026 17:56:52 GMT

← Older revision		Revision as of 17:56, 17 October 2026
(One intermediate revision by the same user not shown)
Line 3:		Line 3:
	The Ouroboros prototype is a user-space decentralized packet network implementation based on an overhauled [[Ouroboros Model\| networking model]]. It is being developed in C for POSIX operating systems.		The Ouroboros prototype is a user-space decentralized packet network implementation based on an overhauled [[Ouroboros Model\| networking model]]. It is being developed in C for POSIX operating systems.

	This prototype is very much a work in progress.		This prototype is very much a work in progress. Given that network access requires some daemons to run as root, we recommend you run this prototype in a contained environment (throwaway container, Virtual Machine).

	On this page are instructions for installing the prototype. Once done, head to the [[Ouroboros Tutorials \| tutorials]] section. The [https://ouroboros.rocks/docs old documentation website] is still available for reference, but only this wiki is maintained.		On this page are instructions for installing the prototype. Once done, head to the [[Ouroboros Tutorials \| tutorials]] section. The [https://ouroboros.rocks/docs old documentation website] is still available for reference, but only this wiki is maintained.

Ouroboros

Dimitri — Sat, 17 Oct 2026 17:55:37 GMT

What the prototype already shows

← Older revision		Revision as of 17:55, 17 October 2026
(One intermediate revision by the same user not shown)
Line 39:		Line 39:
	= What the prototype already shows =		= What the prototype already shows =

	The [[Ouroboros Prototype\|prototype]] runs in user space on Linux, *BSD and OS X. It is a proof of concept to toy around with, not production software, but the core claims of the model are running code. The [[Ouroboros Tutorials\|tutorials]] walk through ~~them one by one~~:		The [[Ouroboros Prototype\|prototype]] runs in user space on Linux, *BSD and OS X. It is a proof of concept to toy around with, not production software, but the core claims of the model are running code. The [[Ouroboros Tutorials\|tutorials]] walk through the prototype:

	* '''Names and flows work as described.''' Bind a name to a process, allocate a flow to it, ping ([[Ouroboros Tutorial 01\|01]]). Two processes on the same machine need no network layer at all.		* '''Names and flows work as described.''' Bind a name to a process, allocate a flow to it, ping ([[Ouroboros Tutorial 01\|01]]). Two processes on the same machine need no network layer at all.

Ouroboros Tutorial 10

Dimitri — Mon, 12 Oct 2026 07:52:02 GMT

← Older revision		Revision as of 07:52, 12 October 2026
Line 298:		Line 298:
	</syntaxhighlight>		</syntaxhighlight>

	[[File:O7s_tutorial10-06.png\|center\|thumb\|900px\|The transfers of this tutorial on the same shaped link: the throughput, and the smoothed round-trip time averaged over the transfer, ~~from the FRCT statistics of the oftp client and~~ from <code>ss -ti</code> on the iperf3 socket. The transports that read loss as congestion lose the link to their congestion control. The ones that do not, Ouroboros and BBR, lose almost nothing to the loss; what separates them from the link rate is the headroom their controllers keep, and the round-trip time shows what that headroom buys: a path kept clear of queue.]]		[[File:O7s_tutorial10-06.png\|center\|thumb\|900px\|The transfers of this tutorial on the same shaped link: the throughput, and the smoothed round-trip time averaged over the transfer. For TCP it is the kernel's, from <code>ss -ti</code> on the iperf3 socket. For Ouroboros the solid bar is the round trip the controller in uni-2 measures with its heartbeats, the path and its queue, and the dashed bar extends it to what FRCT in the oftp client measures, with the tx ring and the held acknowledgments in it. The transports that read loss as congestion lose the link to their congestion control. The ones that do not, Ouroboros and BBR, lose almost nothing to the loss; what separates them from the link rate is the headroom their controllers keep, and the round-trip time shows what that headroom buys: a path kept clear of queue.]]

	The comparison is about the shape, not the numbers: iperf3 and oftp are different tools. That our transfer sits a few Mbit/s under CUBIC without loss is tuning. CUBIC takes the link to 100 Mbit/s on the wire by filling the queue in front of it until something gives, and on this link nothing gives but the receiver's window: netem holds 65,536 frames, and the round-trip time of the transfer averages 511 ms, the 20 ms of the path and 491 ms of queue, some 6 MB waiting in front of a 100 Mbit/s link. The controller in uni-2 keeps that queue short and cuts the rate at the first sign of it growing, and the link idles for a moment after every cut; the round trip of our transfer averages 41 ms, and little of that is queue, as we will see. Its constants could let it sit closer to the link, at the price of a slightly longer queue; that trade-off is the controller's to make, and not where the two architectures differ. With loss, the queue is empty: CUBIC, Reno and DCTCP never get near the link, and their round trip is the 21 ms of the path. BBR, which fills the link, keeps its probing in the queue, at 25 ms.		The comparison is about the shape, not the numbers: iperf3 and oftp are different tools. That our transfer sits a few Mbit/s under CUBIC without loss is tuning. CUBIC takes the link to 100 Mbit/s on the wire by filling the queue in front of it until something gives, and on this link nothing gives but the receiver's window: netem holds 65,536 frames, and the round-trip time of the transfer averages 511 ms, the 20 ms of the path and 491 ms of queue, some 6 MB waiting in front of a 100 Mbit/s link. The controller in uni-2 keeps that queue short and cuts the rate at the first sign of it growing, and the link idles for a moment after every cut; the round trip of our transfer averages 41 ms, and little of that is queue, as we will see. Its constants could let it sit closer to the link, at the price of a slightly longer queue; that trade-off is the controller's to make, and not where the two architectures differ. With loss, the queue is empty: CUBIC, Reno and DCTCP never get near the link, and their round trip is the 21 ms of the path. BBR, which fills the link, keeps its probing in the queue, at 25 ms.

File:O7s tutorial10-06.png

Dimitri — Mon, 12 Oct 2026 07:49:24 GMT

Dimitri deleted page File:O7s tutorial10-06.png Deleted old revision 20261010093003!O7s_tutorial10-06.png: content before blanking was: ""

File:O7s tutorial10-06.png

Dimitri — Mon, 12 Oct 2026 07:49:17 GMT

Dimitri uploaded a new version of File:O7s tutorial10-06.png

New page

Ouroboros Implementation Overview

Dimitri — Sun, 11 Oct 2026 11:18:32 GMT

Programming language support

Show changes

Ouroboros Tutorial 08

Dimitri — Sun, 11 Oct 2026 10:32:05 GMT

The FRCT header

← Older revision		Revision as of 10:32, 11 October 2026
Line 82:		Line 82:
	</syntaxhighlight>		</syntaxhighlight>

	After the 5-byte PoA header and the 16-byte DTP header of Tutorial 04 comes the FRCT header. ~~Unlike the DTP header, it is in network byte order:~~		After the 5-byte PoA header and the 16-byte DTP header of Tutorial 04 comes the FRCT header.

	uint16_t flags; c300 DATA, DRF, FFGM, LFGM		uint16_t flags; c300 DATA, DRF, FFGM, LFGM

Ouroboros

Dimitri — Sun, 11 Oct 2026 09:48:08 GMT

← Older revision		Revision as of 09:48, 11 October 2026
(One intermediate revision by the same user not shown)
Line 5:		Line 5:
	Computer networking is a lot more complicated than it needs to be.		Computer networking is a lot more complicated than it needs to be.

	Ask anyone who has moved a rack of servers. The machines move in an afternoon; the network takes the rest of the week. Even when every service is virtualized, the network is what has to be reconfigured by hand, and the network is what breaks when someone gets it wrong. Keeping a service online shouldn't take an army of prized experts.		Ask anyone who has moved a rack of servers. The machines move in an afternoon; the network takes the rest of the week.

	Ouroboros (O7s for short) is a prototype packet-switching technology built on the premise that none of this complexity is fundamental. It is a [[Ouroboros Functional Layering\|redesign of the Internet model]], from the programming interface almost down to the wire, with one goal: networks that are simple to set up, simple to understand and simple to run~~. In a single sentence: ''micro-services architecture applied to the network itself''~~.		Ouroboros (O7s for short) is a prototype packet-switching technology built on the premise that none of this complexity is fundamental. It is a [[Ouroboros Functional Layering\|redesign of the Internet model]], from the programming interface almost down to the wire, with one goal: networks that are simple to set up, simple to understand and simple to run.

	It is an alternative to TCP/IP, but it is perfectly happy to run on top of it.<ref>Ouroboros works as an overlay network over Ethernet or UDP, so there is no need to chuck out your NICs and switches.</ref>		It is an alternative to TCP/IP, but it is perfectly happy to run on top of it.<ref>Ouroboros works as an overlay network over Ethernet or UDP, so there is no need to chuck out your NICs and switches.</ref>

File:O7s tutorial10-06.png

Dimitri — Sun, 11 Oct 2026 08:03:12 GMT

Dimitri deleted page File:O7s tutorial10-06.png Deleted old revision 20261004190555!O7s_tutorial10-06.png: content before blanking was: ""

File:O7s tutorial10-07.png

Dimitri — Sun, 11 Oct 2026 07:53:36 GMT

Dimitri deleted page File:O7s tutorial10-07.png Deleted old revision 20261011075327!O7s_tutorial10-07.png: content before blanking was: ""

File:O7s tutorial10-07.png

Dimitri — Sun, 11 Oct 2026 07:53:27 GMT

Dimitri uploaded a new version of File:O7s tutorial10-07.png

New page

Ouroboros and TCP/IP

Dimitri — Sat, 10 Oct 2026 19:48:26 GMT

Ouroboros

← Older revision		Revision as of 19:48, 10 October 2026
(2 intermediate revisions by the same user not shown)
Line 26:		Line 26:
	\| A new link technology \|\| A new address family at the bottom, and ARP, DHCP and the like to tie it to IP \|\| A [[Ouroboros Functional Layering#The transmission layer\|point of attachment]]: the IPCP attaches to it and the layer is unchanged		\| A new link technology \|\| A new address family at the bottom, and ARP, DHCP and the like to tie it to IP \|\| A [[Ouroboros Functional Layering#The transmission layer\|point of attachment]]: the IPCP attaches to it and the layer is unchanged
	\|}		\|}

			The second row has a cost in code as well as in deployment. Homa, the receiver-driven transport for the datacentre, is about nineteen thousand lines in the Linux kernel, of which some two thousand are the idea itself: the grants, shortest message first and the priority cutoffs. The rest is there because the sockets world gives a new transport nothing to stand on, so it must bring its own socket family, RPC state, buffer pools, loss repair, offload path and metrics, and then win a protocol number so the network will pass it. In Ouroboros the same idea would be one congestion-avoidance policy of about fifteen hundred lines, seams included, because everything else is already provided and shared with every other policy: flows and the IRMd for naming and allocation, FRCT for fragmentation and repair, shared-memory rings for buffers, and the Layer MTU for message boundaries. A peer of TCP must reimplement the host; a policy only has to say what it does differently, because the host is already a Layer.

	= Protocol ossification =		= Protocol ossification =
Line 35:		Line 37:
	== Ouroboros ==		== Ouroboros ==

	The Ouroboros [[Ouroboros Protocols\|protocols]] have no field that names what is above them, and no field with a well-defined value. Where the TCP/IP headers identify a protocol or a service, the Ouroboros headers carry a ~~random ID~~ chosen for one flow:		The Ouroboros [[Ouroboros Protocols\|protocols]] have no field that names what is above them, and no field with a well-defined value. Where the TCP/IP headers identify a protocol or a service, the Ouroboros headers carry a label chosen for one flow or one attachment:

	{\| class="wikitable"		{\| class="wikitable"
Line 57:		Line 59:
	== Ouroboros ==		== Ouroboros ==

	Ouroboros provides primitives to define and modify the network topology (enrolment and adjacency management). Addresses are internal to the network forwarding layer, ~~assigned~~ by the ~~network~~, and not ~~visible~~ to ~~applications~~. In the prototype ~~today~~, a Layer has one address level: the address authority hands out a random address, routing is link state over the whole Layer, and ~~the directory that maps~~ names ~~to addresses is a DHT. Renumbering a Layer without service interruption, and making~~ the ~~forwarding layer scale with multiple address levels~~, ~~is still research. It looks feasible from our current vantage point~~, ~~so it is the direction we pursue. Ideally, the network~~ Layer ~~would also~~ configure its ~~subnet topology (routing~~ areas) from ~~the global~~ topology~~, but that may not be feasible; in any case, the IP solution of defining the subnet topology by hand, but not the address assignment, remains available as~~ a ~~fallback~~.		Ouroboros provides primitives to define and modify the network topology (enrolment and adjacency management). Addresses are internal to the network forwarding layer and never visible to applications, so nothing outside the Layer can depend on them, and the Layer is free to change them.

			The forwarding layer scales by giving an address several levels: one name per level, from the most significant down. Each level has its own routing area, a set of IPCPs that share one dissemination scope, realised as a broadcast Layer, and an IPCP joins the areas of the levels it takes part in. Areas form a tree; in the parent's routing a child area is a single vertex, reached through the gateways that are members of both, so an IPCP holds a routing table per level it joined, not one for the whole Layer. Forwarding descends the address: the first level at which the destination differs from the local address is the level the packet is forwarded at, and an IPCP that has no scope at that level hands the packet to a member of its own area that does.

			Within an area, a name is bound to exactly one thing, a member or a child area, but a member or a child may bear two names at once. That is what makes the topology changeable while it runs: renumbering an area, splitting a tree at its root, joining trees under a new root, merging two sibling areas and moving a node into another area are each a sequence of make-before-break steps, adopt the new name, retire the old one, with every pair of nodes reachable before and after each step. This model has been worked out in detail and checked against a model of the forwarding and routing, for delivery between every pair of nodes, for path stretch against flat shortest paths, and for connectivity across every step of every operation, and the changes to the unicast IPCP have been mapped out: the forwarding lookup, the routing component and the address authority change, management flows become joins into broadcast Layers, and the flat address of the prototype today is the case of a single level. It is not in the tree yet. In the prototype, a Layer has one address level, the address authority hands out a random address, and routing is link state over the whole Layer. What is still open is automation: which areas exist, which IPCPs join them and which names they get are given by the operator, as subnets are in IP, and whether a Layer can configure its areas from its own topology is a question for later.

	= Names are synonyms for addresses =		= Names are synonyms for addresses =

Ouroboros

Dimitri — Sat, 10 Oct 2026 16:43:31 GMT

What the prototype already shows

← Older revision		Revision as of 16:43, 10 October 2026
Line 48:		Line 48:
	* '''Anycast and load balancing''' between several instances of a service come for free from the naming model ([[Ouroboros Tutorial 02\|02]], [[Ouroboros Tutorial 05\|05]]).		* '''Anycast and load balancing''' between several instances of a service come for free from the naming model ([[Ouroboros Tutorial 02\|02]], [[Ouroboros Tutorial 05\|05]]).

	The [[Ouroboros Implementation Overview\|implementation overview]] has the status per component.		The [[Ouroboros Implementation Overview\|implementation overview]] has the status per component. A quick overview vs TCP can be found here: [[Ouroboros_and_TCP/IP]].

	There's a lot more to be done, but there's only one way to eat an elephant: one bite at a time.		There's a lot more to be done, but there's only one way to eat an elephant: one bite at a time.

Ouroboros Tutorial 10

Dimitri — Sat, 10 Oct 2026 16:39:39 GMT

Transports compared

@@ Line 335: / Line 335: @@
 $ sudo ip link del br0
 </syntaxhighlight>
 == Notes ==
 <references />

Ouroboros and TCP/IP

Dimitri — Sat, 10 Oct 2026 16:31:01 GMT

Ouroboros

Show changes

Ouroboros Tutorial 10

Dimitri — Sat, 10 Oct 2026 10:05:30 GMT

Transports compared

@@ Line 335: / Line 335: @@
 $ sudo ip link del br0
 </syntaxhighlight>
 == Notes ==
 <references />

File:O7s tutorial10-08.png

Dimitri — Sat, 10 Oct 2026 09:30:58 GMT

Dimitri uploaded File:O7s tutorial10-08.png

New page

File:O7s tutorial10-07.png

Dimitri — Sat, 10 Oct 2026 09:30:26 GMT

Dimitri uploaded File:O7s tutorial10-07.png

New page

File:O7s tutorial10-06.png

Dimitri — Sat, 10 Oct 2026 09:30:03 GMT

Dimitri uploaded a new version of File:O7s tutorial10-06.png

New page

Ouroboros Tutorial 10

Dimitri — Sat, 10 Oct 2026 09:29:17 GMT

Show changes

Ouroboros:General disclaimer

Dimitri — Fri, 09 Oct 2026 10:55:26 GMT

← Older revision		Revision as of 10:55, 9 October 2026
Line 1:		Line 1:
	Ouroboros is a work-in-progress research prototype~~, so a lot of this is still conjecture rather than fact~~.		Ouroboros is a work-in-progress research prototype.

	This wiki serves as a documentation resource about our understanding of packet networks and the current state of the Ouroboros prototype.		This wiki serves as a documentation resource about our understanding of packet networks and the current state of the Ouroboros prototype.

	~~Not~~ that this content is provided by the developers and is not independently curated nor peer-reviewed.		Note that this content is provided by the developers and is not independently curated nor peer-reviewed.

Ouroboros

Dimitri — Fri, 09 Oct 2026 05:57:31 GMT

Why not just fix the layer model?

← Older revision		Revision as of 05:57, 9 October 2026
(4 intermediate revisions by the same user not shown)
Line 15:		Line 15:
	Every networking course starts with the same picture: a stack of layers, seven in the textbook, five in practice. Physical at the bottom, then link, network, transport and application, each with its own job and its own protocols. TCP/IP is the set of protocols that fills in the slots. The trouble is that the picture is wrong, and everything built on it inherits the flaws.		Every networking course starts with the same picture: a stack of layers, seven in the textbook, five in practice. Physical at the bottom, then link, network, transport and application, each with its own job and its own protocols. TCP/IP is the set of protocols that fills in the slots. The trouble is that the picture is wrong, and everything built on it inherits the flaws.

	'''The layers aren't actually different.''' Every layer names things, addresses things, forwards things and checks that what was sent has arrived. Ethernet does it, IP does it, TCP does it, and the application does it once more. The model treats these as five separate problems, so we have five sets of protocols, five address formats and five toolboxes, each configured by hand, in its own format, by its own specialists.		'''Real networks don't fit the picture.''' VLANs, MPLS, tunnels, VPNs and overlays are networks inside networks, and the model has no slot for them, so they end up as "layer 2.5" with their own ad-hoc rules. If IP is the network layer, what is ICMP, which runs on top of IP and is also in the network layer? When the examples don't fit the model, it is the model that is wrong.

	'''Real networks don't fit the picture.''' VLANs, MPLS, tunnels, VPNs and overlays are networks inside networks, and the model has no slot for them, so they end up as "layer 2~~.5" and "layer 3~~.5" with their own ad-hoc rules. If IP is the network layer, what is ICMP, which runs on top of IP and is also ~~called~~ the network layer? When the examples don't fit the model, it is the model that is wrong.

	'''The layers are welded together.''' On paper, a layer only talks to its neighbors. In practice, the Ethernet frame says which network protocol it carries, the IP packet says which transport protocol, the port number says which application, and the socket interface bakes the IP address format into every program. Nothing can be replaced on its own. That is why adding IPv6 became a decades-long slog, and why the core protocols haven't changed in thirty years.		'''The layers are welded together.''' On paper, a layer only talks to its neighbors. In practice, the Ethernet frame says which network protocol it carries, the IP packet says which transport protocol, the port number says which application, and the socket interface bakes the IP address format into every program. Nothing can be replaced on its own. That is why adding IPv6 became a decades-long slog, and why the core protocols haven't changed in thirty years.
Line 35:		Line 33:
	'''Flows, not sockets and ports.''' An application asks the system for a ''flow'' to a name and says what it needs: how much delay it can tolerate, whether every byte must arrive, whether the peer must be authenticated, whether the data must be encrypted. The system does the rest and hands back a descriptor to read and write. Six function calls cover the whole application interface.		'''Flows, not sockets and ports.''' An application asks the system for a ''flow'' to a name and says what it needs: how much delay it can tolerate, whether every byte must arrive, whether the peer must be authenticated, whether the data must be encrypted. The system does the rest and hands back a descriptor to read and write. Six function calls cover the whole application interface.

	'''Trust before the first byte.''' The keys needed to authenticate a service come from the ~~directory~~, not from the other end of the connection. A flow is authenticated, and if requested encrypted, before the application sees any data. Endpoint identifiers are random and live only as long as the flow, so there is nothing to scan for, and forged packets get an attacker nothing: replies go to the stored peer, not to the forger.		'''Trust before the first byte.''' The keys needed to authenticate a service come from the naming system, not from the other end of the connection. A flow is authenticated, and if requested encrypted, before the application sees any data. Endpoint identifiers are random and live only as long as the flow, so there is nothing to scan for, and forged packets get an attacker nothing: replies go to the stored peer, not to the forger.

	'''One configuration file per machine.''' Applications carry no network configuration. A single file tells the system which layers to join and which names to serve, and every application on the machine inherits it.		'''One configuration file per machine.''' Applications carry no network configuration. A single file tells the system which layers to join and which names to serve, and every application on the machine inherits it.
Line 51:		Line 49:

	The [[Ouroboros Implementation Overview\|implementation overview]] has the status per component.		The [[Ouroboros Implementation Overview\|implementation overview]] has the status per component.

			There's a lot more to be done, but there's only one way to eat an elephant: one bite at a time.

	= Where it comes from =		= Where it comes from =

	Ouroboros builds on two decades of European research into future networks, including the Recursive InterNetwork Architecture (RINA), and on four decades of hindsight about what went wrong with the Internet. In 2016, after working on the [https://github.com/IRATI/stack IRATI] kernel prototype of RINA, we started over from scratch in user space, to steer around issues we saw in the RINA model and to keep the barrier to entry low. We have been taking the prototype forward in our spare time ever since; the [[History of Ouroboros\|full history]] has the details.		Ouroboros builds on two decades of European research into future networks, including the Recursive InterNetwork Architecture (RINA), and on four decades of hindsight about what went wrong with the Internet. In 2016, after working on the [https://github.com/IRATI/stack IRATI] kernel prototype of RINA, we started over from scratch in user space, to steer around issues we saw in the RINA model and to keep the barrier to entry low. We have been taking the prototype forward in our spare time ever since; the [[History of Ouroboros\|full history]] has the details.

	~~There's only one way to eat an elephant: one bite at a time.~~

	= Dig deeper =		= Dig deeper =

File:O7s model-06.png

Dimitri — Thu, 08 Oct 2026 21:09:03 GMT

Dimitri uploaded a new version of File:O7s model-06.png

New page

File:O7s model-05.png

Dimitri — Thu, 08 Oct 2026 21:08:17 GMT

Dimitri uploaded a new version of File:O7s model-05.png

New page

File:O7s model-04.png

Dimitri — Thu, 08 Oct 2026 21:07:37 GMT

Dimitri uploaded a new version of File:O7s model-04.png

New page

File:O7s model-03.png

Dimitri — Thu, 08 Oct 2026 21:07:18 GMT

Dimitri uploaded a new version of File:O7s model-03.png

New page

File:O7s model-02.png

Dimitri — Thu, 08 Oct 2026 21:06:53 GMT

Dimitri uploaded a new version of File:O7s model-02.png

New page

File:O7s model-01.png

Dimitri — Thu, 08 Oct 2026 21:06:27 GMT

Dimitri uploaded a new version of File:O7s model-01.png

New page

Ouroboros Functional Layering

Dimitri — Thu, 08 Oct 2026 21:06:13 GMT

← Older revision		Revision as of 21:06, 8 October 2026
Line 19:		Line 19:
	== Application end-to-end layer ==		== Application end-to-end layer ==

	The application end-to-end layer ~~establishes flows and~~ makes the packets on ~~them~~ reliable and ~~secure~~. A unicast flow is initiated by a client process towards a server process, which is identified by a [[Glossary#Name\|service name]].		The application end-to-end layer makes the packets on a flow reliable and private. A unicast flow is initiated by a client process towards a server process, which is identified by a [[Glossary#Name\|service name]].

	It can provide:		It can provide:
	* encryption with a symmetric key;		* encryption with the symmetric key that flow allocation hands it;
	* reliability, implemented by [[Flow_and_Retransmission_Control_Protocol\|FRCT]]: fragmentation, in-order delivery, duplicate suppression, Automatic Repeat reQuest (ARQ) and flow control;		* reliability, implemented by [[Flow_and_Retransmission_Control_Protocol\|FRCT]]: fragmentation, in-order delivery, duplicate suppression, Automatic Repeat reQuest (ARQ) and flow control;
	* integrity, through hash-based checks such as CRC32;		* integrity, through hash-based checks such as CRC32;
Line 28:		Line 28:

	Everything in that list is optional. A flow without FRCT is a '''raw flow'''.		Everything in that list is optional. A flow without FRCT is a '''raw flow'''.

	Flow establishment, authentication and symmetric key distribution are each a '''two-way handshake'''. When the MTU allows, authentication and key exchange piggyback on the flow establishment request and reply, so all three complete within a single round-trip time. See [[Flow Allocation]] for the details.

	Below it, the application end-to-end layer uses the Network IPC API to reach the network end-to-end layer.		Below it, the application end-to-end layer uses the Network IPC API to reach the network end-to-end layer.
Line 43:		Line 41:
	# [[Congestion avoidance]]: watch the network flow for congestion and police its throughput as needed.		# [[Congestion avoidance]]: watch the network flow for congestion and police its throughput as needed.

	The ~~flow allocation~~ exchange maps the QoS the application asked for onto a network traffic class~~. It~~ carries the application-level request and response inside its own ~~request and response~~, so that application-level and network-level flow allocation together fit in one round trip.		Flow establishment, authentication and symmetric key distribution are each a '''two-way handshake'''. When the MTU allows, authentication and key exchange piggyback on the flow establishment request and reply, so all three complete within a single round-trip time. The exchange also maps the QoS the application asked for onto a network traffic class, and it carries the application-level request and response inside its own, so that application-level and network-level flow allocation together fit in one round trip. See [[Flow Allocation]] for the details.

			Authentication lives on the boundary between the two end-to-end layers rather than in either of them. The IRMd, which implements the Network IPC API, runs the handshake on behalf of both: it holds the credentials, verifies the peer against the certificate for the service name, in both directions if required, and hands the resulting symmetric key to the application end-to-end layer, while the flow allocator only carries the exchange. The same boundary is where an IPCP authenticates when it enrols in a Layer, through the flow it allocates over the Layer below, and where a process could one day authenticate with a Broadcast Layer when it joins one.

	The network end-to-end layer is the interface for the application end-to-end layer above it. The two always go hand in hand.		The network end-to-end layer is the interface for the application end-to-end layer above it. The two always go hand in hand.
Line 57:		Line 57:
	The transmission layer is best seen as a special case of the forwarding or flooding layer, used to build a 0-Layer that stops the recursion. It comes with its own, tailored network end-to-end layer, because the application end-to-end layer above always needs one. For a dumb link a minimal flow allocator will do; when the transmission layer wraps a legacy network, it may pay to have every feature of a full network end-to-end layer.		The transmission layer is best seen as a special case of the forwarding or flooding layer, used to build a 0-Layer that stops the recursion. It comes with its own, tailored network end-to-end layer, because the application end-to-end layer above always needs one. For a dumb link a minimal flow allocator will do; when the transmission layer wraps a legacy network, it may pay to have every feature of a full network end-to-end layer.

	In the prototype this 0-Layer is not a separate process. Ethernet and UDP are '''points of attachment''' (PoAs): the transmission layer and its minimal flow allocator live inside the IPCP that uses them, attached with ''irm ipcp poa attach''. A PoA resolves peers, assigns endpoint identifiers and ~~carries~~ the flow allocation handshake. It hands its flows to the IPCP's application end-to-end layer through the same Network IPC API as any Layer, so ~~authentication,~~ encryption and reliability on those flows come from that layer~~, not from the PoA~~, and nothing above can tell a PoA from a Layer. An IPCP can attach to several PoAs at once. The one 0-Layer that is still an IPCP of its own is the local IPCP, which connects processes on the same machine through memory.		In the prototype this 0-Layer is not a separate process. Ethernet and UDP are '''points of attachment''' (PoAs): the transmission layer and its minimal flow allocator live inside the IPCP that uses them, attached with ''irm ipcp poa attach''. A PoA resolves peers, assigns endpoint identifiers and runs the flow allocation handshake, authentication included. It hands its flows to the IPCP's application end-to-end layer through the same Network IPC API as any Layer, so encryption and reliability on those flows come from that layer, and nothing above can tell a PoA from a Layer. An IPCP can attach to several PoAs at once. The one 0-Layer that is still an IPCP of its own is the local IPCP, which connects processes on the same machine through memory.

	= Broadcast model =		= Broadcast model =
Line 67:		Line 67:
	== Broadcast API ==		== Broadcast API ==

	The [[Broadcast API]] lets an application join and leave broadcast flows, and read from and write to them. Like the Unicast API it is network-agnostic, with synchronous and asynchronous primitives and message or stream delivery. QoS on broadcast flows is inherently more limited than on unicast flows. A broadcast flow maps directly onto a [[Broadcast Layer]].		The [[Broadcast API]] lets an application join and leave broadcast flows, and read from and write to them. Like the Unicast API it is network-agnostic, with synchronous and asynchronous primitives and message or stream delivery. QoS on broadcast flows is inherently more limited than on unicast flows. A broadcast flow maps directly onto a [[Broadcast Layer]]. Joining one is not authenticated today; the Broadcast API is where that would be added.

	== Network flooding layer ==		== Network flooding layer ==
Line 107:		Line 107:
	== Splitting the transport layer ==		== Splitting the transport layer ==

	The functions of the transport layer, TCP and UDP, move into two independent layers. The application end-to-end layer takes [[Glossary#Automated_Repeat_reQuest\|ARQ]] and flow control; the network end-to-end layer takes multiplexing, name-to-address resolution and congestion control. The split resembles the sublayering of the data link layer into Logical Link Control and Media Access Control. Name-to-address resolution, roughly what a DNS SRV lookup does, lands inside the network end-to-end layer instead of being an optional chore for the application. The Network IPC API takes a ''service name'' and resolves it internally, whereas the TCP/IP transport layer wants an IP address and a port and leaves the lookup to the application.		The functions of the transport layer, TCP and UDP, move into two independent layers. The application end-to-end layer takes [[Glossary#Automated_Repeat_reQuest\|ARQ]] and flow control; the network end-to-end layer takes multiplexing, name-to-address resolution and congestion control. Authentication sits on the boundary between the two, as part of flow allocation, where TCP/IP leaves it to the application. The split resembles the sublayering of the data link layer into Logical Link Control and Media Access Control. Name-to-address resolution, roughly what a DNS SRV lookup does, lands inside the network end-to-end layer instead of being an optional chore for the application. The Network IPC API takes a ''service name'' and resolves it internally, whereas the TCP/IP transport layer wants an IP address and a port and leaves the lookup to the application.

	== Untangling the network layer ==		== Untangling the network layer ==

File:O7s model-03.png

Dimitri — Thu, 08 Oct 2026 20:58:00 GMT

Dimitri uploaded a new version of File:O7s model-03.png

New page

File:O7s model-02.png

Dimitri — Thu, 08 Oct 2026 20:57:40 GMT

Dimitri uploaded a new version of File:O7s model-02.png

New page

File:O7s model-01.png

Dimitri — Thu, 08 Oct 2026 20:57:11 GMT

Dimitri uploaded a new version of File:O7s model-01.png

New page