23 files changed, 125 insertions, 36 deletions
diff --git a/content/en/blog/news/20191006-new-site.md b/content/en/blog/20191006-new-site.md
index c04ff2d..c04ff2d 100644
--- a/content/en/blog/news/20191006-new-site.md
+++ b/content/en/blog/20191006-new-site.md
diff --git a/content/en/blog/news/20200116-hn.md b/content/en/blog/20200116-hn.md
index b80a7bd..b80a7bd 100644
--- a/content/en/blog/news/20200116-hn.md
+++ b/content/en/blog/20200116-hn.md
diff --git a/content/en/blog/news/20200212-ecmp.md b/content/en/blog/20200212-ecmp.md
index 019b40d..019b40d 100644
--- a/content/en/blog/news/20200212-ecmp.md
+++ b/content/en/blog/20200212-ecmp.md
diff --git a/content/en/blog/news/20200216-ecmp.md b/content/en/blog/20200216-ecmp.md
index ce632c9..ce632c9 100644
--- a/content/en/blog/news/20200216-ecmp.md
+++ b/content/en/blog/20200216-ecmp.md
diff --git a/content/en/blog/news/20200502-frcp.md b/content/en/blog/20200502-frcp.md
index 28c5794..28c5794 100644
--- a/content/en/blog/news/20200502-frcp.md
+++ b/content/en/blog/20200502-frcp.md
diff --git a/content/en/blog/news/20200507-python-lb.png b/content/en/blog/20200507-python-lb.png
index 89e710e..89e710e 100644
--- a/content/en/blog/news/20200507-python-lb.png
+++ b/content/en/blog/20200507-python-lb.png
diff --git a/content/en/blog/news/20200507-python.md b/content/en/blog/20200507-python.md
index d4b3504..2b05c91 100644
--- a/content/en/blog/news/20200507-python.md
+++ b/content/en/blog/20200507-python.md
@@ -65,7 +65,7 @@ released after the weekend.
 Oh, and here is a picture of Ouroboros load-balancing between the C (top right)
 and Python (top left) implementations using the C and Python clients:
 
-{{<figure width="60%" src="/blog/news/20200507-python-lb.png">}}
+{{<figure width="60%" src="/blog/20200507-python-lb.png">}}
 
 Can't wait to get the full API done!
 
diff --git a/content/en/blog/news/20201212-congestion-avoidance.md b/content/en/blog/20201212-congestion-avoidance.md
index f395a4f..0b010c5 100644
--- a/content/en/blog/news/20201212-congestion-avoidance.md
+++ b/content/en/blog/20201212-congestion-avoidance.md
@@ -334,7 +334,7 @@ big oscillations because of AIMD), when switching the flows on the
 clients on and off which is on par with DCTCP and not unexpected
 keeping in mind the similarities between the algorithms:
 
-{{<figure width="60%" src="/blog/news/20201212-congestion.png">}}
+{{<figure width="60%" src="/blog/20201212-congestion.png">}}
 
 The periodic "gaps" were not seen at the ocbr endpoint applicationand
 may have been due to tcpdump not capturing everything that those
