This is hilarious. I happen to be preparing for a test centered around the OSI model and I don’t get why it’s set this way. Every few paragraphs the text says something like “remember that nowadays things a bit fuzzier and don’t fit within one layer” well then why are we even using this model?
As models go it’s pretty good, and no one has made a better one. Seriously. The layers are all useful concepts to know about and discuss, even if in some cases it is most practical to blur the lines or outright combine two of them into one protocol. You will at least know that you are doing so, and you will know to point out _why_ you are. But nobody has ever determined that it is _always_ best to combine two of the layers (which would really amount to proving that the two are in fact the same thing). But since nobody can prove that it is _never_ a good idea either, it remains a model and not a theorem with a proof.
Edit: but I will also say that any test or certification which focuses too much on the OSI model is also suspect. I don’t know what test you’re about to take, but plenty of people will sell you certifications that in the end are meaningless.
If one is going to argue for a layers based model the OSI model is still a particularly poor choice vs something with at least relevant layers such as the 4 layer model commonly referred from TCP/IP. It's been the superior model to reference for decades.
Because all models are wrong, but some models are useful.
OSI is a useful model, especially at lower layers, because it covers the abstractions from physical to network to internet to protocols, and that is a useful way to think about things.
I discuss this point several times. I claim the model is not useful, specifically because the layering abstraction for hte lower layers is a misconception rather than the truth.
For example, I describe how the OSI Model claims that layer #2 and #3 describe different functionality in the same network stack. I claim the opposite, how they describe roughly the same functionality in differnet networks.
Namely, both Ethernet and the Internet forward packets based upon addresses. The difference is that Ethernet does this locally while the Internet does this locally. Otherwise, the theoretical concept of packets, forwarding, and addresses are the same.
The key concept in routing is hierarchy, which Ethernet does not have. It’s an extra dimension that changes the way the protocol and applications work at that layer.
You can say a cube and a square are the same thing, but I don’t think that’s particularly useful pragmatically. Ditto for L2 and L3; if you abstract out the difference, they are indeed the same. But that’s not useful.
Now, you could say that time has brought evolutions / optimizations that blur layer boundaries, like VLANs at layer 2. But that doesn’t make the model less useful.
In my experience working alongside network engineers, they use “layer 2” as a synonym for Ethernet, “layer 3” as a synonym for IP (v4 and v6), “layer 4” as a synonym for TCP and UDP, and “layer 7” as a synonym for application protocols. They don’t talk about the other layers. It’s just jargon, without any deeper meaning.
> The point of all this is that ethernet and IP were getting further and further intertwined. They're nowadays almost inseparable. It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address, and it's hard to imagine that network interface working without an IP address. You write your IP routing table using IP addresses, but of course you know you're lying when you name the router by IP address; you're just indirectly saying that you want to route via a MAC address. And you have ARP, which gets bridged but not really, and DHCP, which is an IP packet but is really an ethernet protocol, and so on.
Yep, for every person who says they haven't touched osi in a decade, there's someone studying the topic either at a school or for a vendor certification.
And for every "the bottom layers are worthwhile", there's a network engineer applying for a job with some leetcode like tool asking them about layer 5.
This is wonderful material. But admittedly, I am a bit lazy on reading to the part I want: what is a good model, or set of models, I should re-educate myself with to correct what I was taught?
Ethernet, IPv4, TCP, and HTTP; what functions do each provide, how is each coupled to its neighbor, and what are the viable alternatives in the design spaces of each?
Part of the OSI layering model was I think meant to get people's brains wrapped around the dynamics of packet switching networks, which were once a novelty and are now just part of the air we breathe.
I would probably add TLS in thereas an optional layer between TCP and HTTP. But http/3 and quic complicates things because it kind of blends the tcp, tls, and http layers together.
It's wrong to think of them as different functions of the same network. Instead, they are differnet networks.
Ethernet and the Internet both provide the function of forwarding packets through a network to the target destination address. The MAC protocol and IP protocol provide the same theoretical function.
Where they differ is that Ethernet was designed to a be a local network, whereas the Internet is designed to be an internetwork. All it demand from local networks is that they get packets from one hop to the other. Ethernet does this for the Internet, but so do carrier pigeons.
The same is true for HTTP. Instead of thinking of it as a component of the network, think of it as something that rides independently on top of the network. In a hypothetical future whe we've replaced the Internet with some other technology, the web would still function.
I mean, this isn't bad or anything, and if Rob Graham is going to write about anything with authority, this is certainly it, but it's kind of beating up a straw man, isn't it? I feel like "layering violations" went out the window with HTTP, and certainly by the time we got WebSockets.
It's not great. It reads like some angsty nerd who really doesn't like the idea of something and has spent an inordinate amount of time trying to explain why it's wrong and why his solution is better. Sometimes that works, if your name is Locke or Marx or something, but this writing really doesn't say "genius" to me.
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?
I sort of agree that "OSI" is really weakening his argument, and that he could take clearer aim at the classical Internet layering model (network, transport, application) --- even that simple layering is obsolete now. But it'd still be a straw man! We even run DNS over HTTP at this point.
I think that the "OSI" he's speaking about isn't an engineering tool, a thing people would use to construct systems; rather, this "OSI" is a way of modelling systems that exist — systems that, of course, were not implemented by people thinking about OSI. It's an analytical modelling tool, a thing applied to a system retrospectively in an attempt to understand it, break it down along abstract rather than concrete lines. Like the various flavors of literary criticism.
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.
Yea, it's not about engineers constructing systems. I mean, engineers do frequently pretend their creations fit the OSI model, but they work backwards to make it appear to conform to orthodoxy.
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 teaches misconceptsion, such as how Ethernet and the Internet are integrated in a single network stack rather than being independent networks.
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 Wind...
> Maybe it's still a thing in academia, but it's not in corporate or open source worlds.
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.
Enterprise networking still exists, and most things still fit in the OSI model for the most part (MPLS/"layer 2.5" had already broke the model kinda, exceptions can be made).
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.
Terminology like "layer 4", "layer 7" and sometimes "layer 3" is often used in documentation for things like load balancers, vpns or other tunnels, etc. As a specific example the documentation is for layers is split into layers 4-7 that roughly sort of match the OSI model. Except not really, because the OSI model doesn't really math tcp/ip. And the first feature listed on the overview page for an AWS ALB is that it does "Layer-7 Load Balancing".
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.
I try and use "application layer" and "transport layer" myself but find that people don't really understand what I mean but for some reason understand "layer 4" and "layer 7" (and sadly yeah, occasionally "layer 3".) I still insist in documents in using descriptive layer names but usually in conversation just refer to load balancers or proxies.
It is worse with drive arrays. The original UC Berkeley RAID project enumerated several possible configurations of drives. Unfortunately the numbers they used to represent their configurations entered the vernacular when we probably should have been using the names. Now it is a complete mess.
The rant is not about layering being wrong, but rather that OSI is unsuitable to describe the layering of modern computer networks.
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.
This isn't a straw-man (or at least wasn't when I took an undergraduate networking class in 2003 at Purdue[1]). We were taught the mappings from the OSI model to Ethernet/IP pretty much like TFA says, along with some hand-waving for the top 3 models with too many holes for the professor to address whenever anyone raised questions about it.
1: It was an off semester and it wasn't taught by Doug Comer, but we did use his book.
Well, as my footnote in the abstract says, it's swatting a fly with an anvil.
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 under...
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.
I am curious how the OSI model would guide a reader on which layer should be responsible for encryption and authentication. Especially how it relates to existing protocols such as IPSEC, TLS, Kerberized Telnet, QUIC, etc.
My experience has been similar to yours and from day one way back in the early 80's I was taught that OSI is a model and that no real-world networking protocol adhered to it. Period end. Forty years ago OSI wasn't taught as a framework or a standard - and this was within 5 years of it being developed! It was always taught as a model to understand the different aspects and functions of machine to machine communications. That's it and that's all!
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!
I don't think that Bob's essay goes against layering per-se. It's about the OSI layering specifcially not being suited to describe the current Internet anymore.
Layering is very much alive, but I tend to agree that we need a richer and better suited layering model.
Under: 7.1.2. Poorly understood terminology
>This is what happened with “session”. When OSI named this layer, it had nothing to do with sessions in general, but with very specific issues connecting a terminal to a mainframe.
[...]
What we think of as sessions (as in HTTP) are actually called associations in OSI, and is assigned to the Application Layer #7.
Elsewhere in the text I describe how OSI chose a word at random, that they never meant by it what we now call "sessions". It could've been 'dialog layer' or 'interaction layer". I recommend they should've chosen "Intercourse Layer".
Overall this is helpful, but it seems a bit ranty, and doesn't do as much as (for example) John Day's Patterns in Network Architecture to provide a positive alternative model.
I always thought this model was pretty worthless. I remember when they tried to apply it to the internet. It didn't quite fit, but they needed a model because intellectuals.
It depends on when it was. Back in 1999 it fit pretty well. Even if not perfect it still was a good teaching tool to explain "how it all works" on some level. Then you got to know the hairy details.
Nowadays "Internet" is mostly HTTP 2 for most people and then this model doesn't even remotely explain the structure of it.
I claim that by 1981, the OSI Model was already obsolete and that it didn't fit well, that was not a good teaching tool, that it has done more to beffudle than enlighten students. The problem being is that if you learned according to the modle, you are not aware of what you misundertood.
It didn't fit any better in 1999 than it does now and it wasn't a good teaching tool because it didn't match reality at all but was presented as if it did. Definitely caused more confusion than learning.
A very fun read, especially if (like me) you realized a year ago you had basically no idea how networking actually worked, because your whole mental model was based off of the Wikipedia article on the OSI model, and decided to cram all 180 pages of Michael W. Lucas's Networking for System Administrators into your head with Anki cards to finally make the "real" stuff stick. (Terrific book, terrific writer, I will never get tired of recommending this one in particular.)
Oh my God I read this ages ago and completely forgot which blog it was on. Thank you for bringing this back to my attention! This is up there with Hotel Concierge on Tumblr for "favorite giant sprawling essays on the Internet" for me.
I'm really enjoying reading this. I understand why it needs to be so long, but I think it could have more reach if there were also a short primer that succinctly explains why OSI is wrong, and proposes a single alternative model.
> People today can’t comprehend the original model because they have no experience with terminals and mainframes. This makes them treat OSI as a deep mystery.
In fairness, I have come to think that we should teach computer science by plopping students in front of a PDP-11 and teletype (probably actually a PiDP-11 under the hood, but the students don't need to know how we realized the machine), running v6 unix, take them through the Lions book[0], then take them through... probably early BSD? on similarly period-appropriate hardware (again, implemented however needed) to learn networking, and then catch them up on the following few decades, because it turns out a lot of modern concepts make more sense when you see them in the original context[1]. A person could also argue that we should get over the past and build systems that learn from past ideas and mistakes without having to actually include the entire history, but I've come to view this as impossible to actually implement so we might as well embrace the tree rings that are our computers.
Computer science is about computers just as much as physics is about telescopes.
Computer scientists should think of computers in terms of logic, computability and complexity theory. We don’t expect physicists to learn how the first telescopes worked in detail because it’s useless. A physicist should learn optics and then understand why telescopes were build that way.
The history of something can help put it in context and make taking the pill less bitter, but the fact remains that the majority of computer engineering is a bunch of incoherent mess that stems from decades of desperate backwards compatibility and baby duck syndrome. If you taught CS students stuff from the PDP era you would simply give them a limited view of what computers can be.
> Computer science is about computers just as much as physics is about telescopes.
Assume I actually mean computer engineering or so, but it's still taught in a section of school called the computer science department and the diplomas still say computer science so I'm going to call it that.
> but the fact remains that the majority of computer engineering is a bunch of incoherent mess that stems from decades of desperate backwards compatibility and baby duck syndrome.
Yeah, that's my point; in reality our computers are layers upon layers of old stuff patched over with newer stuff for decades, so we might as well teach it that way. And obviously we should teach all the way to present; I'm not intending to suggest that we stop in the 80s.
You mean astronomy, not physics. Physics is about telescopes (and other physical objects), and learning about basic telescopes, and how to improve them is part of optics courses. Astronomy on the other hand doesn't actually care how telescopes are built (other than the data acquired by them meets the needs of the science).
Most curriculums suffer from teaching outdated concepts in CS, how would this help? Universities' purpose is not to satisfy someones retrocomputing history interest, but to supply state of the art understanding of a group of subjects.
The current state of art is built on relatively minor additions to the ancient stuff. I think it's easier to start with the old stuff and then teach up to the current day rather than trying to ignore the old stuff and just teach the modern parts.
> [OSI's] negatives far outweigh its positives. OSI is not theory, it’s not a framework, it’s not helpful, it’s not a standard, it’s not anything those who use it claim it to be. Anything you teach with the OSI Model can better be taught without it.
This is a naive understanding of the OSI model, whose primary virtue is not any specific detail it expresses, but instead its ubiquity.
The only way to successfully replace a (clearly entrenched) status quo is to make the positive case for the new thing, which has to be just obviously and significantly better. Pointing out the flaws in the current thing is never convincing, and never a winning strategy.
It's far from ubiquitous though. It breaks down as soon as you enter the real world. It's simultaneously too vague to be useful for talking about specifics and too inaccurate to be useful for talking about generalities.
It's absolutely ubiquitous as a model. It's taught in every CS curriculum in every university in the world.
It also doesn't break down in the real world, unless you're being extremely pedantic. Many bits of software don't map cleanly to the defined layers, but we can still talk about the distinction between the network layer vs. the session layer, for example, and get value out of that discussion.
> It also doesn't break down in the real world, unless you're being extremely pedantic.
It breaks down if you're trying to do anything at all with it. There are basically two layer boundaries that are useful to talk about in the real world - between Ethernet and TCP/IP, and between TCP/IP and application protocols. The OSI model has 6 layer boundaries but a) neither of them maps cleanly to either of those two real-world buondaries b) no-one knows what the other 4 are (you can kinda-sorta say that the boundary between TCP and IP is one of them, but that isn't the distinction that the OSI says it is either). Depending who you ask you can sort of retrofit it and say that the boundary between Ethernet and TCP/IP is between OSI layer 2 and 3 or 3 and 4, and the boundary between TCP/IP and application protocols is somewhere between layers 4 and 7, which is sort of ok because no-one knows WTF layers 5 and 6 are meant to be. But you're really not getting any value from using the OSI model at that point; it's not telling you anything useful and it's actively getting in the way of understanding what's going on.
> we can still talk about the distinction between the network layer vs. the session layer, for example, and get value out of that discussion.
OSI is just a model. Like all models, it's wrong. But its ubiquity, and the fact that it's survived the test of time, clearly signal that it is a useful model. And that's as good as models get.
Not all models are truly wrong. But I get your point. I think though the author isn't just arguing that the OSI is like your typical "wrong" model. I think he's saying it's a shitty model. It's crap. It's like using Hippocrates four humors to model human health.
Yeah that model is wrong just like every model. But unlike every model it's a garbage model.
Religion has ALSO survived the test of time, but Jesus Christ coming back from the dead and walking on water is still utter bullshit. Not to get into a religious argument here, but if you're Christian let me know and I'll have to look harder for another analogy.
Anyway my point is: Surviving the test of time, Does not mean shit.
Look, just tautologically, if it was so shitty, we wouldn't be talking about it, because nobody would be using it.
You're free to use a definition of "shitty" that doesn't take into account usage or longevity, but that definition is not really relevant except at the theory level.
So why are we talking about moses putting 2 of every animal on the face of the earth on an ark? Why is it being taught to tons of good Christians all over the world?
Let's face it. The story of moses, in terms of the actuality of what happened? Utter bullshit. Just because everyone teaches it and talks about it, doesn't make it not bullshit.
You know what I mean by shitty or bullshit. You just disagree. You're just saying, in your opinion, it's not bullshit, but you absolutely know what I mean here.
Your opinion is valid.
I'm just saying that ubiquity does not prevent something from being bullshit.
Something that is being talked about everywhere and all the time does not prevent that something from being bullshit.
So you may believe that OSI is NOT bullshit. But your reasoning would be invalid if the two above points are the starting axioms of your logic.
And this specific model is very wrong. It is not useful; it survived mostly because it's useless: slapping an "OSI level X" label on something affects pretty much nothing so sure, you can keep doing that and keep teaching it to people.
Tons of concepts that masquerade as "theory." Big words and "epiphanies" that make programmers loyal to the concept in the same way people are loyal to OSI.
Design patterns,
SOLID,
etc.
All bullshit akin to color theory and OSI. Big words and bullshit. At best you can use these things as rules of thumb. They work somewhat. But overall they don't.
"The goal of these Wikipedia-style ontological frameworks is to describe theory, like science. But for the most part, networking is practice. It reflects engineering choices rather than scientific principles. It’s less like a biological taxonomy and more like a military hierarchy: we humans chose to put things there.
It’s a struggle choosing pure theory vs. practice. Are we describing the TCP/IP Internet that we are all using today? Or are we trying to describe theory, how networks have existed in the past and how they might exist in the future?
The OSI Model pretends its theory because it’s the standard. The idea is that there would be 7 fixed layers and that over time, new standards would be invented that would upgrade a layer. All networks of the future would follow this blueprint, so it described all future networks.
"
I'm really surprised that RFC-1122 isn't mentioned in the entire article; The IETF defines 3 layers for a TCP/IP network (link, IP, and Transport) and those layers are (IMO) much more useful for understanding the internet than the OSI model. In addition they don't pretend to be describing a platonic ideal of a network, but rather just specific parts of the network we are using today.
Yeah; as somebody who was taught the OSI model at university, they basically straight up told us to ignore the OSI model above layer 4, and to treat the remaining stuff as a starting point rather than the whole story.
So criticizing layers 5/6/7 is not really helpful. Those are not actually taught anymore.
People refer to the OSI model because it's useful, and can be explained in about 1/30th of the text needed to produce this rant. Why not propose an equally-concise yet more useful model instead?
It is good to remind yourself once in a while that “networks” don't exist, they are an illusion based on processing of independent packets based on magical numbers in them. In theory, there is nothing strange in a system that decides to hold all IP addresses higher than a certain number, or offer some service on all even ports at once. It only needs a different mathematical operation on those numbers to be performed.
Also, in theory, we can have internet-wide broadcasts (in a multicast-like or some other graph traversal manner). Then, say, ALL p2p file sharing can be reduced to a single standard request "WHO-HAS The.Matrix.DivX.l33tR1pZ.avi". Then one starts to think why it is not possible in practice.
This document is great but could use some tough-love editing. The author drives home the same points repeatedly, and in many cases redundantly, in a way that does no favors to the substantive content of the argument. Sometimes less ranting makes for a more devastating critique.
I think this might be the favourite thing I read on hacker news. Thank you so much Robert Graham for writing this, I always considered the OSI model fishy, and although I mostly worked with stuff like CAN (that was also mentioned) I was irked when people tried to shoehorn OSI model _even there_ !
If I ever meet you, robertgraham, I am definitely going to try buying you a beer.
One thing I am a bit confused though is that the Ethernet uses TCP/IP but you keep trying to hammer the point that is a internet thing. So... I'm a bit confused about this. Are the packages used by the router to talk with a local network device different than the packages used by the router to talk with a device on the internet? And is the format of these packages the same and just fwded if they address a local device but unpacked and re-packed with the proper header if they address a internet device?
Ethernet doesn't use TCP/IP. Ethernet is it's own network. It has nothing to do with TCP/IP.
Other things use Ethernet. Routers, when connected to each other, often use a local Ethernet network to communicate.
Think of the TCP/IP Internet as it's own network, ignoring how routers physically talk to each other. Sometimes it's a directly link, a wire. Sometimes it's carrier pigeons. Sometimes it's WiFi. Sometimes it's Ethernet. Whatever it is, it's local to between the routers and does not extend outside that.
I think my confusion arises that, when I access some other PC on the local network, I connect to an IP and port. That's not on the wide internet, but it uses IP to communicate. Therefore... where's the ethernet's role in that?
94 comments
[ 2.3 ms ] story [ 166 ms ] threadEdit: but I will also say that any test or certification which focuses too much on the OSI model is also suspect. I don’t know what test you’re about to take, but plenty of people will sell you certifications that in the end are meaningless.
OSI is a useful model, especially at lower layers, because it covers the abstractions from physical to network to internet to protocols, and that is a useful way to think about things.
For example, I describe how the OSI Model claims that layer #2 and #3 describe different functionality in the same network stack. I claim the opposite, how they describe roughly the same functionality in differnet networks.
Namely, both Ethernet and the Internet forward packets based upon addresses. The difference is that Ethernet does this locally while the Internet does this locally. Otherwise, the theoretical concept of packets, forwarding, and addresses are the same.
You can say a cube and a square are the same thing, but I don’t think that’s particularly useful pragmatically. Ditto for L2 and L3; if you abstract out the difference, they are indeed the same. But that’s not useful.
Now, you could say that time has brought evolutions / optimizations that blur layer boundaries, like VLANs at layer 2. But that doesn’t make the model less useful.
Admittedly layers 5 and 6 are kind of blurry, but so what? Doesn’t mean the model isn’t useful, just that it isn’t a perfect map=territory.
https://apenwarr.ca/log/20170810
> The point of all this is that ethernet and IP were getting further and further intertwined. They're nowadays almost inseparable. It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address, and it's hard to imagine that network interface working without an IP address. You write your IP routing table using IP addresses, but of course you know you're lying when you name the router by IP address; you're just indirectly saying that you want to route via a MAC address. And you have ARP, which gets bridged but not really, and DHCP, which is an IP packet but is really an ethernet protocol, and so on.
And for every "the bottom layers are worthwhile", there's a network engineer applying for a job with some leetcode like tool asking them about layer 5.
Part of the OSI layering model was I think meant to get people's brains wrapped around the dynamics of packet switching networks, which were once a novelty and are now just part of the air we breathe.
Then, read:
https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...
IMHO that's the highest layer of the OSI model that is useful. After that it's various ways of tunnelling streams inside of streams.
Ethernet and the Internet both provide the function of forwarding packets through a network to the target destination address. The MAC protocol and IP protocol provide the same theoretical function.
Where they differ is that Ethernet was designed to a be a local network, whereas the Internet is designed to be an internetwork. All it demand from local networks is that they get packets from one hop to the other. Ethernet does this for the Internet, but so do carrier pigeons.
The same is true for HTTP. Instead of thinking of it as a component of the network, think of it as something that rides independently on top of the network. In a hypothetical future whe we've replaced the Internet with some other technology, the web would still function.
Then your criticism of the first three OSI layers is merely that they should be named "point-to-point", "local", and "inter".
I can agree with that criticism. But I can't agree with needing 239 pages to convey it.
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 Wind...
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.
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.
1: It was an off semester and it wasn't taught by Doug Comer, but we did use his book.
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.
[1] https://en.wikipedia.org/wiki/Michael_A._Padlipsky
[2] https://archive.org/details/elementsofnetwor00padl
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 under...
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.
Layering is very much alive, but I tend to agree that we need a richer and better suited layering model.
Under: 7.1.2. Poorly understood terminology >This is what happened with “session”. When OSI named this layer, it had nothing to do with sessions in general, but with very specific issues connecting a terminal to a mainframe. [...] What we think of as sessions (as in HTTP) are actually called associations in OSI, and is assigned to the Application Layer #7.
Nowadays "Internet" is mostly HTTP 2 for most people and then this model doesn't even remotely explain the structure of it.
I claim that by 1981, the OSI Model was already obsolete and that it didn't fit well, that was not a good teaching tool, that it has done more to beffudle than enlighten students. The problem being is that if you learned according to the modle, you are not aware of what you misundertood.
https://apenwarr.ca/log/20170810
In fairness, I have come to think that we should teach computer science by plopping students in front of a PDP-11 and teletype (probably actually a PiDP-11 under the hood, but the students don't need to know how we realized the machine), running v6 unix, take them through the Lions book[0], then take them through... probably early BSD? on similarly period-appropriate hardware (again, implemented however needed) to learn networking, and then catch them up on the following few decades, because it turns out a lot of modern concepts make more sense when you see them in the original context[1]. A person could also argue that we should get over the past and build systems that learn from past ideas and mistakes without having to actually include the entire history, but I've come to view this as impossible to actually implement so we might as well embrace the tree rings that are our computers.
[0] https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Opera...
[1] For instance, vi's key choices make perfect sense when you see the keyboard it was born on - https://en.wikipedia.org/wiki/Vi#Creation
Computer scientists should think of computers in terms of logic, computability and complexity theory. We don’t expect physicists to learn how the first telescopes worked in detail because it’s useless. A physicist should learn optics and then understand why telescopes were build that way.
The history of something can help put it in context and make taking the pill less bitter, but the fact remains that the majority of computer engineering is a bunch of incoherent mess that stems from decades of desperate backwards compatibility and baby duck syndrome. If you taught CS students stuff from the PDP era you would simply give them a limited view of what computers can be.
Assume I actually mean computer engineering or so, but it's still taught in a section of school called the computer science department and the diplomas still say computer science so I'm going to call it that.
> but the fact remains that the majority of computer engineering is a bunch of incoherent mess that stems from decades of desperate backwards compatibility and baby duck syndrome.
Yeah, that's my point; in reality our computers are layers upon layers of old stuff patched over with newer stuff for decades, so we might as well teach it that way. And obviously we should teach all the way to present; I'm not intending to suggest that we stop in the 80s.
I too am a sucker for a pithy quote.
Alas it couldn’t be more wrong.
Computer science is about computers and how to program them. It is an engineering discipline, not a science.
That’s computer engineering, not computer science
This is a naive understanding of the OSI model, whose primary virtue is not any specific detail it expresses, but instead its ubiquity.
The only way to successfully replace a (clearly entrenched) status quo is to make the positive case for the new thing, which has to be just obviously and significantly better. Pointing out the flaws in the current thing is never convincing, and never a winning strategy.
It also doesn't break down in the real world, unless you're being extremely pedantic. Many bits of software don't map cleanly to the defined layers, but we can still talk about the distinction between the network layer vs. the session layer, for example, and get value out of that discussion.
It breaks down if you're trying to do anything at all with it. There are basically two layer boundaries that are useful to talk about in the real world - between Ethernet and TCP/IP, and between TCP/IP and application protocols. The OSI model has 6 layer boundaries but a) neither of them maps cleanly to either of those two real-world buondaries b) no-one knows what the other 4 are (you can kinda-sorta say that the boundary between TCP and IP is one of them, but that isn't the distinction that the OSI says it is either). Depending who you ask you can sort of retrofit it and say that the boundary between Ethernet and TCP/IP is between OSI layer 2 and 3 or 3 and 4, and the boundary between TCP/IP and application protocols is somewhere between layers 4 and 7, which is sort of ok because no-one knows WTF layers 5 and 6 are meant to be. But you're really not getting any value from using the OSI model at that point; it's not telling you anything useful and it's actively getting in the way of understanding what's going on.
> we can still talk about the distinction between the network layer vs. the session layer, for example, and get value out of that discussion.
Like what?
It depends on the type of person you are for this analogy to work but...
Religion is ubiquitous and it is largely just inaccurate made up fantasy stories posing as truth. It's generally not good from this perspective.
OSI is religion. And like religion, it is ubiquitous. Is that a good thing? I'm not sure.
Yeah that model is wrong just like every model. But unlike every model it's a garbage model.
Religion has ALSO survived the test of time, but Jesus Christ coming back from the dead and walking on water is still utter bullshit. Not to get into a religious argument here, but if you're Christian let me know and I'll have to look harder for another analogy.
Anyway my point is: Surviving the test of time, Does not mean shit.
You're free to use a definition of "shitty" that doesn't take into account usage or longevity, but that definition is not really relevant except at the theory level.
Let's face it. The story of moses, in terms of the actuality of what happened? Utter bullshit. Just because everyone teaches it and talks about it, doesn't make it not bullshit.
You know what I mean by shitty or bullshit. You just disagree. You're just saying, in your opinion, it's not bullshit, but you absolutely know what I mean here.
Your opinion is valid.
I'm just saying that ubiquity does not prevent something from being bullshit.
Something that is being talked about everywhere and all the time does not prevent that something from being bullshit.
So you may believe that OSI is NOT bullshit. But your reasoning would be invalid if the two above points are the starting axioms of your logic.
Tons of concepts that masquerade as "theory." Big words and "epiphanies" that make programmers loyal to the concept in the same way people are loyal to OSI.
Design patterns, SOLID, etc.
All bullshit akin to color theory and OSI. Big words and bullshit. At best you can use these things as rules of thumb. They work somewhat. But overall they don't.
"The goal of these Wikipedia-style ontological frameworks is to describe theory, like science. But for the most part, networking is practice. It reflects engineering choices rather than scientific principles. It’s less like a biological taxonomy and more like a military hierarchy: we humans chose to put things there.
It’s a struggle choosing pure theory vs. practice. Are we describing the TCP/IP Internet that we are all using today? Or are we trying to describe theory, how networks have existed in the past and how they might exist in the future? The OSI Model pretends its theory because it’s the standard. The idea is that there would be 7 fixed layers and that over time, new standards would be invented that would upgrade a layer. All networks of the future would follow this blueprint, so it described all future networks. "
RFC 1122 is a retconned version of the Internet model that tried to change terminology to fit OSI.
So criticizing layers 5/6/7 is not really helpful. Those are not actually taught anymore.
People refer to the OSI model because it's useful, and can be explained in about 1/30th of the text needed to produce this rant. Why not propose an equally-concise yet more useful model instead?
Also, in theory, we can have internet-wide broadcasts (in a multicast-like or some other graph traversal manner). Then, say, ALL p2p file sharing can be reduced to a single standard request "WHO-HAS The.Matrix.DivX.l33tR1pZ.avi". Then one starts to think why it is not possible in practice.
If I ever meet you, robertgraham, I am definitely going to try buying you a beer.
One thing I am a bit confused though is that the Ethernet uses TCP/IP but you keep trying to hammer the point that is a internet thing. So... I'm a bit confused about this. Are the packages used by the router to talk with a local network device different than the packages used by the router to talk with a device on the internet? And is the format of these packages the same and just fwded if they address a local device but unpacked and re-packed with the proper header if they address a internet device?
Other things use Ethernet. Routers, when connected to each other, often use a local Ethernet network to communicate.
Think of the TCP/IP Internet as it's own network, ignoring how routers physically talk to each other. Sometimes it's a directly link, a wire. Sometimes it's carrier pigeons. Sometimes it's WiFi. Sometimes it's Ethernet. Whatever it is, it's local to between the routers and does not extend outside that.