diff options
Diffstat (limited to 'content/en/docs/Releases')
| -rw-r--r-- | content/en/docs/Releases/0_18.md | 109 | ||||
| -rw-r--r-- | content/en/docs/Releases/0_20.md | 70 | ||||
| -rw-r--r-- | content/en/docs/Releases/_index.md | 6 |
3 files changed, 185 insertions, 0 deletions
diff --git a/content/en/docs/Releases/0_18.md b/content/en/docs/Releases/0_18.md new file mode 100644 index 0000000..c489d33 --- /dev/null +++ b/content/en/docs/Releases/0_18.md @@ -0,0 +1,109 @@ +--- +date: 2021-02-12 +title: "Ouroboros 0.18" +linkTitle: "Ouroboros 0.18" +description: "Major additions and changes in 0.18.0" +author: Dimitri Staessens +--- + +With version 0.18 come a number of interesting updates to the prototype. + +### Automated Repeat-Request (ARQ) and flow control + +We finished the implementation of the base retransmission +logic. Ouroboros will now send, receive and handle acknowledgments +under packet loss conditions. It will also send and handle window +updates for flow control. The operation of flow control is very +similar to the operation of window-based flow control in TCP, the main +difference being that our sequence numbers are per-packet instead of +per-byte. + +The previous version of FRCP had some partial implementation of the +ARQ functionality, such as piggybacking ACK information on _writes_ +and handling sequence numbers on _reads_. But now, Ourobroos will also +send (delayed) ACK packets without data if the application is not +sending and finish sending when a flow is closed if not everything was +acknowledged (can be turned off with the FRCTFLINGER flag). + +Recall that Ouroboros has this logic implemented in the application +library, it's not a separate component (or kernel) that is managing +transmit and receive buffers and retransmission. Furthermore, our +implementation doesn't add a thread to the application. If a +single-threaded application uses ARQ, it will remain single-threaded. + +It's not unlikely that in the future we will add the option for the +library to start a dedicated thread to manage ARQ as this may have +some beneficial characteristics for read/write call durations. Other +future addditions may include fast-retransmit and selective ACK +support. + +The most important characteristic of Ouroboros FRCP compared to TCP +and derivative protocols (QUIC, SCTP, ...) is that it is 100% +independent of congestion control, which allows for it to operate at +real RTT timescales (i.e. microseconds in datacenters) without fear of +RTT underestimates severely capping throughput. Another characteristic +is that the RTT estimate is really measuring the responsiveness of the +application, not the kernel on the machine. + +A detailed description of the operation of ARQ can be found +in the [protocols](/docs/concepts/protocols/#operation-of-frcp) +section. + +### Congestion Avoidance + +The next big addition is congestion avoidance. By default, the unicast +layer's default configuration will now congestion-control all client +traffic sent over them[^1]. As noted above, congestion avoidance in +Ouroboros is completely independent of the operation of ARQ and flow +control. For more information about how this all works, have a look at +the developer blog +[here](/blog/2020/12/12/congestion-avoidance-in-ouroboros/) and +[here](/blog/2020/12/19/exploring-ouroboros-with-wireshark/). + +### Revision of the flow allocator + +We also made a change to the flow allocator, more specifically the +Endpoint IDs to use 64-bit identifiers. The reason for this change is +to make it harder to guess these endpoint identifiers. In TCP, +applications can listen to sockets that are bound to a port on a (set +of) IP addresses. You can't imagine how many hosts are trying to brute +force password guess SSH logins on TCP port 22. To make this at least +a bit harder, Ouroboros has no well-known application ports, and after +this patch they are roughtly equivalent to a 32-bit random +number. Note that in an ideal Ouroboros deployment, sensitive +applications such as SSH login should run on a different layer/network +than publicly available applications. + +### Revision of the ipcpd-udp + +The ipcpd-udp has gone through some revisions during its lifetime. In +the beginning, we wanted to emulate the operation of an Ouroboros +layers, having the flow allocator listening on a certain UDP port, and +mapping endpoints identifiers to random ephemeral UDP ports. So as an +example, the source would generate a UDP socket, e.g. on port 30927, +and send a request for a new flow the fixed known Ouroboros UDP port +(3531) at the receiver. This also generates a socket on an ephemeral +UDP port, say 23705, and it sends a response back to the source on UDP +port 3531. Traffic for the "client" flow would be on UDP port pair +(30927, 23705). This was giving a bunch of headaches with computers +behind NAT firewalls, rendering that scheme only useful in lab +environments. To make it more useable, the next revision used a single +fixed incoming UDP port for the flow allocator protocol, using an +ephemeral UDP port from the sender side per flow and added the flow +allocator endpoints as a "next header" inside UDP. So traffic would +always be sent to destination UDP port 3531. Benefit was that only a +single port was needed in the NAT forwarding rules, and that anyone +running Ouroboros would be able to receive allocation messages, and +this is enforcing a bit all users to participate in a mesh topology. +However, opening a certain UDP port is still a hassle, so in this +(most likely final) revision, we just run the flow allocator in the +ipcpd-udp as a UDP server on a (configurable) port. No more NAT +firewall configurations required if you want to connect (but if you +want to accept connections, opening UDP port 3531 is still required). + +The full changelog can be browsed in +[cgit](/cgit/ouroboros/log/?showmsg=1). + +[^1]: This is not a claim that every packet inside a layer is + flow-controlled: internal management traffic to the layer (flow + allocator protocol, etc) is not congestion-controlled.
\ No newline at end of file diff --git a/content/en/docs/Releases/0_20.md b/content/en/docs/Releases/0_20.md new file mode 100644 index 0000000..7f2ff9a --- /dev/null +++ b/content/en/docs/Releases/0_20.md @@ -0,0 +1,70 @@ +--- +date: 2023-09-21 +title: "Ouroboros 0.20" +linkTitle: "Ouroboros 0.20" +description: "Major additions and changes in 0.20.0" +author: Dimitri Staessens +--- + +Version 0.20 brings some code refactoring and a slow of bugfixes to +the prototype to improve stability, but the main quality-of-life +addition is config file support in TOML format. This removes the need +for bash scripts to configure the prototype on reboots/restarts; a +very basic feature that was long overdue. + +As an example, before v0.20, this server had Ouroboros running as a +systemd service, and it was configured using the following irm commands: + +```bash +irm i b t udp n udp l udp ip 51.38.114.133 +irm n r ouroboros.rocks.oping l udp +irm b prog oping n ouroboros.rocks.oping auto -- -l +``` + +These bootstrap a UDP layer to the server's public IP address, +register the name "ouroboros.rocks.oping" with that layer and bind the +program binary /usr/bin/oping to that name, telling the irmd to start +that server automatically if it wasn't running before. + +While pretty simple to perform, if the service was restarted or the +server was rebooted, we needed to re-run these commands (we could have +added them to some system startup script, of course). + +Now the IRMd will load the config file specified in +/etc/ouroboros/irmd.conf. The IRMd configuration to achieve the above +(I renamed the UDP layer to "Internet", but that name doesn't really +matter if there is only one ipcpd-udp in the system): +```bash +root@vps646159:~# cat /etc/ouroboros/irmd.conf +### Ouroboros configuration file +[name."ouroboros.rocks.oping"] +prog=["/usr/bin/oping"] +args=["-l"] + +[udp.internet] +bootstrap="Internet" +ip="51.38.114.133" +reg=["ouroboros.rocks.oping"] +``` + +To enable config file support, tomlc99 is needed. Install via + +```bash +git clone https://github.com/cktan/tomlc99 +cd tomlc99 +make +sudo make install +``` + +and then reconfigure cmake and build Ouroboros as usual. + +More information on how to use config files is in the example +configuration file, installed in /etc/ouroboros/irmd.conf.example, or +you can have a quick look in the +[repository](/cgit/ouroboros/tree/irmd.conf.in). + +The full git changelog can be browsed in +[cgit](/cgit/ouroboros/log/?showmsg=1). + + + diff --git a/content/en/docs/Releases/_index.md b/content/en/docs/Releases/_index.md new file mode 100644 index 0000000..8328c33 --- /dev/null +++ b/content/en/docs/Releases/_index.md @@ -0,0 +1,6 @@ + +--- +title: "Releases" +linkTitle: "Release notes" +weight: 120 +--- |