diff --git a/content/en/blog/news/20201212-congestion.png b/content/en/blog/20201212-congestion.png
index 8e5b89f..8e5b89f 100644
--- a/content/en/blog/news/20201212-congestion.png
+++ b/content/en/blog/20201212-congestion.png
diff --git a/content/en/blog/news/20201219-congestion-avoidance.md b/content/en/blog/20201219-congestion-avoidance.md
index 7391091..240eb88 100644
--- a/content/en/blog/news/20201219-congestion-avoidance.md
+++ b/content/en/blog/20201219-congestion-avoidance.md
@@ -35,7 +35,7 @@ First, a quick refresh on the experiment layout, it's the the same
 4-node experiment as in the
 [previous post](/blog/2020/12/12/congestion-avoidance-in-ouroboros/#mb-ecn-in-action)
 
-{{<figure width="80%" src="/blog/news/20201219-exp.svg">}}
+{{<figure width="80%" src="/blog/20201219-exp.svg">}}
 
 I tried to draw the setup as best as I can in the figure above.
 
@@ -52,7 +52,7 @@ generated with our _constant bit rate_ ```ocbr``` tool trying to send
 about 80 Mbit/s of application-level throughput over the unicast
 layer.
 
-{{<figure width="80%" src="/blog/news/20201219-congestion.png">}}
+{{<figure width="80%" src="/blog/20201219-congestion.png">}}
 
 The graph above shows the bandwidth -- as captured on the congested
 100Mbit Ethernet link --, separated for each traffic flow, from the
@@ -142,7 +142,7 @@ from the "wire":
 
 ## The network protocol
 
-{{<figure width="80%" src="/blog/news/20201219-ws-0.png">}}
+{{<figure width="80%" src="/blog/20201219-ws-0.png">}}
 
 We will first have a look at packets captured around the point in time
 where the second (red) flow enters the network, about 14 seconds into
@@ -194,7 +194,7 @@ endpoint for the ```ocbr``` server.
 
 ## The flow request
 
-{{<figure width="80%" src="/blog/news/20201219-ws-1.png">}}
+{{<figure width="80%" src="/blog/20201219-ws-1.png">}}
 
 The first "red" packet that was captured is the one for the flow
 allocation request, **FLOW REQUEST**[^6]. As mentioned before, the
@@ -235,7 +235,7 @@ relevant for this message.
 
 ## The flow reply
 
-{{<figure width="80%" src="/blog/news/20201219-ws-2.png">}}
+{{<figure width="80%" src="/blog/20201219-ws-2.png">}}
 
 Now, the **FLOW REPLY** message for our request. It originates our
 machine, so you will notice that the TTL is the starting value of 60.
@@ -247,7 +247,7 @@ for this flow.
 
 ## Congestion / flow update
 
-{{<figure width="80%" src="/blog/news/20201219-ws-3.png">}}
+{{<figure width="80%" src="/blog/20201219-ws-3.png">}}
 
 Now a quick look at the congestion avoidance mechanisms. The
 information for the Additive Increase / Multiple Decrease algorithm is
@@ -256,7 +256,7 @@ active, they experience congestion since the requested bandwidth from
 the two ```ocbr``` clients (180Mbit) exceeds the 100Mbit link, and the
 figure above shows a packet marked with an ECN value of 11.
 
-{{<figure width="80%" src="/blog/news/20201219-ws-4.png">}}
+{{<figure width="80%" src="/blog/20201219-ws-4.png">}}
 
 When the packets on a flow experience congestion, the flow allocator
 at the endpoint (the one our _uni-s_ IPCP) will update the sender with
diff --git a/content/en/blog/news/20201219-congestion.png b/content/en/blog/20201219-congestion.png
index 5675438..5675438 100644
--- a/content/en/blog/news/20201219-congestion.png
+++ b/content/en/blog/20201219-congestion.png
diff --git a/content/en/blog/news/20201219-exp.svg b/content/en/blog/20201219-exp.svg
index 68e09e2..68e09e2 100644
--- a/content/en/blog/news/20201219-exp.svg
+++ b/content/en/blog/20201219-exp.svg
diff --git a/content/en/blog/news/20201219-ws-0.png b/content/en/blog/20201219-ws-0.png
index fd7a83a..fd7a83a 100644
--- a/content/en/blog/news/20201219-ws-0.png
+++ b/content/en/blog/20201219-ws-0.png
diff --git a/content/en/blog/news/20201219-ws-1.png b/content/en/blog/20201219-ws-1.png
index 0f07fd0..0f07fd0 100644
--- a/content/en/blog/news/20201219-ws-1.png
+++ b/content/en/blog/20201219-ws-1.png
diff --git a/content/en/blog/news/20201219-ws-2.png b/content/en/blog/20201219-ws-2.png
index 7cd8b7d..7cd8b7d 100644
--- a/content/en/blog/news/20201219-ws-2.png
+++ b/content/en/blog/20201219-ws-2.png
diff --git a/content/en/blog/news/20201219-ws-3.png b/content/en/blog/20201219-ws-3.png
index 2a6f6d5..2a6f6d5 100644
--- a/content/en/blog/news/20201219-ws-3.png
+++ b/content/en/blog/20201219-ws-3.png
diff --git a/content/en/blog/news/20201219-ws-4.png b/content/en/blog/20201219-ws-4.png
index 3a0ef8c..3a0ef8c 100644
--- a/content/en/blog/news/20201219-ws-4.png
+++ b/content/en/blog/20201219-ws-4.png
diff --git a/content/en/blog/_index.md b/content/en/blog/_index.md
index 43820eb..34904e5 100644
--- a/content/en/blog/_index.md
+++ b/content/en/blog/_index.md
@@ -1,13 +1,7 @@
 ---
-title: "Docsy Blog"
+title: "Developer Blog"
 linkTitle: "Blog"
 menu:
   main:
     weight: 30
 ---
-
-
-This is the **blog** section. It has two categories: News and Releases.
-
-Files in these directories will be listed in reverse chronological order.
-
diff --git a/content/en/blog/news/_index.md b/content/en/blog/news/_index.md
deleted file mode 100644
index c10cfa2..0000000
--- a/content/en/blog/news/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "News About Docsy"
-linkTitle: "News"
-weight: 20
----
diff --git a/content/en/blog/releases/_index.md b/content/en/blog/releases/_index.md
deleted file mode 100644
index b1d9eb4..0000000
--- a/content/en/blog/releases/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
-
----
-title: "New Releases"
-linkTitle: "Releases"
-weight: 20
----
-
-
diff --git a/content/en/blog/releases/upcoming.md b/content/en/blog/releases/upcoming.md
deleted file mode 100644
index f984380..0000000
--- a/content/en/blog/releases/upcoming.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-date: 2019-10-06
-title: "Plans for 0.16"
-linkTitle: "Ouroboros 0.16"
-description: "Ouroboros 0.16"
-author: Dimitri Staessens
----
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/_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
+---