Ouroboros and TCP/IP: Difference between revisions
| Line 3: | Line 3: | ||
= Problems and fixes = | = Problems and fixes = | ||
Below is a list of problems, issues and nits present in the TCP/IP architecture and stack with a description how O7s approaches them. This list is in no particular order, without any implied gravity | Below is a list of problems, issues and nits present in the TCP/IP architecture and stack with a description how O7s approaches them. This list is in no particular order, without any implied gravity. | ||
== Network ossification == | == Network ossification == | ||
=== The problem === | === 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 === | === 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 == | == 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<ref>[https://datatracker.ietf.org/doc/html/rfc9000 RFC 9000]</ref>. | |||
=== O7s solution === | === O7s solution === | ||
Revision as of 07:47, 25 October 2023
This page is under construction
Problems and fixes
Below is a list of problems, issues and nits present in the TCP/IP architecture and stack with a description how O7s approaches them. This list is in no particular order, without any implied gravity.
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[1].
O7s solution
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.