Ouroboros and TCP/IP
This page is under construction
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[1].
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 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
The problem
The term ossification of the Internet is sometimes used to describe a lack of evolvability - difficulties in implementing and deploying changes to core protocols - in the TCP/IP networking stack. The prime example of this is the slow adoption of IPv6. At the root of the problem is the lack of separation between mechanism and policy at Layer 3, i.e. no service interface. Sure, deploying a new network-layer protocol will always be a endeavour requiring OS and network hardware changes. But the fact that this essentially L3 change bubbles up all the way to the application layer (AF_INET6, sockaddr_in6, ...) while also trickling down into the data link layer (Ethertype 0x86DD) adds additional slog to standardization and adoption. The question does this application support IPv6? should never have been a thing.
O7s solution
Clean interfaces hide internals between O7s layers. This makes O7s Layers essentially hot-swappable so, at least in theory, the O7s network protocol can be changed without affecting operation of network.
Protocol ossification
The problem
If a protocol is designed with a flexible structure, but that flexibility is never used in practice, some implementation is going to assume it is constant. TCP/IP protocols are riddled with bits and pieces that are not needed and/or have only a few values that are ever used. An example is the Protocol field in IP, where a lot of hardware drops anything that is non-standard and adding a new value to the standard requires updating a lot of hardware. QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks[2].
O7s solution
No protocol fields that have fixed or 'well-defined' values.
Topology ossification
The problem
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 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
The problem
An application-layer message may span multiple TCP segments, which in turn may span many IP fragments. When an IP fragment is lost, retransmission in TCP will retransmit all IP fragments related to the TCP segment. IP fragmentation is mostly deprecated.
O7s solution
Fragmentation at the application end-to-end layer based on path MTU preserves the application-layer message size.
TCP is byte-stream only
The problem
TCP sequence numbers are per-byte instead of per-packet. This is efficient for large bulk data transfers, but application protocols over TCP that are message-based have to manage message boundaries themselves. QUIC uses 2 sequence number spaces (to solve the transmission ambiguity problem), the stream offset also being per-byte. SCTP is a packet-based reliable protocol, but less frequently used. The application needs to choose the protocol (SOCK_STREAM / SOCK_SEQPACKET and IPPROTO_TCP / IPPROTO_SCTP etc).
O7s solution
FRCP uses per-packet sequence numbering, fragmentation bits are used to preserve application-layer message boundaries and a byte-oriented read/write option is provided on top of this protocol when needed for bulk data streams. Application sets service as a generic QoS specification, it doesn't need to know of protocols.
Where do addresses go?
The problem
IP addresses are assigned to interfaces, causing issues with multihoming, especially over multiple networks. Every so often the argument pops up whether addresses should be assigned to interfaces or nodes, a false dichotomy.
O7s solution
In general, in every system, there is one address per attached network, and that address emerges naturally from the internal structure of the IPCP's forwarding components. With some exceptions of 0-Layers (Transmission layer), addresses are not associated with hardware elements.
Duplicate functionality between functional layers
The problem
Some mechanisms are present in multiple layers of the TCP/IP internet model, such as retransmission and flow control in the Data Link's LLC sublayer and the Transport Layer, and security mechanisms in about every layer.
O7s solution
A functional model without duplication of functionality. However, there is a repeating structure (the Layer), defined by scope instead of function.
Technological Ambiguity and Contradictions
The problem
A lot of technologies don't fit the 5/7-layer models for the Internet, such as MPLS (Layer 2.5?) and various encapsulations (Virtual Private Networks, application-layer tunnels, ...). If IP is L3 how is ICMP, running on top of IP, also L3? If UDP is L4, what is QUIC? The 5-layer model has some use as marketing terminology, but a model with so many logical contradictions has no place in a science curriculum. We can't brush this aside.
O7s solution
The repeating structure (the Layer) in O7s readily accommodates such tunneling and overlay solutions without internal inconsistencies, duplication or contradictions.