Does the world need a general purpose alternative to IP networking?
I suspect that in any applications where IP is not the best choice, the best choice will be a minimal protocol that doesn't try to reimplements everything IP does.
I think the argument is that IP is pretty much never the best choice due to a slew of architectural decisions that turned out not to be great in hindsight (or, at least according to Day, sometimes in foresight). Things like buffet bloat, device/service mobility, difficulty upgrading infrastructure (see: IPv6) and unbounded routing tables in devices are symptoms of this. RINA is also a lot architecturally simpler than the current Internet stack while (theoretically?) maintaining or improving on its performance advantages, so it is indeed in some sense a more minimal protocol than TCP/IP — albeit one that doesn't (as far as I know) sacrifice any functionality :)
The main argument for using IP over something like RINA is just inertia: a lot of software and, worse, hardware is built assuming IP (and even more specific things, like TCP over IPv4 over Ethernet). Ironically, the difficulty of adopting incremental improvements to IP is due to the same architectural constraints that make people want to abstract over it or replace it: in a RINA-like architecture, something equivalent to the IPv4→IPv6 shift could be rolled out incrementally without connected systems having to be aware.
There are a variety of workarounds in the wild, mostly built as additional layers piled on top of IP: VPNs that present themselves as Ethernet layers (but really run on top of UDP/IP), software-defined networking at the HTTP level (very popular in the DevOps world), etc. fly.io has a particularly neat hack where IP addresses are hijacked as service identifiers. But they all come with complexity and/or performance costs. In scenarios where performance is important, you see alternative protocols in place like RDMA (HPC) or DCTCP (intra–data centre communication).
Interestingly because RINA is fully encapsulated you can run it on top of IP as a replacement for the software-defined VPN or HTTP stacks we currently use, with the intention of gradually building downwards.
[Ouroboros](https://ouroboros.rocks/), which gets mentioned here occasionally, is a newer, more experimental network architecture that is spiritually and technically related to RINA.
2 comments
[ 3.1 ms ] story [ 14.8 ms ] threadI suspect that in any applications where IP is not the best choice, the best choice will be a minimal protocol that doesn't try to reimplements everything IP does.
The main argument for using IP over something like RINA is just inertia: a lot of software and, worse, hardware is built assuming IP (and even more specific things, like TCP over IPv4 over Ethernet). Ironically, the difficulty of adopting incremental improvements to IP is due to the same architectural constraints that make people want to abstract over it or replace it: in a RINA-like architecture, something equivalent to the IPv4→IPv6 shift could be rolled out incrementally without connected systems having to be aware.
There are a variety of workarounds in the wild, mostly built as additional layers piled on top of IP: VPNs that present themselves as Ethernet layers (but really run on top of UDP/IP), software-defined networking at the HTTP level (very popular in the DevOps world), etc. fly.io has a particularly neat hack where IP addresses are hijacked as service identifiers. But they all come with complexity and/or performance costs. In scenarios where performance is important, you see alternative protocols in place like RDMA (HPC) or DCTCP (intra–data centre communication).
Interestingly because RINA is fully encapsulated you can run it on top of IP as a replacement for the software-defined VPN or HTTP stacks we currently use, with the intention of gradually building downwards.
[Ouroboros](https://ouroboros.rocks/), which gets mentioned here occasionally, is a newer, more experimental network architecture that is spiritually and technically related to RINA.