Ouroboros: Difference between revisions

From Ouroboros
Jump to navigation Jump to search
No edit summary
Line 21: Line 21:
** authentication
** authentication
* flow control: sender does not send more traffic than a receiver can cope with
* flow control: sender does not send more traffic than a receiver can cope with
* congestion avoidance: total offered load to the network does not cause systematic delays in packet delivery beyond the expected latency due to packet processing in nodes and propagation delays over the links, and definitely doesn't cause packet loss due to lack of buffer space.
* congestion avoidance: total offered load to the network does not cause systematic delays in packet delivery beyond the expected latency due to packet processing in nodes and propagation delays over the links. Avoid relying on packet loss.
* fragmentation of an application message into smaller network packets, and reassembly
* fragmentation of an application message into smaller network packets, and reassembly
* naming a service
* naming a service

Revision as of 15:43, 31 May 2022

Ouroboros (abbreviated as "O7s") is a work-in-progress Internetwork prototype created by Dimitri Staessens and Sander Vrijders at IMEC / Ghent University early 2016.

Objectives

What we need to clear right out of the way is that our main driver to create Ouroboros was not to solve any specific perceived engineering problems within TCP/IP, or RINA, or whatever other network design. It is also not developed to add some functionality that we perceive as missing in TCP/IP or any other network technology.

Our main driver is to figure out the fundamental laws that govern packet networks as a whole. Laws that if they are broken, the network will not work or will not scale.

The aim is to provide the following network functionality as elegantly as possible:

  • best effort delivery of packets
  • in-order delivery
  • reliable delivery
    • re-transmission of lost packets
    • detection of unwanted packets
    • transmission of packets over diverse paths, possibly sending multiple copies, potentially using some erasure-coding scheme
    • transmission of packets over diverse networks, possible sending multiple copies, potentially using some erasure-coding scheme
  • filtering out received duplicates
  • security
    • encryption
    • authentication
  • flow control: sender does not send more traffic than a receiver can cope with
  • congestion avoidance: total offered load to the network does not cause systematic delays in packet delivery beyond the expected latency due to packet processing in nodes and propagation delays over the links. Avoid relying on packet loss.
  • fragmentation of an application message into smaller network packets, and reassembly
  • naming a service
  • locating a process that provides access to the named service
  • establishing an association between the process that consumes the service and the process that provides access to the service

The prototype is an implementation to validate these ideas.

Model

Main Article: Ouroboros model

The model consists of the following elements:


Prototype

Main Article: Ouroboros prototype

  • IRMd
  • IPCPs
  • Ouroboros library

History

Main Article: History of Ouroboros

The Ouroboros project has its roots in European-funded projects on RINA.


Differences compared to TCP/IP

Main Article: Differences between Ouroboros and TCP/IP

  • Decoupled flow control and congestion avoidance
  • Only explicit congestion avoidance

Differences compared to RINA

Main Article: Differences between Ouroboros and RINA

RIB/CDAP is abstracted as a broadcast layer.

No "shim layers", all layers implement a flow allocator.