History of Ouroboros - Revision history

Dimitri: /* 2017: Ouroboros diverges from RINA */

2024-02-18T11:28:03Z

2017: Ouroboros diverges from RINA

← Older revision		Revision as of 11:28, 18 February 2024
Line 154:		Line 154:
	We were again under pressure to get some publications out; in order to meet ARCFIRE objectives, and Sander had to meet some publication quota to finish his PhD. The design of [[Rumba]] was interesting enough for a paper, the implementation allowed us to deploy 3 Recursive Network prototypes (IRATI, rlite and Ouroboros) on testeds using different APIs: jFed for Fed4Fire and [https://www.geni.net/ GENI], Emulab for iMinds virtual wall testbed, QEMU using virtual machines, docker using -- well -- docker containers, and a local option only for Ouroboros. But we needed more publications, so for ARCFIRE Sander had implemented Loop-Free Alternates routing in Ouroboros and was getting some larger-scale results with them. And I reluctantly started working on a paper on Ouroboros -- I still felt the time wasn't right, and we first needed to have a full FRCP implementation and full congestion avoidance to make a worthwile analysis.		We were again under pressure to get some publications out; in order to meet ARCFIRE objectives, and Sander had to meet some publication quota to finish his PhD. The design of [[Rumba]] was interesting enough for a paper, the implementation allowed us to deploy 3 Recursive Network prototypes (IRATI, rlite and Ouroboros) on testeds using different APIs: jFed for Fed4Fire and [https://www.geni.net/ GENI], Emulab for iMinds virtual wall testbed, QEMU using virtual machines, docker using -- well -- docker containers, and a local option only for Ouroboros. But we needed more publications, so for ARCFIRE Sander had implemented Loop-Free Alternates routing in Ouroboros and was getting some larger-scale results with them. And I reluctantly started working on a paper on Ouroboros -- I still felt the time wasn't right, and we first needed to have a full FRCP implementation and full congestion avoidance to make a worthwile analysis.

	We finished the experiments for ARCFIRE, but as with PRISTINE, the results were not accepted for publication. During the writing of the paper, a final realization came. We had implemented our link-state routing a while ago, and it was doing something interesting, akin to all link-state routing protocols: a link-state packet that came in on some flow, was sent out on all other flows. It was -- in effect --doing broadcast. But... OSPF is doing the same. Wait a minute. OSPF uses a multicast IP address. But of course! Multicast wasn't what it seemed to be. Multicast was broadcast on a layer, creating a multicast group was enrollment in that layer. A multicast IP address is a broadcast Layer name! Based on the link-state routing code in the ''normal IPCP''~~, I implemented the~~ broadcast IPCP in a single night. The ''normal IPCP'' was renamed ''unicast IPCP''. It had all fallen into place, the Ouroboros architecture was shaped.		We finished the experiments for ARCFIRE, but as with PRISTINE, the results were not accepted for publication. During the writing of the paper, a final realization came. We had implemented our link-state routing a while ago, and it was doing something interesting, akin to all link-state routing protocols: a link-state packet that came in on some flow, was sent out on all other flows. It was -- in effect --doing broadcast. But... OSPF is doing the same. Wait a minute. OSPF uses a multicast IP address. But of course! Multicast wasn't what it seemed to be. Multicast was broadcast on a layer, creating a multicast group was enrollment in that layer. A multicast IP address is a broadcast Layer name! Based on the link-state routing code in the ''normal IPCP''. The broadcast IPCP was implented in a single night. The ''normal IPCP'' was renamed ''unicast IPCP''. It had all fallen into place, the Ouroboros architecture was shaped.

Dimitri at 11:15, 10 November 2023

2023-11-10T11:15:03Z

← Older revision		Revision as of 11:15, 10 November 2023
Line 1:		Line 1:
	~~{{Under construction}}~~

	Disclaimer: this article expresses the view of its author.		Disclaimer: this article expresses the view of its author.

Dimitri: /* 2016: ARCFIRE and the start of Ouroboros */

2023-11-10T11:14:39Z

2016: ARCFIRE and the start of Ouroboros

← Older revision		Revision as of 11:14, 10 November 2023
Line 116:		Line 116:
	Somewhere around April, we were starting the implementation of a _normal_ IPCP in Ouroboros, and another RINA component was quickly becoming a nuisance: the ''Common Distributed Application Protocol'' (CDAP). While I had no problem with the objectives of CDAP, I was -- to put it mildly -- not a big fan of the object-oriented paradigm that was underneath it. Its methods, _read/write, create/destroy, start/stop_ make sense to many, but just like the HTTP methods PUT/GET/DELETE/POST/... there is nothing fundamental about it. It might as well have just one method, [http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html execute].		Somewhere around April, we were starting the implementation of a _normal_ IPCP in Ouroboros, and another RINA component was quickly becoming a nuisance: the ''Common Distributed Application Protocol'' (CDAP). While I had no problem with the objectives of CDAP, I was -- to put it mildly -- not a big fan of the object-oriented paradigm that was underneath it. Its methods, _read/write, create/destroy, start/stop_ make sense to many, but just like the HTTP methods PUT/GET/DELETE/POST/... there is nothing fundamental about it. It might as well have just one method, [http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html execute].

	Summer was approaching fast. Most of the contributions to PRISTINE were in, so the ARCFIRE partners could start to focus on that project. There was a risk: ARCFIRE depended on the Fed4FIRE testbeds, and Fed4FIRE was ending and its future was not certain. The projected target API for _rumba_ was [~~jFed](~~https://jfed.ilabt.imec.be/). To mitigate the risk, we made an inventory of other potential testbeds, and to accomodate for the wait for the results of the funding calls, we proposed (and got) an extention to ARCFIRE with 6 months to a 30-month project duration. In the end Fed4FIRE+ was funded, ARCFIRE had some breathing space -- after all, we had to fire on all cylinders to get the best possible results and make a case for RINA -- and Sander and myself had some extra time to get Ouroboros up and running.		Summer was approaching fast. Most of the contributions to PRISTINE were in, so the ARCFIRE partners could start to focus on that project. There was a risk: ARCFIRE depended on the Fed4FIRE testbeds, and Fed4FIRE was ending and its future was not certain. The projected target API for _rumba_ was [https://jfed.ilabt.imec.be/ jFed]. To mitigate the risk, we made an inventory of other potential testbeds, and to accomodate for the wait for the results of the funding calls, we proposed (and got) an extention to ARCFIRE with 6 months to a 30-month project duration. In the end Fed4FIRE+ was funded, ARCFIRE had some breathing space -- after all, we had to fire on all cylinders to get the best possible results and make a case for RINA -- and Sander and myself had some extra time to get Ouroboros up and running.

	Sander quickly developed an Ethernet LLC ''shim DIF'' for Ouroboros based on the UDP shim DIF, and after that, we both moved our focus on the key components in the ''normal IPCP'', implementing the full flow allocator and building the data transfer protocol (DTP), and the routing and forwarding functionality. CDAP was getting more and more annoying, but apart from that, this part of the RINA specs were fairly mature following the implementation work in IRATI, and the implementation progress was steady and rather uneventful. For now.		Sander quickly developed an Ethernet LLC ''shim DIF'' for Ouroboros based on the UDP shim DIF, and after that, we both moved our focus on the key components in the ''normal IPCP'', implementing the full flow allocator and building the data transfer protocol (DTP), and the routing and forwarding functionality. CDAP was getting more and more annoying, but apart from that, this part of the RINA specs were fairly mature following the implementation work in IRATI, and the implementation progress was steady and rather uneventful. For now.

Dimitri: /* 2016: ARCFIRE and the start of Ouroboros */

2023-11-10T11:14:04Z

2016: ARCFIRE and the start of Ouroboros

← Older revision		Revision as of 11:14, 10 November 2023
Line 114:		Line 114:
	We had also implemented our first ''shim DIF'', which would allow to run the Ouroboros prototype over UDP/IPv4. We started with a UDP shim because there is a POSIX sockets API for UDP. Recall that we were targeting POSIX, including FreeBSD and MacOS X to make the Ouroboros prototype more accessible. Programming interfaces into Ethernet, such as _raw sockets_, are not standard between operating systems, so we would implement an Ethernet _shim DIF_ later. Now, the Ouroboros _shim DIF_ stopped being a _shim_ pretty fast. When we were developing the _shim DIFs_ for IRATI, there was one very important rule: we were not allowed to add functionality to the protocol we were wrapping with the RINA API; we could only _map_ functions that were existing in the (Etherent/UDP) protocol. This -- was the underlying reasoning -- would show that the protocol/layers in the current Internet were _incomplete_ layers. But that also meant that the functions that were not present -- the flow allocator in particular -- would need to be circumvented through manual configuration at the endpoints. We weren't going to have any of that -- the Ouroboros IPCP daemons all implement a flow allocator. You may also be wondering why none of the prototypes have a ''shim DIF'' directly over IP. It's perfectly possible! But the reason is simple: it would use a non-standardized value for the ''protocol'' field in the IP header, and most IP routers drop such packets. It is for that same reason QUIC/HTTP3 is over UDP and not over IP. TCP/IP protocol ossification at work again!		We had also implemented our first ''shim DIF'', which would allow to run the Ouroboros prototype over UDP/IPv4. We started with a UDP shim because there is a POSIX sockets API for UDP. Recall that we were targeting POSIX, including FreeBSD and MacOS X to make the Ouroboros prototype more accessible. Programming interfaces into Ethernet, such as _raw sockets_, are not standard between operating systems, so we would implement an Ethernet _shim DIF_ later. Now, the Ouroboros _shim DIF_ stopped being a _shim_ pretty fast. When we were developing the _shim DIFs_ for IRATI, there was one very important rule: we were not allowed to add functionality to the protocol we were wrapping with the RINA API; we could only _map_ functions that were existing in the (Etherent/UDP) protocol. This -- was the underlying reasoning -- would show that the protocol/layers in the current Internet were _incomplete_ layers. But that also meant that the functions that were not present -- the flow allocator in particular -- would need to be circumvented through manual configuration at the endpoints. We weren't going to have any of that -- the Ouroboros IPCP daemons all implement a flow allocator. You may also be wondering why none of the prototypes have a ''shim DIF'' directly over IP. It's perfectly possible! But the reason is simple: it would use a non-standardized value for the ''protocol'' field in the IP header, and most IP routers drop such packets. It is for that same reason QUIC/HTTP3 is over UDP and not over IP. TCP/IP protocol ossification at work again!

	Somewhere around April, we were starting the implementation of a _normal_ IPCP in Ouroboros, and another RINA component was quickly becoming a nuisance: the ''Common Distributed Application Protocol'' (CDAP). While I had no problem with the objectives of CDAP, I was -- to put it mildly -- not a big fan of the object-oriented paradigm that was underneath it. Its methods, _read/write, create/destroy, start/stop_ make sense to many, but just like the HTTP methods PUT/GET/DELETE/POST/... there is nothing fundamental about it. It might as well have just one method, [~~execute](~~http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).		Somewhere around April, we were starting the implementation of a _normal_ IPCP in Ouroboros, and another RINA component was quickly becoming a nuisance: the ''Common Distributed Application Protocol'' (CDAP). While I had no problem with the objectives of CDAP, I was -- to put it mildly -- not a big fan of the object-oriented paradigm that was underneath it. Its methods, _read/write, create/destroy, start/stop_ make sense to many, but just like the HTTP methods PUT/GET/DELETE/POST/... there is nothing fundamental about it. It might as well have just one method, [http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html execute].

	Summer was approaching fast. Most of the contributions to PRISTINE were in, so the ARCFIRE partners could start to focus on that project. There was a risk: ARCFIRE depended on the Fed4FIRE testbeds, and Fed4FIRE was ending and its future was not certain. The projected target API for _rumba_ was [jFed](https://jfed.ilabt.imec.be/). To mitigate the risk, we made an inventory of other potential testbeds, and to accomodate for the wait for the results of the funding calls, we proposed (and got) an extention to ARCFIRE with 6 months to a 30-month project duration. In the end Fed4FIRE+ was funded, ARCFIRE had some breathing space -- after all, we had to fire on all cylinders to get the best possible results and make a case for RINA -- and Sander and myself had some extra time to get Ouroboros up and running.		Summer was approaching fast. Most of the contributions to PRISTINE were in, so the ARCFIRE partners could start to focus on that project. There was a risk: ARCFIRE depended on the Fed4FIRE testbeds, and Fed4FIRE was ending and its future was not certain. The projected target API for _rumba_ was [jFed](https://jfed.ilabt.imec.be/). To mitigate the risk, we made an inventory of other potential testbeds, and to accomodate for the wait for the results of the funding calls, we proposed (and got) an extention to ARCFIRE with 6 months to a 30-month project duration. In the end Fed4FIRE+ was funded, ARCFIRE had some breathing space -- after all, we had to fire on all cylinders to get the best possible results and make a case for RINA -- and Sander and myself had some extra time to get Ouroboros up and running.

Dimitri: /* 2016: ARCFIRE and the start of Ouroboros */

2023-11-10T11:13:35Z

2016: ARCFIRE and the start of Ouroboros

← Older revision		Revision as of 11:13, 10 November 2023
Line 102:		Line 102:
	= 2016: ARCFIRE and the start of Ouroboros =		= 2016: ARCFIRE and the start of Ouroboros =

	Another year, and we kept the tradition of RINA project kick-offs going. This time it was again in Barcelona, but without a co-located workshop. ARCFIRE (like IRATI before it) was within the FIRE framework, and the project committed to get experiments running with a reasonable number of nodes (on the order of 100) to demonstrate stability and scale of the prototypes and also to bring more tooling to the RINA community. The project was coordinated by Sven van der Meer (Ericsson at that time), who had done significant work on the PRISTINE use cases, and would focus on the impact of RINA on network management. The industry-inspired use cases were brought by Diego López (Telefónica), _acteur incontournable_ in the Network Functions Virtualization (NFV) world. The project was of course topped off with the usual suspects - i2cat, Nextworks, and ourselves. The order at hand for us was to develop a fleshed-out testbed deployment framework for RINA, which we named [~~Rumba](~~https://gitlab.com/arcfire/rumba). The name derived from rhumba - a bunch of rattlesnakes - and an Ouroboros is a mythical snake, and it was written in Python. A rhumba project already existed, but rumba was an accepted alternate spelling.		Another year, and we kept the tradition of RINA project kick-offs going. This time it was again in Barcelona, but without a co-located workshop. ARCFIRE (like IRATI before it) was within the FIRE framework, and the project committed to get experiments running with a reasonable number of nodes (on the order of 100) to demonstrate stability and scale of the prototypes and also to bring more tooling to the RINA community. The project was coordinated by Sven van der Meer (Ericsson at that time), who had done significant work on the PRISTINE use cases, and would focus on the impact of RINA on network management. The industry-inspired use cases were brought by Diego López (Telefónica), _acteur incontournable_ in the Network Functions Virtualization (NFV) world. The project was of course topped off with the usual suspects - i2cat, Nextworks, and ourselves. The order at hand for us was to develop a fleshed-out testbed deployment framework for RINA, which we named [https://gitlab.com/arcfire/rumba Rumba]. The name derived from rhumba - a bunch of rattlesnakes - and an Ouroboros is a mythical snake, and it was written in Python. A rhumba project already existed, but rumba was an accepted alternate spelling.

	In early 2016, the RINA landscape was very different compared to when we embarked on IRATI in 2013. There were now 2 open source prototypes, IRATI was the de-facto standard used in European Funded projects, but Vincenzo's rlite was also becoming available at the time and would also be used in ARCFIRE. And soon, the development of a third prototype -- _Ouroboros_ -- would start. External perception of RINA in the scientific community had also been shifting, and not in a positive direction. At the start of the IRATI project, we had the position paper with project plans and outlines, and the papers on the _shims_ showed some ways on how RINA could be deployed. But other articles trying to demonstrate the benefits of RINA were -- despite all the efforts and good will of all people involved -- lacking in quality, mostly due to the limitations of the software. All these subpar publications did more harm than good, as the quality of the publications rubbed off on the perceived merits of the RINA architecture as a whole. We were always feeling this pressure to publish _something_, _anything_ -- and reviewers were always looking for a value proposition -- Why is this better than TCP/IP or my preferred solution?, Compare this in depth to my preferred solution -- that we simply couldn't support with data at this point in time. And not for lack of want or a lack of trying. But at least, ARCFIRE had at 2 years to look forward to, a focused scope and by now, the team had a lot of experience in the bag. But for the future of RINA, we knew the pressure was on -- this was a _now or never_ type of situation.		In early 2016, the RINA landscape was very different compared to when we embarked on IRATI in 2013. There were now 2 open source prototypes, IRATI was the de-facto standard used in European Funded projects, but Vincenzo's rlite was also becoming available at the time and would also be used in ARCFIRE. And soon, the development of a third prototype -- _Ouroboros_ -- would start. External perception of RINA in the scientific community had also been shifting, and not in a positive direction. At the start of the IRATI project, we had the position paper with project plans and outlines, and the papers on the _shims_ showed some ways on how RINA could be deployed. But other articles trying to demonstrate the benefits of RINA were -- despite all the efforts and good will of all people involved -- lacking in quality, mostly due to the limitations of the software. All these subpar publications did more harm than good, as the quality of the publications rubbed off on the perceived merits of the RINA architecture as a whole. We were always feeling this pressure to publish _something_, _anything_ -- and reviewers were always looking for a value proposition -- Why is this better than TCP/IP or my preferred solution?, Compare this in depth to my preferred solution -- that we simply couldn't support with data at this point in time. And not for lack of want or a lack of trying. But at least, ARCFIRE had at 2 years to look forward to, a focused scope and by now, the team had a lot of experience in the bag. But for the future of RINA, we knew the pressure was on -- this was a _now or never_ type of situation.

Dimitri: /* 2015: End of IRATI and IRINA, PRISTINE, and the RINAiSense IoT project */

2023-11-10T11:13:00Z

2015: End of IRATI and IRINA, PRISTINE, and the RINAiSense IoT project

← Older revision		Revision as of 11:13, 10 November 2023
Line 94:		Line 94:
	By the end of summer, we were still a long way off the mark in terms of what we hoped to achieve. The traffic generator tool and configurator were ready, and the implementation of LFA was as good as done, so we could deploy the machines for the use case scenarios on the testbeds. But due to stability problems, the deployment that actually worked on IRATI was limited to about 3 nodes in a triangle that showed the traffic getting routed over the two remaining link if a link got severed.		By the end of summer, we were still a long way off the mark in terms of what we hoped to achieve. The traffic generator tool and configurator were ready, and the implementation of LFA was as good as done, so we could deploy the machines for the use case scenarios on the testbeds. But due to stability problems, the deployment that actually worked on IRATI was limited to about 3 nodes in a triangle that showed the traffic getting routed over the two remaining link if a link got severed.

	In the meantime, Vincenzo was making good progress on his own RINA implementation, [~~rlite](~~https://github.com/vmaffione/rlite), and Sander and myself started discussing options on a more and more regular basis on what to do. Should we branch off IRATI and try to clean it up? Keep only IRATI kernel space and rewrite user space? Hop on the ''rlite'' train? Or just start over entirely? Should we go user-space entirely or keep parts in-kernel?		In the meantime, Vincenzo was making good progress on his own RINA implementation, [https://github.com/vmaffione/rlite rlite], and Sander and myself started discussing options on a more and more regular basis on what to do. Should we branch off IRATI and try to clean it up? Keep only IRATI kernel space and rewrite user space? Hop on the ''rlite'' train? Or just start over entirely? Should we go user-space entirely or keep parts in-kernel?

	In the last semester of 2015, Sander was heading for a 3-month research stint at Boston University to work on routing in RINA with John Day and the BU team. By that time, we had ruled out branching off of openIRATI. Our estimate was that cleaning up the code base would be more work than starting over. We'd also have IRATI as an upstream dependency, and trying to merge contributions upstream would lead to endless discussions and further hamper progress for both projects. IRATI was out. Contributing to rlite then? Vincenzo was making progress fast, and we knew he was extremely talented and competent. But we were also afraid of running into disagreements of how to proceed. In the meantime, Sander's original research plans in Boston got subverted by a 'major review' decision on the _shim hypervisor_ article, putting his priority on getting that accepted and published. When I visited Sander in Boston at the end of October, we were again assessing the situation, and agreed that the best decision was to start our own prototype, to avoid rlite having _too many cooks in the kitchen_. Our development was not going to be part of some funded project, so we were free to evaluate and scrutinize all design decisions, and we could get feedback on the RINA mailing lists on our findings. When all considerations settled, our own RINA implementation was going to be in user-space and target POSIX.		In the last semester of 2015, Sander was heading for a 3-month research stint at Boston University to work on routing in RINA with John Day and the BU team. By that time, we had ruled out branching off of openIRATI. Our estimate was that cleaning up the code base would be more work than starting over. We'd also have IRATI as an upstream dependency, and trying to merge contributions upstream would lead to endless discussions and further hamper progress for both projects. IRATI was out. Contributing to rlite then? Vincenzo was making progress fast, and we knew he was extremely talented and competent. But we were also afraid of running into disagreements of how to proceed. In the meantime, Sander's original research plans in Boston got subverted by a 'major review' decision on the _shim hypervisor_ article, putting his priority on getting that accepted and published. When I visited Sander in Boston at the end of October, we were again assessing the situation, and agreed that the best decision was to start our own prototype, to avoid rlite having _too many cooks in the kitchen_. Our development was not going to be part of some funded project, so we were free to evaluate and scrutinize all design decisions, and we could get feedback on the RINA mailing lists on our findings. When all considerations settled, our own RINA implementation was going to be in user-space and target POSIX.

Dimitri: /* 2012: IBBT meets RINA */

2023-11-10T11:12:16Z

2012: IBBT meets RINA

← Older revision		Revision as of 11:12, 10 November 2023
Line 13:		Line 13:
	The IRATI project promised an implementation of RINA in Linux _and_ FreeBSD/JunOS, with detailed comparisons of RINA against TCP/IP in various scenarios, and also demonstrate interoperability with RINA proof-of-concept prototypes with very limited functionality: the [https://github.com/PouzinSociety/tinos \| TINOS prototype] and the [http://trianetworksystems.com/ TRIA] prototype.		The IRATI project promised an implementation of RINA in Linux _and_ FreeBSD/JunOS, with detailed comparisons of RINA against TCP/IP in various scenarios, and also demonstrate interoperability with RINA proof-of-concept prototypes with very limited functionality: the [https://github.com/PouzinSociety/tinos \| TINOS prototype] and the [http://trianetworksystems.com/ TRIA] prototype.

	The Interdisciplinary Institute for Broad-Band Technology (IBBT) -- soon to be known as iMinds, and now fully integrated in [~~IMEC](~~https://www.imec-int.com) -- had a very convincing track record in the FIRE program because of its networking testbed facilities, and was invited as a consortium member. IBBT and i2CAT were both part of a testbed project, called OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications). The IRATI project would adopt (and extend) the OFELIA testbed as its platform for experimental deployment of the RINA prototypes.		The Interdisciplinary Institute for Broad-Band Technology (IBBT) -- soon to be known as iMinds, and now fully integrated in [https://www.imec-int.com IMEC] -- had a very convincing track record in the FIRE program because of its networking testbed facilities, and was invited as a consortium member. IBBT and i2CAT were both part of a testbed project, called OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications). The IRATI project would adopt (and extend) the OFELIA testbed as its platform for experimental deployment of the RINA prototypes.

	Three partners were responsible for the new RINA implementation: i2cat, who had experience on RINA; [http://nextworks.it Nextworks], an Italian SME with expertise in networking and software development, and us at IBBT.		Three partners were responsible for the new RINA implementation: i2cat, who had experience on RINA; [http://nextworks.it Nextworks], an Italian SME with expertise in networking and software development, and us at IBBT.

Dimitri: /* 2017: Ouroboros diverges from RINA */

2023-11-10T11:11:52Z

2017: Ouroboros diverges from RINA

← Older revision		Revision as of 11:11, 10 November 2023
Line 142:		Line 142:
	Ouroboros now had a clean, crisp boundary between the flow in a ''DIF'', and any connections using that flow in the layer above. Flow allocation creates a flow between ''Application Instances'' and after that, a connection phase would create a ''connection'' between ''Application Entity Instances''. So roughly speaking -- without the OSI terminology -- first the network connects the running programs, and after that, the programs decide which protocols to use (which can be implicit). What was in the RINA specs , what the RINA API was actually doing, was mixing these exchanges! Now, we have no issues with that from an operational perspective: the Ouroboros flow allocator has a ''piggyback API''. But the contents of the piggybacked information in Ouroboros is opaque. And all this has another, even bigger, implication. One that I would only figure out via another line of reasoning some time later.		Ouroboros now had a clean, crisp boundary between the flow in a ''DIF'', and any connections using that flow in the layer above. Flow allocation creates a flow between ''Application Instances'' and after that, a connection phase would create a ''connection'' between ''Application Entity Instances''. So roughly speaking -- without the OSI terminology -- first the network connects the running programs, and after that, the programs decide which protocols to use (which can be implicit). What was in the RINA specs , what the RINA API was actually doing, was mixing these exchanges! Now, we have no issues with that from an operational perspective: the Ouroboros flow allocator has a ''piggyback API''. But the contents of the piggybacked information in Ouroboros is opaque. And all this has another, even bigger, implication. One that I would only figure out via another line of reasoning some time later.

	With ARCFIRE rolling along and the implementation of the _rumba_ framework in full swing, Sander was working on the link-state routing policy for Ouroboros, and I started implementing a ''Distributed Hash Table (DHT)'' that would serve as the directory -- think of the equivalent of [~~DNS-SRV](~~https://en.wikipedia.org/wiki/SRV_record) for a RINA DIF -- a key-value store mapping ''application names'' to ''addresses''. The link-state routing component was something that was really closely related to the Resource Information Base -- the RIB. That RIB was closely coupled with CDAP. Remember that prediction that I made about a year prior, somewhere in April 2016? On September 9th 2017, two weeks before the ARCFIRE RINA hackathon, [https://ouroboros.rocks/cgit/ouroboros/commit/?id=45c6615484ffe347654c34decb72ff1ef9bde0f3&h=master CDAP was removed from Ouroboros]. From that point, Ouroboros could definitely not be considered a RINA implementation anymore.		With ARCFIRE rolling along and the implementation of the _rumba_ framework in full swing, Sander was working on the link-state routing policy for Ouroboros, and I started implementing a ''Distributed Hash Table (DHT)'' that would serve as the directory -- think of the equivalent of [https://en.wikipedia.org/wiki/SRV_record DNS SRV] for a RINA DIF -- a key-value store mapping ''application names'' to ''addresses''. The link-state routing component was something that was really closely related to the Resource Information Base -- the RIB. That RIB was closely coupled with CDAP. Remember that prediction that I made about a year prior, somewhere in April 2016? On September 9th 2017, two weeks before the ARCFIRE RINA hackathon, [https://ouroboros.rocks/cgit/ouroboros/commit/?id=45c6615484ffe347654c34decb72ff1ef9bde0f3&h=master CDAP was removed from Ouroboros]. From that point, Ouroboros could definitely not be considered a RINA implementation anymore.

	It was time to get started on the last big component: DTCP -- the ''Data Transfer Control Protocol''. When implementing this, a couple of things were again quickly becoming clear. First, the implementation was proving to be completely independent of DTP. The RINA ''specs'' propose a state vector between DTP and DTCP. This solves the ''IP fragmentation problem'' -- if an IP fragment gets lost, TCP would resend all fragments. Hence TCP needs to know about the fragmentation in IP and only retransmit the bytes in that fragment. But the code was again speaking otherwise. It was basically telling us: TCP was independent of IP. But fragmentation should be in TCP, and IP should specify its maximum packet size. Anything else would result in an intolerable mess. So that's how we split the ''Flow and Retransmission Control Protocol'' (FRCP) and the ''Data Transfer Protocol''(DTP) in Ouroboros.		It was time to get started on the last big component: DTCP -- the ''Data Transfer Control Protocol''. When implementing this, a couple of things were again quickly becoming clear. First, the implementation was proving to be completely independent of DTP. The RINA ''specs'' propose a state vector between DTP and DTCP. This solves the ''IP fragmentation problem'' -- if an IP fragment gets lost, TCP would resend all fragments. Hence TCP needs to know about the fragmentation in IP and only retransmit the bytes in that fragment. But the code was again speaking otherwise. It was basically telling us: TCP was independent of IP. But fragmentation should be in TCP, and IP should specify its maximum packet size. Anything else would result in an intolerable mess. So that's how we split the ''Flow and Retransmission Control Protocol'' (FRCP) and the ''Data Transfer Protocol''(DTP) in Ouroboros.
Line 154:		Line 154:
	But we were still running against the clock. ARCFIRE was soon to end, and Ouroboros had undergone quite some unanticipated changes that meant the implementation was also facing the reality of [https://en.wikipedia.org/wiki/Hofstadter%27s_law Hofstadter's Law].		But we were still running against the clock. ARCFIRE was soon to end, and Ouroboros had undergone quite some unanticipated changes that meant the implementation was also facing the reality of [https://en.wikipedia.org/wiki/Hofstadter%27s_law Hofstadter's Law].

	We were again under pressure to get some publications out; in order to meet ARCFIRE objectives, and Sander had to meet some publication quota to finish his PhD. The design of [[Rumba]] was interesting enough for a [paper~~](https://www.geni.net/)~~, the implementation allowed us to deploy 3 Recursive Network prototypes (IRATI, rlite and Ouroboros) on testeds using different APIs: jFed for Fed4Fire and [~~GENI](~~https://www.geni.net/), Emulab for iMinds virtual wall testbed, QEMU using virtual machines, docker using -- well -- docker containers, and a local option only for Ouroboros. But we needed more publications, so for ARCFIRE Sander had implemented Loop-Free Alternates routing in Ouroboros and was getting some larger-scale results with them. And I reluctantly started working on a paper on Ouroboros -- I still felt the time wasn't right, and we first needed to have a full FRCP implementation and full congestion avoidance to make a worthwile analysis.		We were again under pressure to get some publications out; in order to meet ARCFIRE objectives, and Sander had to meet some publication quota to finish his PhD. The design of [[Rumba]] was interesting enough for a paper, the implementation allowed us to deploy 3 Recursive Network prototypes (IRATI, rlite and Ouroboros) on testeds using different APIs: jFed for Fed4Fire and [https://www.geni.net/ GENI], Emulab for iMinds virtual wall testbed, QEMU using virtual machines, docker using -- well -- docker containers, and a local option only for Ouroboros. But we needed more publications, so for ARCFIRE Sander had implemented Loop-Free Alternates routing in Ouroboros and was getting some larger-scale results with them. And I reluctantly started working on a paper on Ouroboros -- I still felt the time wasn't right, and we first needed to have a full FRCP implementation and full congestion avoidance to make a worthwile analysis.

	We finished the experiments for ARCFIRE, but as with PRISTINE, the results were not accepted for publication. During the writing of the paper, a final realization came. We had implemented our link-state routing a while ago, and it was doing something interesting, akin to all link-state routing protocols: a link-state packet that came in on some flow, was sent out on all other flows. It was -- in effect --doing broadcast. But... OSPF is doing the same. Wait a minute. OSPF uses a multicast IP address. But of course! Multicast wasn't what it seemed to be. Multicast was broadcast on a layer, creating a multicast group was enrollment in that layer. A multicast IP address is a broadcast Layer name! Based on the link-state routing code in the ''normal IPCP'', I implemented the broadcast IPCP in a single night. The ''normal IPCP'' was renamed ''unicast IPCP''. It had all fallen into place, the Ouroboros architecture was shaped.		We finished the experiments for ARCFIRE, but as with PRISTINE, the results were not accepted for publication. During the writing of the paper, a final realization came. We had implemented our link-state routing a while ago, and it was doing something interesting, akin to all link-state routing protocols: a link-state packet that came in on some flow, was sent out on all other flows. It was -- in effect --doing broadcast. But... OSPF is doing the same. Wait a minute. OSPF uses a multicast IP address. But of course! Multicast wasn't what it seemed to be. Multicast was broadcast on a layer, creating a multicast group was enrollment in that layer. A multicast IP address is a broadcast Layer name! Based on the link-state routing code in the ''normal IPCP'', I implemented the broadcast IPCP in a single night. The ''normal IPCP'' was renamed ''unicast IPCP''. It had all fallen into place, the Ouroboros architecture was shaped.

Dimitri at 11:10, 10 November 2023

2023-11-10T11:10:05Z

Show changes

Dimitri at 09:47, 10 November 2023

2023-11-10T09:47:12Z

← Older revision		Revision as of 09:47, 10 November 2023
Line 3:		Line 3:
	Disclaimer: this article expresses the view of its author.		Disclaimer: this article expresses the view of its author.

	The origin of the [[Ouroboros \| Ouroboros project]] lies within European-funded research and experiences implementing [[RINA]]. These research projects started off as validation projects for the ideas that are embedded in the 2007 book [https://www.oreilly.com/library/view/patterns-in-network/9780132252423/ Patterns in Network Architecture]. After initial experiences, it became clear that software development within research projects has its limitations, and 2 parties that were working on the [https://github.com/IRATI/stack OpenIRATI prototype] decided to roll their own RINA projects: Vincenzo Maffione at Nextworks started [https://github.com/vmaffione/rlite rlite] and we at IMEC started Ouroboros. ''rlite'' stayed more-or-less true to RINA specifications, but our ambition was to fully retrace the ''methodology'' that John Day introduced to arrive at the RINA architecture, rather than start from its conclusions. We started from scratch, without any bias towards any predetermined outcomes, and treaded lightly.		The origin of the [[Ouroboros \| Ouroboros project]] lies within European-funded research and experiences implementing [[RINA]]. These research projects started off as validation projects for the ideas that are embedded in the 2007 book [https://www.oreilly.com/library/view/patterns-in-network/9780132252423/ Patterns in Network Architecture]. After initial experiences, it became clear that software development within research projects has its limitations, and 2 parties that were working on the [https://github.com/IRATI/stack OpenIRATI prototype] decided to roll their own RINA projects: Vincenzo Maffione at Nextworks started [https://github.com/vmaffione/rlite rlite] and we at IMEC started Ouroboros. ''rlite'' stayed more-or-less true to RINA specifications, but our ambition was to fully retrace the ''methodology'' that John Day introduced to arrive at the RINA architecture, rather than start from its conclusions. We started from scratch, without any bias towards any predetermined outcomes, and treaded lightly. This is a more detailed account for those interested in the back story.

	=== 2012: IBBT meets RINA ===		=== 2012: IBBT meets RINA ===
Line 13:		Line 13:
	The IRATI project promised an implementation of RINA in Linux _and_ FreeBSD/JunOS, with detailed comparisons of RINA against TCP/IP in various scenarios, and also demonstrate interoperability with RINA proof-of-concept prototypes with very limited functionality: the [https://github.com/PouzinSociety/tinos \| TINOS prototype] and the [http://trianetworksystems.com/ TRIA] prototype.		The IRATI project promised an implementation of RINA in Linux _and_ FreeBSD/JunOS, with detailed comparisons of RINA against TCP/IP in various scenarios, and also demonstrate interoperability with RINA proof-of-concept prototypes with very limited functionality: the [https://github.com/PouzinSociety/tinos \| TINOS prototype] and the [http://trianetworksystems.com/ TRIA] prototype.

	The Interdisciplinary Institute for Broad-Band Technology (IBBT) -- soon to be known as iMinds, and now fully integrated in [IMEC](https://www.imec-int.com) -- had a very convincing track record in the FIRE program because of its networking testbed facilities, and was invited as a consortium member. IBBT and i2CAT were both part of a testbed project, called OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications). IRATI would adopt (and extend) the OFELIA testbed as its platform for experimental deployment of the RINA prototypes.		The Interdisciplinary Institute for Broad-Band Technology (IBBT) -- soon to be known as iMinds, and now fully integrated in [IMEC](https://www.imec-int.com) -- had a very convincing track record in the FIRE program because of its networking testbed facilities, and was invited as a consortium member. IBBT and i2CAT were both part of a testbed project, called OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications). The IRATI project would adopt (and extend) the OFELIA testbed as its platform for experimental deployment of the RINA prototypes.

	Three partners were responsible for the new RINA implementation: i2cat, who had experience on RINA; [http://nextworks.it Nextworks], an Italian SME with expertise in networking and software development, and IBBT.		Three partners were responsible for the new RINA implementation: i2cat, who had experience on RINA; [http://nextworks.it Nextworks], an Italian SME with expertise in networking and software development, and us at IBBT.

	The Italian branch of Interoute (now part of [https://gtt.net GTT]), Europe's largest Cloud Service Platform provider had a role in the project overseeing its use-cases, and Boston University (BU) joined as an unfunded partner with an advisory role.		The Italian branch of Interoute (now part of [https://gtt.net GTT]), Europe's largest Cloud Service Platform provider had a role in the project overseeing its use-cases, and Boston University (BU) joined as an unfunded partner with an advisory role.

	The project ~~had~~ three phases, each started with development activities followed by experimentation. Phase I was projected to end in November 2013 (initial closed source prototype, demonstrate capabilities comparable to TCP/IP), Phase II in June 2014 (open source prototype, demonstrate capabilities beyond TCP/IP) and Phase III was to conclude in December 2014 (final prototype, complete implementation, demonstrate interoperability with previous RINA prototypes) with the end of the project.		The project was subdivided in three phases, each started with development activities followed by experimentation. Phase I was projected to end in November 2013 (initial closed source prototype, demonstrate capabilities comparable to TCP/IP), Phase II in June 2014 (open source prototype, demonstrate capabilities beyond TCP/IP) and Phase III was to conclude in December 2014 (final prototype, complete implementation, demonstrate interoperability with previous RINA prototypes) with the end of the project.

	== 2013: IRATI Phase I ==		== 2013: IRATI Phase I ==