aboutsummaryrefslogtreecommitdiff
path: root/content/en
diff options
context:
space:
mode:
authorDimitri Staessens <[email protected]>2021-03-22 17:04:28 +0100
committerDimitri Staessens <[email protected]>2021-03-22 17:04:28 +0100
commitc92c69912314e5862efef8f31477e167c30715f2 (patch)
tree1f6e2d984cd40eca83ea9db52acd97a5db7442a9 /content/en
parent50739383c88d479e166685197b541bbe7ed45739 (diff)
downloadwebsite-c92c69912314e5862efef8f31477e167c30715f2.tar.gz
website-c92c69912314e5862efef8f31477e167c30715f2.zip
content: Fixes based on Sanders comments
Diffstat (limited to 'content/en')
-rw-r--r--content/en/blog/20210320-ouroboros-rina.md39
1 files changed, 20 insertions, 19 deletions
diff --git a/content/en/blog/20210320-ouroboros-rina.md b/content/en/blog/20210320-ouroboros-rina.md
index b70012c..9d51f64 100644
--- a/content/en/blog/20210320-ouroboros-rina.md
+++ b/content/en/blog/20210320-ouroboros-rina.md
@@ -70,11 +70,10 @@ very heavily on software development. Project work was performed as
part of PhD tracks, so who would do the work? There was a PhD student
under my guidance working mostly on OpenFlow, Sachin -- one of the
kindest people I have ever met, and now a professor at TU Dublin --
-and there was also a master thesis student, Sander Vrijders, that was
-interested in pursuing a PhD in our research group. After a couple of
-internal sessions where we explained possible research tracks aligned
-to ongoing and upcoming projects in our group, Sander decided to take
-on the challenge of IRATI and start a PhD track on RINA.
+and we had a student with us, Sander Vrijders, who just finished his
+master's thesis. We invited him to talk about a possible PhD track,
+aligned to ongoing and upcoming projects in our group. Sander decided
+to take on the challenge of IRATI and start a PhD track on RINA.
### IRATI
@@ -112,16 +111,15 @@ had an advisory role in the project.
The first work was determining the software design of the
implementation. IRATI was going to build an in-kernel implementation
of RINA. A lot of the heavy lifting on the design was already done
-during the project proposal preparation phase, and the components to
-be implemented were
+during the project proposal preparation phase, and about 3 months into
+the projects, the components to be implemented were
[well-defined](https://core.ac.uk/download/pdf/190646748.pdf).
Broadly speaking, there were 3 things to implement: the IPCPs that
make up the RINA layers (Distributed IPC Facilities, DIFs), the
component that is responsible for creating and starting these IPCPs
-(the IPC manager, which had a user space and a kernel space part), and
-the core library to communicate between these components, called
-_librina_. The prototype would be built in 3 phases over the course of
-2 years.
+(the IPC manager), and the core library to communicate between these
+components, called _librina_. The prototype would be built in 3 phases
+over the course of 2 years.
i2cat was going to get started on most of the management parts (IPC
Manager, based on their existing Java implementation; librina,
@@ -361,7 +359,7 @@ improving gradually over time. Our real problem was _scale_, to which
the biggest hurdle was the configuration of the IRATI stack. It was a
complete nightmare. Almost anything and everything had to be
preconfigured in _json_. I remember that by that time, Vincenzo had
-developed a tool called the _demonstator_ based on tiny buildroot VMs
+developed a tool called the _demonstrator_ based on tiny buildroot VMs
to create setups for local testing, but this wasn't going to help us
deploy it on the Fed4FIRE testbeds. So Sander developed one of the
first orchestrators for RINA, called the _configurator_ for deploying
@@ -544,7 +542,7 @@ passing that around with NULL values all the time was really ugly. The
naming API in Ouroboros changed quickly over time, initially saving
some state in an _init_ call (the naming information of the current
application, for instance) and later on removing the source naming
-information from the flow allocation protocol alltogether, because it
+information from the flow allocation protocol altogether, because it
could so easily be filled with fake garbage that one shouldn't rely on
it for anything. The four-tuple was then broken up to pass two 2-tuple
name and instance-id, using one for the Process, the other for the
@@ -586,7 +584,7 @@ Ouroboros, at FOSDEM 2018,
When we tried to propose them to the RINA community, these changes
were not exactly met with cheers. The interactions with that community
-was alse beginning to change. RINA was the _specs_. Why are we now
+was also beginning to change. RINA was the _specs_. Why are we now
again asking questions about basic things that we implemented in IRATI
years ago? IRATI shows its works. Want to change the _specs_: talk to
John.
@@ -846,11 +844,14 @@ in the IPCP, as a set of function calls, just like HTTP
libraries. Sander was initially skeptic, because to his taste, if a
single-threaded application uses the library, it should remain
single-threaded. How could it send acknowledgements, restransmit
-packets etc? I agreed, but said I was confident that it would work by
-running the functionality as part of the IPC calls,
-read/write/fevent. And that's how it's implemented now. All this
-meant that Ouroboros layers were not DIFs, and we stopped using that
-terminology.
+packets etc? And the RINA specs had congestion avoidance as part of
+EFCP/DTCP. At least that shouldn't be in the application!? I agreed,
+but said I was confident that it would make the single-threaded thing
+work by running the functionality as part of the IPC calls,
+read/write/fevent. And congestion avoidance logic should be in the
+IPCP in the flow allocator. And that's how it's implemented now. All
+this meant that Ouroboros layers were not DIFs, and we stopped using
+that terminology.
By now, the prototype was running stable enough for us to go _open
source_. We got approval from IMEC to release it to the public under