In an earlier text, he said it's as if college taught you what the parts of a horse-drawn carriage are and what part of a modern car you need to point at when the instructor asks you where the loin straps are.
It's not about people who already deal with this, like Nanog or systems programmers. Whatever model they've started with, they've developed a better one in their heads based upon their own expertise and experience.
It's about educators who continue to teach out-dated concepts.
Take Presentation Layer #6 as an example. It was created because in the 1970s, every computer model had a different character-set, and every terminal model different command-codes. It was therefore assumed that translating among these different formats would be a property of the network, that a fundamental step would be negotiating some common representation, like it is with FTP and Telnet.
This is no longer true today. Everything's Unicode. A PDF file on an EBDIC IBM mainframe is still encoded as UTF-8. Data representation is a property of the DATA not a property of the NETWORK. But people are slow to adapting to this paradigm shift.
As for "layering violations", I propose an alternative model where there are no layering violations. If real world conflicts with your model, the model needs updating.
I'm surprised you did not mention his work. Defining and critiquing the reference models in the case of the ARPAnet and OSI was his thing. Much of it was published in a (quite funny) book The Elements of Networking Style[2], partially taken from some of his RFCs.
I've spent 40 years professionally applying OSI to systems architecture, design and application, across a very broad sphere of different use cases and subjects, from networking to digital musical-instrument making, embedded systems for heavy industry, and so on. I have shipped multiple forms of computing systems to tens of millions of users over decades, and OSI has been a proven, extremely powerful tool in the toolbox under those circumstances.
I respect your opinion as a network wonk, but I can't help but feel you are doing a huge disservice to generations of students who will take your authority to mean something, and end up ignoring what is, admittedly, one of the greatest tools for systems architects to use in sorting out the mess - based on your mis-application of it as a tool in your limited realm as a network engineer.
People are seduced by their own ignorance.
For example - Just No: session is not just a mainframe term. It means: "a semi-permanent interactive information exchange between communicating devices", and it always has. You've colloquialized it to your own local context for the sake of your argument, and I feel your framing of this phrase as an "ancient term related to archaic mainframe technology" is a disservice to those who attempt to apply your deconstructivist doctrine. (Also, there is no such thing as old technology - only old users.)
By way of example: MIDI instruments have sessions. (MIDI, which is incidentally not TCP/IP, can also be grasped through the OSI model, because the OSI model is an expression of an observation of natural laws about how interchanging systems operate.)
I was taught, and have always seen OSI as a systems-interchange abstraction, not just for networking but for all computing systems, which can be defined as being composed of a network of interdependent components exchanging units of information.
The realization that the network is the computer elevated OSI out of the realms of networking and into a more broadly applicable context: all computing systems are a network of nodes interchanging information and in that sense OSI becomes far, far more valuable. TCP/IP is just one of the realms these natural laws were observed and codified, but this is just the tip of the ice berg for computing systems architecture.
Network wonks might not like to admit it necessarily, but the network is a computer and any computing system is a network. (You're a wonk if you care more about the technology than the users, using it.)
>Data representation is a property of the DATA not a property of the NETWORK.
One cannot have a NETWORK without an agreed-upon representation of DATA which, at least two nodes, must agree on. Thus a NETWORK without a common DATA representation isn't a functioning network. NETWORK encompasses DATA. You simply cannot have a NETWORK without standardized DATA: that is what a student of the Open Systems Interchange theory learns when they apply it.
>If real world conflicts with your model, the model needs updating.
Or, one of two other states exist: a) you don't have enough experience with the real world, or b) your understanding of the model isn't sufficient to solve the problem of a).
To look at OSI as simply a networking abstraction is to completely invalidate its utility as a means of organizing layers in the construction of a functional ontology. This kills the programmer.
People are seduced by their own ignorance.
You state:
The OSI Model pretends its theory because it’s the standard.
The OSI Model is an observation of natural laws in the ways that open systems interchange units of information according to human intuition about organization. I think you come very close to realizing this in your treatise, but you avoid this conclusion because, I suppose, its unsuited for your argument that OSI is broken. I think your understanding of its broad applicability across a much, much wider array of systems interchanges is what is faulty, here.
It's about educators who continue to teach out-dated concepts.
Educators should understand the concepts they are attempting to teach and should not be ignorant of the realms in which those concepts can be applied. Educators are clearly teaching it wrong, if students come away thinking that OSI is only relevant to building networking architecture. They miss the point entirely if they don't realize that OSI is applicable to any form of networked interchange of units of data - whether its on-die or across state lines. Whether its the CPU in the satellite or the network those satellites support: OSI scales to all systems of open interchange, big or small.
Therefore: I don't think OSI is broken at all. It think its application needs to escape the limited mindset of network wonks, though, and clearly it needs to be wrestled out of the hands of the academic gentry who don't get out much and therefore don't know how to apply it equitably.
OSI is an observation of the layering of the ontologies that are required in order to make a modern computing system have value to its human operators - and its use by systems architects in that context is highly, highly productive.
I've seen it time and again: a grey beard comes in and cleans up the mess by getting things sorted into the proper layers. Greenbeards, got into the mess by ignoring OSI in the first place.
As all computing systems are networks, OSI has a valuable scope way beyond the limited realm of netops. I look forward to your reasoned consideration of this challenge to your authority on the matter.
The writers the OSI Model wrote a specific blueprint, not an "observation of natural laws". When they said "session", they didn't mean the same things you conceive of. Instead, they meant a very specific problem of connecting dumb terminals to simplex links.
What you now call "sessions" is what OSI called "associations", and OSI defined them to be part of the "Application Layer".
I'm not sure you've even read the OSI Model. For example, the "Presentation Layer" is not defined to do the data format translation, but only to NEGOTIATE a common represenation. The actual data translation is still done in the Application.
This is the problem. People have not read and understood the entire model. They've not heard of "associations" and believe the OSI's use of "sessions" means anything they might call "session". They believe OSI was written as theory when it was not. They believe anything OSI terms they don't understand mean something else, mean some sort of timeless theory.
They are seduced by their own ignorance of the model.
The problem of having an abstract representation of 'something' that must exist before any further negotiation can occur, on a one-on-one peer basis, still exists.
We still have sessions. The technology may have been a soggy noodle when the OSI authors started their journey, but its still just a damp string now.
>I'm not sure you've even read the OSI Model.
That is your prerogative, but I could as well claim that, neither have you - or if you have, you clearly have not understood it well, also. Such statements are of little use in a discussion of the OSI model, other than to serve as a barrier to entry.
>Seduced
OSI was written to observe a specific instance of the necessity to formulate distinct abstractions between disparate components in a multi-variate system, successfully processing information. (The Open Systems Interchange, or indeed .. didn't OSI itself evolve as an acronym, hmm..)
Like many good observations of natural law, it evolved over time as humans came to understand it, adopt it, and apply it to their situation.
Your claims of the intents and purposes of the original authors, per your perspective of the model, are frankly not convincing in the slightest.
Technology evolves from natural laws. It is based on observation, analysis, understanding, and application. This is true of all technologies - they're entirely dependent on the skill of the user.
Perhaps you have not searched far enough to find positive examples of OSI model mapping in an analysis which produced high-yield, industrial-strength, compelling results.
I would say you haven't looked far enough - because you seem intent on only applying it to your limited scopes: a) networking/TCP-IP, and b) your analysis of stupid people and their ignorance of history because it is sexy.
Do OSI on a system for musicians to create sound together on stage, and fail at it at least 3 times, and then we can discuss seduction.
In fact, it was this model that enabled the development and rapid adoption of the internet. People knew and understood, from day one, which OSI layer abstractions were collapsed into and managed by which parts of the TCP/IP protocol. People knew and understood, again from day one, where protocols such FTP, HTTP, and SMTP stood in the model. People understood where physical things like routers, bridges and gateways fit in the model and what functions were being served. The OSI model facilitated the explosion in networking that took place in the 80's and 90's - I know because I was there and watched it happen and was utilizing the model in creating solutions at the time!
This author is attacking a Straw Man.
1: It was an off semester and it wasn't taught by Doug Comer, but we did use his book.
Layering is very much alive, but I tend to agree that we need a richer and better suited layering model.
Moreover, I have not heard anyone but myself utter the word "OSI" out loud in 8 or 10 years. Maybe it's still a thing in academia, but it's not in corporate or open source worlds. I don't know if I've met more than 2 people in 5 years that know how TCP works. It's just a magic tunnel that HTTP somehow uses under the covers. So I really don't get the need or purpose for this document. It's like describing in excruciating detail that what you know about the ancient Egyptians is a lie, because that's somehow going to be necessary for somebody?
Except in the case of OSI, it's not a reputable analytical tool from the perspective of actual academics; it's rather a discredited one. Instead, it's only lay-people with an outdated view of the state-of-scientific-practice who attempt to apply the discredited tool. And this article is an attempt to get those lay-people to stop doing that.
Compare/contrast how the layman may often think that Freudian psychoanalysis is still in use in psychiatry — and may even try to apply it themselves to understand someone's motivations. Much to the chagrin of psychiatrists.
The issue is about education. People teach the model, or some variation of it. It teaches misconceptsion, such as how Ethernet and the Internet are integrated in a single network stack rather than being independent networks. It leads to professionals in IT and cybersecurity who continue to hold this misconception.
It really opened up a whole world of understanding for me when I decided to go look up "RFC 1" to see what it was about.
Reading that — and the few low-numbered RFCs after it — made me realize that "the birth of the Internet" as we know it, was essentially the moment of the deployment of the first network switch (the BB&N IMP), isolating physical networks' electrical properties and collision domains from one-another and using DSPs to arbitrarily re-write packets between different signalling standards — thus rendering uniformity of physical/electrical media and LAN signalling standards, completely irrelevant.
Until that moment, I had always thought of "the Internet" as a standard for LAN networking that grew like a social network until it overtook the world — where things like "Ethernet" and "TCP/IP" were the "Internet flavor" (DARPA flavor?) of those LAN-networking technologies; where "the Internet" was competing with other LAN technology suites, the likes of ChaosNet or AppleTalk or NetBEUI; where people gradually "switched over" from using whatever networking equipment and signalling protocols they had been using, to using Internet networking equipment and standards; and where the fact that people were finally settling on the same networking protocols across multiple Autonomous Systems, allowed them to finally yolk those systems together into inter-networks, with more and more of that happening until we had one big hierarchical LAN called The Internet.
But no! The whole clever thing about "The Internet" is that it didn't do that! It just took all the random proprietary networks that people had built, and connected them together as black boxes, by coming up with a set of standards for how the networks would speak to one-another at their border gateways, and leaving everything else up to implementation, with the assumption of border-gateway routers being implemented by each LAN-technology-vendor to translate between "Internet" signalling and whatever that LAN was doing!
And, in that view, the whole "layer separation" concept — of there being such a thing as an "IP packet" that bubbles up to userland separately from any delivery enveloping — wasn't fundamental to The Internet; in fact, existing protocols that were vertically integrated continued to work, being rewritten into something else when they reached the AS border gateway. The "layer separation" was an optimization to allow new "post-Internet" protocols to be passed "transparently" across AS border gateways without those gateways needing to know about them to rewrite them.
Rather, these "post-Internet" protocols, consisting of separate "LAN envelope" and "Internet payload" parts — and designed with trancieving logic on the endpoints such that the "Internet payload" could traverse the [lossy, laggy] Internet intact — could simply be re-enveloped from "LAN packets" into "Internet packets." And the responsibility for constructing/parsing the "LAN envelope" part would be taken away from userland, made the responsibility of the OS, so that "post-Internet" applications could be portable between computers that used different LAN technologies but wanted to speak the same Internet protocols.
But, of course, network stacks continued to support non-layer-separated communication for decades afterward the advent of The Internet; and AS border gateways continued to support rewriting these protocols "at the edge" for just as long.
It wasn't until much later that LAN networking equipment truly became commoditized. (I have a Windows 2000 manual that describes its support for token-ring networking. Windows 2000!) In a fully post-Internet era, when everyone is using Internet protocols, a "network" could no longer offer much to differentiate itself. So we started to see shifts to actually standardize on LAN technologies, with vendors all moving toward making the same stuff. At that point, border gateways began getting simpler, and companies like Cisco that had made their fortune in the AS-border-gateway space stopped being household names, instead being relegated to the NOC (as they had successfully pivoted into dumb-but-high-throughput enterprise LAN switching, and even-dumber-but-even-higher-throughput Internet backbone switching.)
Counterpoint: DDoS attacks are routinely described as "layer 3" or "layer 7" attacks.
And if you're in the kind of industry that goes in for certifications, the OSI model comes up pretty frequently in networking exams, especially at the entry level.
It's really unfortunate that folks have stopped learning about it. It makes troubleshooting connectivity issues so much easier and collective knowledge of OSI helps immensely with triage and communication.
I have no idea why we continue to use thes numbers instead of saying the protocols or a more descriptive name, like transpory layer or application layer.