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 severity of these issues within TCP/IP, and keeping in mind solutions or mitigations present 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
A clean interface (network IPC API) completely hides internals between application and network. In theory, the O7s network protocol can be changed without even restarting O7s application-layer server and client applications.
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[1].
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.
O7s solution
FRCP uses per-packet numbering and adds a byte-oriented read/write on top of this protocol.