RSS

Why is this better than IP?

The problem with the Internet isn’t that it’s wrong, it’s that it’s almost right. – John Day

With the COVID-19 pandemic raging on at its current peak all over the world, it has been a weird couple of months for most of us. In the last few weeks I did a first implementation of the missing part of the FRCP protocol (retransmission and flow control, fragmentation is still needed), and I hope to get congestion control done by the end of the year, which is very needed because with the retransmission the prototype experiences congestion collapse on a bottleneck caused by the bandwidth of the shared memory allocator we implemented. Then I can finally get rid of the many annoying bugs, stabilize the prototype, and then implement a better allocator. But this is not the main thing I wanted to adress.

I’ve also been pondering the question I always get from network engineers. It’s the one that annoys me the most, because it seems that first this question needs to be answered for the questioner to even consider taking any attempt or spending any effort in trying to understand the body of work presented. This question is, of course, Why is this better than IP?

Now,there are two things we did when building Ouroboros. The most visible is the prototype implementation, but behind it is a network model. This network model is not some arbitrary engineering excercise, we tried to find the minimum required and sufficient conditions for networking, mathematically. In this sense – under the precondition that the model is correct1 – every working network has to fulfill the model, like it or not. It’s not a choice one can take or leave. I’ll try to find more time (and to be perfectly honest: the motivation) in the next couple of weeks to get this aspect across with more clarity and precision than with which it is currently presented in the paper.

Now, I would argue that the current Internet with all its technologies (TCP/IP, VPNs, MPLS, QUIC, …) is closer to the model we derived than it is to the 7-layer-model. NASA’s DTNs don’t violate the model2. RINA is of course very close to the model, as it also predicts the recursive nature of networks. The prototype is an implementation of the model (and thus in some way, close to a minimal network).

While the model predicts recursive layering, it doesn’t forbid engineers to use different APIs for each layer, mix and combine layers into logical constructs, expose layer internals, rewrite packet headers, and do whatever they please. It may have economical benefits for an engineer to put a solution in whatever logical part of the network, hack in an API to expose what the solution needs and then sell it. But this engineering comes at the cost of adding complexity without functionality.

I’ll use an analogy from programming: a simple C for loop uses an index variable, typically named “i”. It is generally seen as bad practice to modify this index variable inside the loop, something like this.

for (int i = 1; i <= 10; ++i) {
        if(i == 2)
                i = 4;
        /* Do some work */
}

But is such code “worse” than another solution to skip 2 and 3, such as this?

for (int i = 1; i <= 10; ++i) {
         if(i == 2 || i == 3)
                 continue;
         /* Do some work */
}

The reason it is considered bad practice, is based on years of programming experience: thousands of programmers noticing that such constructs often lead to bugs and lower maintainability3. I would argue that the Internet is full of this kind of bad practices – it doesn’t take a huge stretch of the imagination to take the example above as an analogy for Network Address Translation (NAT). Of course, NAT is probably the only way to stretch the IPv4 address space beyond its natural limits. But in an ideal networking world (which is our objective), one shouldn’t break end-to-end and consider addresses immutable.

And that’s why I think Ouroboros is a “good” network model. If the minimal necessary and sufficient conditions for networking are understood as a consistent model for networks, we can better assess where engineering decisions have been made that add complexity without objectively adding functionality to the whole. Unfortunately, there aren’t many scientists that design networking solutions from the ground up, so there isn’t much experience to go around.

So then, is Ouroboros better than IP? From an engineering perspective, maybe not, or not by much. But I’m fine with that, it’s not my objective.

Keep safe social distancing, take care and stay curious.

Dimitri

P.S. Of course, I was curious about what the GCC compiler does with the source code examples above. It does seems like the “better” solution also optimizing a bit better:


  1. Of all the comments from peer review, not a single one has addressed any technical issues – let alone correctness – of the model. Most are that I fail to justify why the reviewer should bother to read the article or make an effort to try to understand it as it doesn’t fit current engineering workflows and thus has little chance of short-term deployment. Sorry, but I don’t care. [return]
  2. I came across this when thinking about the limits for the timers for retransmission. A DTN is basically two layers, one without retransmission on top of one with retransmission at very long timeouts. [return]
  3. With modern programming languages leaning more and more towards discouraging mutables alltogether. [return]