Ouroboros and TCP/IP

 This page is under construction  

Problems and fixes

Below is a list of problems, issues and nits present in the Internet architecture and TCP/IP protocol stack with a description how O7s approaches them. This list is in no particular order, without any implied judgement that the approach in O7s is any better or worse than solutions in TCP/IP.

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.

O7s solution

No protocol fields that have fixed or 'well-defined' values.

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.