Ouroboros and TCP/IP - Revision history

Dimitri at 15:07, 12 November 2023

2023-11-12T15:07:09Z

← Older revision		Revision as of 15:07, 12 November 2023
Line 3:		Line 3:
	[[File: aschenbrenner.png\|border\|right\|thumb\|frame\|OSI model - original sketch]]		[[File: aschenbrenner.png\|border\|right\|thumb\|frame\|OSI model - original sketch]]

	The 5-layer Internet model is the result of retro-actively fitting the TCP/IP protocol stack to the 7-layer OSI model. ~~The~~ original sketch of the 7-layer model is shown here for reference<ref>[https://tnc15.wordpress.com/2015/06/17/locked-in-tour-europe/ Locked in Tour Europe]</ref>.		The 5-layer Internet model is the result of retro-actively fitting the TCP/IP protocol stack to the 7-layer OSI model. An original sketch of the 7-layer model is shown here for reference, adapted from a blog post by John Day<ref>[https://tnc15.wordpress.com/2015/06/17/locked-in-tour-europe/ Locked in Tour Europe]</ref>.

	= Problems and fixes =		= Problems and fixes =

Dimitri at 15:05, 12 November 2023

2023-11-12T15:05:11Z

← Older revision		Revision as of 15:05, 12 November 2023
Line 2:		Line 2:

	[[File: aschenbrenner.png\|border\|right\|thumb\|frame\|OSI model - original sketch]]		[[File: aschenbrenner.png\|border\|right\|thumb\|frame\|OSI model - original sketch]]

			The 5-layer Internet model is the result of retro-actively fitting the TCP/IP protocol stack to the 7-layer OSI model. The original sketch of the 7-layer model is shown here for reference<ref>[https://tnc15.wordpress.com/2015/06/17/locked-in-tour-europe/ Locked in Tour Europe]</ref>.

	= Problems and fixes =		= Problems and fixes =

Dimitri at 15:02, 12 November 2023

2023-11-12T15:02:37Z

← Older revision		Revision as of 15:02, 12 November 2023
Line 1:		Line 1:
	{{Under construction}}		{{Under construction}}

			[[File: aschenbrenner.png\|border\|right\|thumb\|frame\|OSI model - original sketch]]

	= Problems and fixes =		= Problems and fixes =

Dimitri: /* Problems and fixes */

2023-11-08T11:47:39Z

Problems and fixes

← Older revision		Revision as of 11:47, 8 November 2023
Line 3:		Line 3:
	= Problems and fixes =		= Problems and fixes =

	Below is a high-level overview of some problems, issues and nits present in the Internet architecture and TCP/IP protocol stack, with a brief description how they are dealt with within O7s. This list is in no particular order, and it is not meant to be implied that the O7s solutions below are unique to O7s.		Below is a high-level overview of some problems, issues and nits present in the Internet architecture and TCP/IP protocol stack, with a brief description how they are or will be dealt with within O7s. This list is in no particular order, and it is not meant to be implied that the O7s solutions below are unique to O7s. Some of the solutions have been implemented, for some solutions we have clear ideas how to implement them, and for some we aren't sure they can work and need more research.

	== Network ossification ==		== Network ossification ==

Dimitri: /* Problems and fixes */

2023-11-05T10:42:41Z

Problems and fixes

← Older revision		Revision as of 10:42, 5 November 2023
Line 3:		Line 3:
	= Problems and fixes =		= Problems and fixes =

	Below is a high-level overview of some problems, issues and nits present in the Internet architecture and TCP/IP protocol stack, with a brief description how they are dealt with within O7s. This list is in no particular order, ~~without any implied judgement that the approach in O7s~~ is ~~any better or worse than other solutions. It is also~~ not meant to be implied that the O7s solutions below are unique to O7s.		Below is a high-level overview of some problems, issues and nits present in the Internet architecture and TCP/IP protocol stack, with a brief description how they are dealt with within O7s. This list is in no particular order, and it is not meant to be implied that the O7s solutions below are unique to O7s.

	== Network ossification ==		== Network ossification ==

Dimitri: /* The problem */

2023-11-05T10:39:36Z

The problem

← Older revision		Revision as of 10:39, 5 November 2023
Line 28:		Line 28:
	=== The problem ===		=== The problem ===

	Public IP addresses are administratively distributed, cementing a large-scale global topology for the Internet that does not reflect its physical connectivity. This mismatch between logical and physical topology is mitigated by adding specific routing entries, resulting in super-linear routing table sizes. The fact that IP addresses are assigned to interfaces doesn't help, but is not the core issue here~~. The dilemma between preferring addressing or topology is known as ''Rekther's law'', stating ''Either topology follows addressing, or addressing follows topology - choose one''~~. The problem is not restricted to public networks. Private networks too are defined by their addressing, and since all networks grow and change over time, small topological changes in the network often conflict with the existing subnetting and addressing, requiring a periodic network redesign to keep things efficient. Achieving optimal network layout is also hindered by some administrative preferences, as network addresses (especially IPv4) are so engraved in the consciousness of network administrators/engineers that they are used as the primary labels for servers and virtual machines. IPv6's large address space should in theory greatly improve the topology ossification issue. Some argue that IPv6's 128-bit addresses space is a waste of bits, but in our opinion, it is the right choice to allow for topology flexibility in a network with evolving topologies - especially so in the case of the Internet where the topology follows the (manually assigned) addressing. There is a waste of bits, it is the source address in the IPv6 packet header. The impact of IPv6's less intuitive address syntax compared to IPv4 on its adoption should not be underestimated.		Addressing can follow topology or topology can follow addressing. Choose one. -- Rekhter's law

			Public IP addresses are administratively distributed, cementing a large-scale global topology for the Internet that does not reflect its physical connectivity. This mismatch between logical and physical topology is mitigated by adding specific routing entries, resulting in super-linear routing table sizes. The fact that IP addresses are assigned to interfaces doesn't help, but is not the core issue here. The problem is not restricted to public networks. Private networks too are defined by their addressing, and since all networks grow and change over time, small topological changes in the network often conflict with the existing subnetting and addressing, requiring a periodic network redesign to keep things efficient. Achieving optimal network layout is also hindered by some administrative preferences, as network addresses (especially IPv4) are so engraved in the consciousness of network administrators/engineers that they are used as the primary labels for servers and virtual machines. IPv6's large address space should in theory greatly improve the topology ossification issue. Some argue that IPv6's 128-bit addresses space is a waste of bits, but in our opinion, it is the right choice to allow for topology flexibility in a network with evolving topologies - especially so in the case of the Internet where the topology follows the (manually assigned) addressing. There is a waste of bits, it is the source address in the IPv6 packet header. The impact of IPv6's less intuitive address syntax compared to IPv4 on its adoption should not be underestimated.

	=== O7s solution ===		=== O7s solution ===

Dimitri: /* The problem */

2023-11-05T10:35:22Z

The problem

← Older revision		Revision as of 10:35, 5 November 2023
Line 28:		Line 28:
	=== The problem ===		=== The problem ===

	Public IP addresses are administratively distributed, cementing a large-scale global topology for the Internet that does not reflect its physical connectivity. This mismatch between logical and physical topology is mitigated by adding specific routing entries, resulting in super-linear routing table sizes ~~and a reduction in scalability of the global Internet~~. The fact that IP addresses are assigned to interfaces doesn't help, but is not the core issue here. The dilemma between preferring addressing or topology is known as ''Rekther's law'', stating ''Either topology follows addressing, or addressing follows topology - choose one''. The problem is not restricted to public networks. Private networks too are defined by their addressing, and since all networks grow and change over time, small topological changes in the network often conflict with the existing subnetting and addressing, requiring a periodic network redesign to keep things efficient. Achieving optimal network layout is also hindered by some administrative preferences, as network addresses (especially IPv4) are so engraved in the consciousness of network administrators/engineers that they are used as the primary labels for servers and virtual machines. IPv6's large address space should in theory greatly improve the topology ossification issue. Some argue that IPv6's 128-bit addresses space is a waste of bits, but in our opinion, it is the right choice to allow for topology flexibility in a network with evolving topologies - especially so in the case of the Internet where the topology follows the (manually assigned) addressing. There is a waste of bits, it is the source address in the IPv6 packet header. The impact of IPv6's less intuitive address syntax compared to IPv4 on its adoption should not be underestimated.		Public IP addresses are administratively distributed, cementing a large-scale global topology for the Internet that does not reflect its physical connectivity. This mismatch between logical and physical topology is mitigated by adding specific routing entries, resulting in super-linear routing table sizes. The fact that IP addresses are assigned to interfaces doesn't help, but is not the core issue here. The dilemma between preferring addressing or topology is known as ''Rekther's law'', stating ''Either topology follows addressing, or addressing follows topology - choose one''. The problem is not restricted to public networks. Private networks too are defined by their addressing, and since all networks grow and change over time, small topological changes in the network often conflict with the existing subnetting and addressing, requiring a periodic network redesign to keep things efficient. Achieving optimal network layout is also hindered by some administrative preferences, as network addresses (especially IPv4) are so engraved in the consciousness of network administrators/engineers that they are used as the primary labels for servers and virtual machines. IPv6's large address space should in theory greatly improve the topology ossification issue. Some argue that IPv6's 128-bit addresses space is a waste of bits, but in our opinion, it is the right choice to allow for topology flexibility in a network with evolving topologies - especially so in the case of the Internet where the topology follows the (manually assigned) addressing. There is a waste of bits, it is the source address in the IPv6 packet header. The impact of IPv6's less intuitive address syntax compared to IPv4 on its adoption should not be underestimated.

	=== O7s solution ===		=== O7s solution ===
	O7s provides primitives to define and modify the network topology (enrollment and adjacency management), addresses are internal to the network forwarding layer, automatically assigned by the network, and dynamic. The network Layer can renumber without service interruption. Making this scale is still an ongoing area of research - we can't do this yet. It looks feasible from our current vantage point so this is the direction we aim to pursue. Ideally, the O7s network Layer would also automatically configure its subnet topology (routing areas) based on the global topology, but that may not be feasible. In any case, the IP solution to manually define the subnet topology (but not the subnet address assignment) is available as a fallback.		O7s provides primitives to define and modify the network topology (enrollment and adjacency management), addresses are internal to the network forwarding layer, automatically assigned by the network, and dynamic. The network Layer can renumber without service interruption. Making this scale is still an ongoing area of research - we can't do this yet. It looks feasible from our current vantage point so this is the direction we aim to pursue. Ideally, the O7s network Layer would also automatically configure its subnet topology (routing areas) based on the global topology, but that may not be feasible. In any case, the IP solution to manually define the subnet topology (but not the subnet address assignment) is available as a fallback.

Dimitri: /* O7s solution */

2023-11-05T10:34:27Z

O7s solution

← Older revision		Revision as of 10:34, 5 November 2023
Line 31:		Line 31:

	=== O7s solution ===		=== O7s solution ===
	O7s provides primitives to define and modify the network topology (enrollment and adjacency management), addresses are internal to the network forwarding layer, automatically assigned by the network, and dynamic. The network Layer can renumber without service interruption. Making this scale is still an ongoing area of research ~~and~~ we can't do this yet~~, however, it~~ looks feasible from our current vantage point so this is the direction we aim to ~~continue~~.		O7s provides primitives to define and modify the network topology (enrollment and adjacency management), addresses are internal to the network forwarding layer, automatically assigned by the network, and dynamic. The network Layer can renumber without service interruption. Making this scale is still an ongoing area of research - we can't do this yet. It looks feasible from our current vantage point so this is the direction we aim to pursue. Ideally, the O7s network Layer would also automatically configure its subnet topology (routing areas) based on the global topology, but that may not be feasible. In any case, the IP solution to manually define the subnet topology (but not the subnet address assignment) is available as a fallback.

	== IP fragmentation ==		== IP fragmentation ==

Dimitri: /* O7s solution */

2023-11-05T10:28:56Z

O7s solution

← Older revision		Revision as of 10:28, 5 November 2023
Line 31:		Line 31:

	=== O7s solution ===		=== O7s solution ===
	~~O7s addresses are internal to the network (i.e. the Layer), assigned by the network (Layer), and dynamic.~~ O7s provides primitives to define and modify the network topology (enrollment and adjacency management), and ~~addressing should follow automatically~~. The network Layer can renumber ~~nodes efficiently and~~ without interruption.		O7s provides primitives to define and modify the network topology (enrollment and adjacency management), addresses are internal to the network forwarding layer, automatically assigned by the network, and dynamic. The network Layer can renumber without service interruption. Making this scale is still an ongoing area of research and we can't do this yet, however, it looks feasible from our current vantage point so this is the direction we aim to continue.
	~~This~~ is ~~the direction we want to go in,~~ still an ongoing area of research and we can't do this ~~at scale. It~~ looks feasible from our current vantage point.

	== IP fragmentation ==		== IP fragmentation ==

Dimitri: /* O7s solution */

2023-11-05T10:26:12Z

O7s solution

← Older revision		Revision as of 10:26, 5 November 2023
Line 31:		Line 31:

	=== O7s solution ===		=== O7s solution ===
	O7s addresses are internal to the network (i.e. the Layer), assigned by the network (Layer), and dynamic. O7s provides primitives to define and modify the network topology (enrollment and adjacency management), and addressing should follow automatically. The network Layer can renumber nodes efficiently and without interruption. This is ~~not fully implemented yet at scale and is one of~~ the ~~more interesting areas~~ of research.		O7s addresses are internal to the network (i.e. the Layer), assigned by the network (Layer), and dynamic. O7s provides primitives to define and modify the network topology (enrollment and adjacency management), and addressing should follow automatically. The network Layer can renumber nodes efficiently and without interruption.
			This is the direction we want to go in, still an ongoing area of research and we can't do this at scale. It looks feasible from our current vantage point.

	== IP fragmentation ==		== IP fragmentation ==