If TCP/IP is the piston airplane, RINA is the jet age. At the moment, it’s exotic; in 20 years, it will be ordinary. Here’s an update on its progress.
Peter Thompson of Predictable Network Solutions Ltd describes the large-scale distributed applications problem that RINA solves uniquely well.
As promised in my previous newsletter, here is my write-up of the 5th international RINA Workshop at Barcelona. I attended the first day only, as the second day was “down in the weeds” of execution, and I’ve spent many years diligently avoiding having to learn the details of another API. I did quite enough of that in the 1980s and 1990s.
For those unfamiliar with Recursive InterNet Architecture (RINA), you can read my previous work:
- Network architecture research: TCP/IP vs RINA, from the 2013 workshop.
- A new kind of network: RINA progress update, from 2016.
- My annotated presentation from this 2018 workshop.
In brief, RINA is a universal framework for distributed computing that subsumes many existing technologies. These either address a piece-part of the problem (e.g. NFV, SON), or act as a workaround for missing base functionality (e.g. VPNs, NAT, firewalls). RINA is the absolute state of the art in computer science, since it is about applying the power of abstraction to its theoretical maximum.
Whilst TCP/IP is sold as being very simple in design, in reality it is extremely complex to manage in operation. IPv6 in particular lacks a business case, since it doesn’t solve the most important problems (e.g. packet header overhead on cellular), and makes others worse (e.g. security attack surface). It’s obsolete by inception, since it gets the basic structure wrong, so has taken 20 years to get not very far. RINA fixes the foundations, so we can build more impressive systems, reaching scales and cost points previously unattainable
The headline from this workshop is that the TCP/IP world is moving towards a RINA-like view of architecture (by necessity), and RINA is finding early applications in the new class of DAPPS (large-scale distributed applications) like blockchain. We have always had DAPPS, such as DNS and CDNs, but they have hitherto been implemented as one-off hand-crafted solutions. RINA is a generalised solution grounded in strong theory.
Since I attended my first RINA workshop in 2013, the RINA-based technology has matured significantly. There are multiple RINA API implementations, prototypes of all the key value propositions, fully operational testbeds and test traffic generators, hackathon examples of engaged developers, and clear use cases with immediate industrial application. There are demos of how to transport RINA datagrams over existing chipsets, tunnel it under and over existing protocols, and a roadmap to exploit new capabilities like P4-programmable routers.
RINA is at the transition from “will this work?” to “how can we use this productively?”. Ericsson has long been involved, Ciena are looking at RINA-based research programme for a self-optimising fabric, Vodafone are engaged in lab trials, and Telefonica are exploring where it fits into their cosmos. Any forward-looking organisation in telco and cloud with a technology scouting function should have this on their target list.
That this above presentation exists at all is as significant as its content. Admittedly, the presenter has a networking PhD, but those are — I am reliably informed — relatively common. This is a skill you can hire for, albeit from a talent puddle rather than pool.
Example opportunities for RINA include:
- Android and iOS API to simplify various network scenarios, so that the application association is maintained regardless of changes of the underlying bearer (e.g. switches between WiFi and cellular, bonding thereof).
- Simplifying network management (e.g. adding cell towers or other elements) and speeding up policy changes (e.g. when merging networks).
- Message queues and similar event-driven distributed systems, adding performance and location independence.
- Alternatives to the ICANN rent-seeking empire of domain names and TLDs, where you can own your identity as a self-sovereign entity and rent its networked delivery into the world.
- Managed enterprise overlays and virtual networks, such as those offered by the ngena operator consortium.
- Cleaning up some of the horrors of IMS and VoLTE where legacy decision in the 2G/3G era resulted in an explosion of signalling and media management complexity.
So you’ve had the headline and overview. Let’s delve into some of the nuggets from the day.
In theory 5G would benefit greatly from RINA, but my sense is that 5G needs RINA more than RINA needs 5G. The cellular ecosystem is trying to perpetuate an end-of-life model of service delivery that forces users into a legacy identity, protocol and billing approaches. So whilst you could in theory solve the network slicing problem with RINA, by the time 5G has figured it out I would expect those use cases to be 80% solved by other competing technologies.
Tthe list of show-stoppers for 5G is about as long as the list of features, and the business case is looking weaker by the week. I could imagine someone like Amazon or (horror!) Facebook bypassing the present cellular model entirely in the next 5-10 years.
These novel delivery systems may evolve out of existing WiFi and industrial control systems for indoors, or new ones that bypass the ground-based network for outdoors (e.g. balloons, low-orbit micro satellite). As Nokia showed us with the iPhone, pride comes before a fall. RINA could easily help new competition to leapfrog the incumbent ecosystem.
In the meantime, the IETF is facing the inevitable problems of having ignored fundamental science issues for decades. In a “good news – bad news” way, they have the right initiatives (to establish new transport protocols and management scopes), but lack the architecture framework to deliver the answer. There is an opportunity here for a detente between TCP/IP and RINA, but this requires transcending the history and feuds that led us here.
The significance of this particular slide will only be evident to a very few people, but it is in fact the most bleeding edge piece of applied research you can find. It combines:
- the world’s most advanced architecture (RINA) with
- the world’s most advanced packet scheduler (the Contention Manager using a cherish-urgency multiplexer [PDF]), to jointly deliver
- the world’s most precision-engineered packet network quality (to a statistical specification).
This proposes a research lab proof-of-concept, not a product, but the potential for disruption is self-evident to those in the know.
Something that caught the attention of many attendees was this “Towers of Hanoi” method of visualising RINA networks. With TCP/IP we have a “beads on a string model”, which you can draw with crayons as boxes and lines that represent the implementation mechanisms.
In contrast, RINA (as the name suggests) uses nested scopes, which represent the functional outcomes. The implementation of each scope is hidden from adjacent layers. It’s a “Russian doll of concatenated information photocopiers”, if that makes any sense. Inside each photocopier is… yet more photocopiers. A piece of wire is just a hardware implementation of the “copy data” API.
The above charting innovation is a simple thing, but really brings the essential difference to life. The challenge now is to create software tools more potent than Powerpoint for creating these charts!
Speaking of managing to scopes, bravo to BT, who have grasped the retrospectively obvious truth: it’s not a good idea for someone in Algeria to be able to claim arbitrary network resources in Argentina. Their slicing architecture has the right concepts in the mix (see “recursive slice composition”), so RINA might be a natural fit down the road… although that’s still a few years off. Scopes naturally limit the screw-ups you can engage in: to err is human, but to really #fail you need an SDN controller with a single universal scope.
“The fundamental structure of distributed computing is recursive with two degrees of freedom.” — That’s the most important statement in computer science that isn’t currently in the textbooks. RINA deals with the recursive bit, and ∆Q is the framework to manage the two degrees of freedom (among load, loss and delay). The conjunction of RINA with ∆Q is an “obvious” one (with enormous hindsight, shoulders of giants, etc.). It’s like how rocketry is what happens when ballistics and chemistry get together for a party. Seems like Vodafone here want to go into orbit.
The room contained quite a number of the top computer scientists on this space rock. One person present was Louis Pouzin, who rightly has been honoured as a co-inventor of packet networking. He is now working on open-root, an alternative to today’s DNS — a source of “protocol usury” that traps people into “identity debt”. A collateral benefit of using RINA for these new applications is that it makes them a total pain for tyrannical regimes to monitor.
You might easily miss something rather remarkable here: “Build in performance as a first-class design objective”. That this is novel and groundbreaking tells you a lot about how far networking still has to go.
Imagine if we built bridges, and accepted that a 5% failure rate was normal. The KPI would be “bodies floating in water”, and we’d monitor downstream for corpses. That’s pretty much what we have for packet networking. We build stuff, load it up, and find out in operation whether it actually works. The “safety case” is built on having a sufficient remaining stock of body bags.
RINA is an abstraction framework that naturally allows for system invariants that can be reasoned about: performance, security, optimality, compliance, etc. This is the basic enabling step to engage in proper engineering: an up-front safety case you can depend upon. The general public knows we aren’t doing it — broadband is notoriously unpredictable and variable — but it’s hard for industry insiders to accept the loss of face.
Blockchain platforms like Cardano, where real synthetic money is at stake, give us the harsh incentive to solve these hard computer science problems.
RINA is still at the stage of “98% slides with bullet points, dense text, and complex diagrams with lots of blobs and lines”. It’s only 2% “stock photo images and slick marketing touting buyable products with immediate benefits”. This technology is maybe 5 years into a 25 year journey of awareness and mainstream adoption. The first hit products are still a few years away, once we’ve done some pilot bespoke projects.
That said, the RINA revolution is clearly “ready to roll”. Internet Protocol itself is now becoming a constraining factor to progress. Blockchain provides RINA with its compelling “killer distributed app” use case. Migration of existing DAPPS (DNS, CDNs, service monitoring, and pretty much any virtual network function ever thought of) will be a natural adoption path for operators who have few other options.
RINA may also be a saviour for many use cases that 5G has been touted for (like factory automation) but will fail to deliver at the reliability, cost and scale being demanded. You have to design systems up-front for “provably correct” operation, and this is unlikely to be retrofitted to the 3GPP stack. It’s not impossible — IBM did formal correctness proofs for CICS back in the day — but it’s the exception.
The weakest part of RINA — but with the biggest long-term impact — is QoS management. The framing of “congestion control” fundamentally misreads the essential nature of the problem, adn it’s easy to unwittingly carry over the sins of TCP/IP into the RINA world. That is because the discipline of network performance engineering itself is immature.
The mechanisms needed to schedule traffic with an engineered safety margin are absolutely novel. RINA makes this into a “novelty squared” problem, requiring two of the rarest skill sets in networking. However, once solved and scaled, it will be world-changing: what the laser did for transmission capacity, RINA+∆Q does for quality control and lean operation.
As a final thought, my sense is that much of RINA’s thinking processes will get incorporated into existing products and technologies, but won’t necessarily be called RINA. It’s an architecture framework, not a protocol, and it can be used and implemented in many ways. Its success may paradoxically come from eventual obscurity: didn’t we always do things this way?
For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.
Read It Now
