RINA: A Clean-slate Internet Architecture

18 Jan 2014

I've begun work on a project with a professor at BU this semester that I'm really excited about. My prof, John Day, along with two others and a slew of PhD students have been working on RINA, a clean-slate Internet architecture. For the next few months, I'll be implementing a web UI that will allow developers to customize a flow (connection) to meet their applications' needs.

Let's compare the needs of an application like Skype vs. a torrenting application. When we use a service like Skype, nothing is more irritating than asking someone "what's up?" and then staring at them for ten seconds while they stare back, then finally go "not much." In terms of sending data, this means what we care most about is timeliness of delivery. We want routers to forward packets as fast as possible. If a packet gets lost or corrupted, we don't necessarily want to sit around waiting for a retransmission, we just want to get the next one there as fast as possible to sustain the "real-time" experience.

This is an extremely different quality of service than what we would expect from our torrenting application. If someone is downloading a movie, what would they prefer? An ETA of one hour with an image that gets scrambled every ten to fifteen minutes and occasionally garbled audio, or an ETA of two hours with a solid picture? What we care about here is the integrity of the data. Every flipped bit, every lost packet should be retransmitted.

One of the principles behind RINA's design is the idea of separation of mechanism and policy that as far as I'm aware, originates from operating systems design. At any point that a decision must be made about what to do with data, it is the policy that dictates whatever action is taken. So the example above describes two possible policies for the data retransmission mechanism. For something like Skype, the policy is simply "Don't bother!" For something like our torrenting application, the policy is "Do bother!" but that's really only scratching the surface. Policies will go on to affect things like how a receiver detects a lost or damaged packet in the first place, whether packets may or may not be accepted out of order and all sorts of other good stuff.

As of now, I envision this UI as a sort of interactive API documentation -- a tool that constructs calls for a user at the same as providing definitions and suggestions. We'll see how far I actually get!