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 research community, 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 without judgement on 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 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.

O7s solution

Avoid protocol fields that require fixed well-defined values; and especially values that define or link to properties or elements present in a different layer of the architecture.

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. The use of 2 number spaces to solve transmission ambiguity is interesting and may be adopted.