Ouroboros and TCP/IP: Difference between revisions
(Created page with "{{Under construction}}") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Under construction}} | {{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 and without any implied gravity of these problems within TCP. | |||
== Network ossification == | |||
=== The problem === | |||
=== O7s solution === | |||
== Protocol ossification == | |||
=== 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. | |||
=== 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. | |||
Revision as of 07:17, 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 and without any implied gravity of these problems within TCP.
Network ossification
The problem
O7s solution
Protocol ossification
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.
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.