Beyond OSI: The ‘Four Things’ Model Of Networking

In my previous post on models, I explained why I don’t find the OSI model very useful in day-to-day work—even if it is the traditional “thing to learn” when you learn networking. It’s impossible to work without models because models give structure to thought. Just as I would be lost without a map, I would be lost without a model.

Before describing my modeling habits, though, I’d like to make three points.

First, models are not sacrosanct. A model is just a tool. If the model you are using is not working for you, feel free to modify it. I find simpler yet extensible models far more effective than complex models for channeling my thoughts. In the past I have tried building huge models that “put everything in one place,” but they do not work for me.

Second, models should have a purpose. I prefer models that help me ask questions rather than models that carry an explanation within themselves.

Third, I do not feel the need to have just one model. I use four different models for different parts of the network:

• Network transport
• Routers and other middleboxes
• Routing protocols and other control planes
• Hosts

I plan to write on these models through this series—and maybe toss in a few other things, like thinking about modularization, tradeoffs, and complexity.

Let’s start with the “Four Things” model, which is somewhat like the OSI model. This model is roughly based on the Recursive InterNetwork Architecture (RINA) approach. However, I’m not so concerned about figuring out how many layers there should be, and I’ve extended the model beyond the basic RINA model. The figure below illustrates the basic concept.

There are three layers here—interface-to-interface, host-to-host, and application-to-application. According to the RINA model, four problems need to be solved at each of these layers: marshaling/formatting, multiplexing, flow control, and error control.

1. Marshaling or formatting data so the sender can transmit data the receiver understands
2. Multiplexing to allow more than two hosts to talk over the same physical or logical circuit at the same time
3. Flow control to make certain the transmitter does not send data faster than the receiver can consume it
4. Error control to make sure data is not changed or damaged while transiting from the sender to the receiver

Each pair of these problems is typically solved within one protocol—multiplexing and marshaling are solved in one protocol, flow and error control in another. Tying this to TCP/IP looks something like this:

• Ethernet contains two protocols, physical and data link, each of which solves two of these four problems for interface-to-interface communication
• IP solves multiplexing and marshaling for host-to-to-host communication
• TCP solves error and flow control for host-to-host communication
• TCP solves multiplexing and (some part of) flow control for application-to-application
• HTML solves marshaling, error control, and flow control for application-to-application

The mapping is imperfect—no mapping between a model and protocols will ever be perfect. However, even this rather rough mapping allows me to ask a lot of questions, such as:

• How is multiplexing solved at the host level, selecting between applications?
• How is multiplexing solved between multiple protocols running on IP?
• What should flow control be doing in this HTML stream?

As stated above, the point is not to have precision but rather a mental map. If I ask these four questions about any protocol or set of protocols, I can quickly understand how the protocol works—and how the protocol interacts with the network.

Asking these questions is also very useful in troubleshooting—which of these four functions fails to cause the problem I’m trying to solve?

So far, we’re pretty much tracking with the RINA model, although I’ve “loosened it up” a small amount, moving from a “this is a proper architecture” tool to “this is how the architecture I’m looking at works” tool.

The next step is to extend the model a little to help us ask better questions. Saying, “I know each protocol must solve these four problems for one layer of connectivity,” is helpful, but we can create something more useful. The figure below shows a model of Four Things.

What we’ve done here is added in the possible solution or sub-problem space for each of the four problems.

• Multiplexing requires us to solve three sub-problems—naming, mapping, and routing
• Marshaling requires us to solve three problems—encoding, a shared dictionary and grammar, and (in some cases) a way to protect transmitted data
• Error control gives you three choices for a transmission error—drop it, ask for retransmission, or try to correct it
• There are only three ways to handle flow control—windows, queues, and dropping the data

Using this extended model, I can understand any protocol very quickly. I can ask:

• What kind of protocol is this? Where does it operate in the stack?
• Which of the four problems does it solve?
• Does it have a “partner protocol” that solves the remaining problems?
• What combination of possible solutions does it use to solve these problems?

As far as I know, this small chart encompasses the entire problem and solution space of transporting data across a network. I’ll talk more about models in an upcoming post.