I learned the Open Systems Interconnect (OSI) model way back in the mid-1980s, as a part of my basic networking education. Ever since then, I’ve used the OSI model in my day-to-day work as a network engineer.
Or maybe not.
Looking back at my career in network engineering, beyond some basic concepts and naming conventions, I cannot remember using the OSI model once. I have used the concept of layering, but never the OSI model specifically.
But people tell me the OSI model is so useful for troubleshooting network problems. How? Maybe this: The network layer must run on top of a functioning data link layer, which must run on top of a functioning physical layer, for the network to carry data from one host to another.
The idea that IP runs on top of some physical link or is useful in troubleshooting, of course—but this is a general layering principle common to all network models, not something unique to the OSI model. What else does the OSI model add to the basic concept of layering?
I have never said—to anyone—“this protocol runs at the physical layer, so it should …” Or “this protocol runs at the network layer, which means this is how must work.” I’ve never said: “This protocol is at the presentation layer, so it solves …”
As far as I can tell, the OSI model tells me a lot about interfaces, but it does not tell me about the problem being solved, the possible scope of the solution, or how the problem is being solved. The OSI model tells me there are layers, and these layers have interfaces—nothing more, and nothing less.
If the OSI model doesn’t really help me understand what each layer does, or what problems each layer solves, is it useful for building protocols? I have developed, and been involved in the development and modification, of multiple protocols across these last thirty years. I cannot remember a time when anyone referenced the OSI model to solve a problem. It is useful to know that IP should call a socket to send packets across an Ethernet link, and TCP should call a socket to send segments across IP, but these are, again, generic layering concepts, not restricted to the OSI model.
It is not just that the OSI model doesn’t add a lot of useful information to my thoughts about networking. It can also add unnecessary confusion.
A lot of ink—digital and physical—has been spilled over the years discussing which protocols fit into which layer. For instance:
- Ethernet is both the physical and data link layers. Shouldn’t this be two protocols? Can you troubleshoot or manage each of these protocols separately? Or should we just “merge” these two layers?
- TCP carries a socket number that selects which application gets the data and emulates a stream of data rather than tossing data to the application in discrete things called segments. Aren’t these things “presenting” the data to the application? Well, it depends … is TCP running under HTTP or FTP? If TCP is running under HTTP, then it’s “just” the transport layer. If TCP is running under FTP, it is both the transport and presentation layers, it seems (?).
- Which layer of the stack is BGP? OSPF? IS-IS? What justification can you give for each possible layer in each case?
At least when Medieval schools discussed how many angels can fit on the head of a pin there was a point to the discussion—differentiating between the attributes of corporeal and non-corporeal beings. What new information is any discussion over which protocol fits where adding to broader pool of networking knowledge?
Nothing I can see.
To add even more confusion, how do we deal with tunneling in the OSI model? The simplest way to explain a tunnel is when a lower layer protocol is encapsulated into another protocol at the same or higher layer, specifically to hide the encapsulated protocol information from middleboxes. You cannot describe tunneling in the OSI model this way, though, because there is no concept of a “layer within a layer.” Recursion does not exist in the OSI model, in part because the OSI model describes interfaces rather than functionality.
None of this is to say we should no longer teach the OSI model—only that I do not find the OSI model particularly useful in designing, building, or managing networks, protocols, or protocol stacks.
What the OSI model is good for is teaching the basic idea of layering, especially the concepts of interface-to-interface, host-to-host, and application-to-application. Just like when you teach the concept of division, some people will “get it” when you explain long division, and others will “get it” when you use apples. There is no way to tell who will “get it” using one explanation or another, so you use both. Some people will “get” the basic concept of layering through the OSI model, and others will not.
Is the OSI model a strong, foundational model for understanding the way a network works, though? Not really.
Of course, if I don’t like the OSI model, I must like something, right? Stay tuned, because that is what is next in this little series.