The Actual OSI Model
computer.rip
computer.rip
In migrating from the use of TCP/IP to the ISO protocols
My main takeway was: Thank god the internet won, OSI was some badly specified eldritch horror. RFC1006 was the only spec that seemed more or less readable by a human being.
Yours truly: Mr. Bombcar
The spec is wordy, but CLNS and TP4 differ little from IP and TCP, except for TP4 not having legacy of being a dumb emulated serial port, so it has message framing. Most of verbiage comes from the part that OSI took pains to handle a lot of problems upfront instead of saying "eh, it's temporary, let's go shopping", and writing standards with strict requirements tended to have certain verbiage allowing one to specify in minutiae what was missing from implementation, with no Postel around to promote lax handling.
N.B. a pretty serious (and implemented on Cisco and Sun) proposal to fix the already-known addressing problem of IPv4 was TUBA - which is essentially TCP running on top of CLNS.
Americans are very pragmatic: make the stuff work and get on with your life, if problems arise in the future we will fix them. American standards are usually but a formalisation of already accepted practises (and this goes well beyond network stuff), this is why they are so effective and so poorly thought out. I guess it's still better than "ideals" that nobody follows.
And of course this is an oversimplification of some sensitivity difference between vast parts of the world, we individuals are but samples on the agregate sociological context that drives this sort of things.
First to market wins if it works and solves the problem. That’s all there is too it. Nobody is going to wait around for something that might work that is theoretically better if you have an option that works and solves your problem.
IPv6 is a pragmatic replacement and it hasn’t even meaningfully killed IPv4 despite being widely available for nearly 20 years.
Yes, that was what my last point was about.
> First to market wins if it works and solves the problem. That’s all there is too it. Nobody is going to wait around for something that might work that is theoretically better if you have an option that works and solves your problem.
This way of framing the problem is weird to me. Markets are not handed to us by the Gods, we put them in place because some of us think they are a good way to solve problems. And in any case, consensus on green fields like networking at the time have very little to do with markets, at least in the economical sense (you could argue for a market of ideas but I don't think that's what you had in mind). But to give a famous counter example, most of the world have changed their perfectly fine system of units when a clearly better one emerged.
> IPv6 is a pragmatic replacement and it hasn’t even meaningfully killed IPv4 despite being widely available for nearly 20 years.
Not nearly as pragmatic as NAT.
Te be clear, I'm not saying that the pragmatic way is bad, in fact it's probably the best in most situations. I'm just pointing out that there might be psycho-social reasons for the non adoption of the OSI model by the network community. I could be wrong of course and I'm happy to read opposing thoughts on the matter.
EDIT: I re-read my first comment and I can see that I have been to dry in my writting and how it can be understood as "those damn Yankees are idiots!". I apologize for that, I'm trying to improve my nuances but still have a long way to go.
Markets exist no matter what. I’m speaking of markets in the economical sense, not a concrete “exchanging things for money”. Look up the phrase “market of ideas” to get a better feel for what I’m talking about.
> Not nearly as pragmatic as NAT.
You are proving my point. A solution that works good enough has immense momentum because the people that care to change are dwarfed by the people who don’t want to bother. IPv6 has a pretty solid sales pitch for ISPs (CGNAT is painful to scale, manage, etc), but they don’t have any say. It’s server admins that need to drop V4 to bring any forced change... and they can’t do that without losing visitors.
> I'm just pointing out that there might be psycho-social reasons for the non adoption of the OSI model by the network community. I could be wrong of course and I'm happy to read opposing thoughts on the matter.
It didn’t offer any clear upside worth the complexity. The shared l4/l3 with TCP/IP means people can easily use the OSI model between two hosts if they want. If the OSI model was actually better for writing software, it would be widespread already.
Being tightly coupled with temporary port of a temporary experimental API that happened because DoD wanted what was effectively "Emergency Capability IPv4 for Unix".
Once the broken design caused by BSD Sockets shows in one's program, it got progressively harder to fix it, especially given how ideologic the fight over APIs got. And then you had a growing installed base and vendors that lobbied against change because it cut into their profit margins, so requirement for OSI support was moved away and away.
"Good enough now" won over "won't stop working two years from now", so we built bandage over bandage over bandage.
Prescriptivism nearly killed the W3C as they were sat around writing specs for xquery or whatever and meanwhile browsers we’re trying to add features while having backwards compatibility with themselves and trying to have compatibility with other browsers. Instead, the W3C should have been trying to codify the sort-of standards of eg quirks mode to persuade browsers to be more compatible with each other.
And yet, they came up with 2 layers of stuff that only a limited number of applications actually use (session, presentation), 2 protocols instead of one at layers 2 and 3, a much more complex layer 4 protocol. The application side of network programming would likely be much more difficult if we had used an OSI network instead of TCP/IP.
Instead of reusing simple common blocks, we have tons of badly written textual parsers mired in historical details of early ASCII teletypes because the ARPA idea of protocol analyser was apparently "connect a teletype".
If you try to use a new protocol over TCP, you'll quickly find all sorts of corportate networks that will drop your traffic; you'll quickly find that people are reluctant to open several ports to allow both your Web GUI and your backend protocol to talk to each other.
So at a very basic level, people aren't piggybacking over HTTP itself, they are piggy-backing onto "Most Used GUI protocol". It's true that they sometimes adopt some of HTTP's features, especially in terms of caching or common error formats, but much more often they ignore it completely (with WebSockets) or partially (binary data in POST requests with custom error messages).
Just as HATEOAS and Content-Type negotiation are extremely rarely used in application protocols, I don't think a Presentation layer would have ever caught on realistically speaking.
Marshall Rose. he's a fantastic coder, and wrote the Open Book and the Simple Book and has done a lot of work in protocols, and IETF standards.
I have a lot of time for Marshall. he did a lot of work on MH, the mailsystem I used for years.
The Simple book is why we have SNMP and not CMIP (in some ways)
The OSI standards were thousands of dollars, I believe; a classic Big Standards move.
I think the writing was on the wall, right there. You're in college, what do you think the computer science folks are implementing and trying to improve, and teaching? Certainly not anything that cost real money, or that involved a towering bureaucracy, or language that no one could comprehend.
I remember the Arpanet flip-over from NCP to TCP, and that was a big deal. The TCP community had early experience implementing and getting stuff running at scale (for the time), with real users and expectations that things would more or less stay working.
"I hear they're moving to 42 layers, because it's a sacred number in Bali."
-- Michael Padlipsky
Nobody knew what those 7 layers were for. Nobody.
Your right that ISO's charging an arm and a leg for the printed docs was a mistake.
And the big switch only worked because it was done during the summer holidays and you could shut down things whilst it was done.
OSI would have not had the Omnishambles that is ipv6
Some people say there is an eighth layer which is of course "Politics"
The grad-level computer networking course I was taking in early '82 mentioned ISO (we used Tannenbaum, recently published, as a base text). The professor pretty much threw his hands up at all the ISO layers. "This is not how you implement networking in real life."
There's a lot to like in IPV6, as well as some things to hate. Transitions remain difficult, but seem unavoidable (sooo much software smuggles IP addresses in 32-bit ints, and changing millions of lines of code and updating database schemas to match is not very much fun).
This was a great, well written article. Even as a network engineer, I learned some things. Never hurts to study the fundamentals.
I learned the OSI model, and it was presented as “And THE LORD sayeth ‘LET THERE BE SEVEN LAYERS.’ And it was good...” and so forth. It was presented as “This is the way we do things.”
And I have never actually seen a true implementation of OSI “in the wild.” It was confusing.
It was useful, in helping me to look at communications in an organized fashion (I’ve written a fair bit of that kind of stuff), but in the same way that reading historical fiction teaches me about the Victorian Era.
I also learned X.400 as an exchange protocol. Folks these days, should give thanks at dinnertime that Professor Van Helsing drove a stake through that nightmare.
And x.400 had stuf that internet mail took a decade to catch up to and some cases does not have non repudiation for example.
It did, indeed, have many things that we wish email had, these days, like true read receipt and routing management.
But it was a complex beast, and that is why it lost out to simple SMTP and POP.
They also used PRIMOS. I worked in FORTRAN (4), PL/1, and C.
What would be really strange if you worked on GLE a PL1/G program the US side made for our Billing system.
The legacy stuff was FORTRAN. Did I say 4?
My mistake. '77.
A hundred KLoC of spaghetti, just like Mama Mia used to make.
The X.400 stuff was in C, but I'm not sure that the stuff I worked on made it to the customer. We wrote a mover application.
The ISO Development Environment [1] was open source.
[1] https://en.wikipedia.org/wiki/ISO_Development_Environment
Those three applications aren't particularly compelling. I never encountered them.
This is a bit harsh.
I downloaded Minix updates, and indeed my first Linux kernel disk images, over an X.25 network.
X.25 was one of the first packet-switching protocols - predating IPv4 by a few years - and therefore is very much NOT an analog to telephone (circuit-switched, predominantly, historically and at the time) networks. (Okay, there were VC's, let's not muddy the waters.)
I recall in the early/mid 1990's a colleague hunting down a weird X.25 network utilisation pattern, where a customer was establishing and tearing down connections at a rapid rate of knots. Details are fuzzy, it was a long time ago, but IIRC the customer had worked out how to embed payload in the connection establishment header, but at the far end was refusing that connection (while ingesting the payload). Billing was done based on connection establishment and subsequent transfer. Great (loophole) success, etc.
TFA touches on SNA (IBM's System Network Architecture) but doesn't seem to attribute as much blame to it as I believe we should. SNA was, coincidentally, a 7-layer model. The obvious distinction, to modern minds anyway, is the hierarchical vs peer relationship between entities on a network. (An interesting question to ask graduates is to define a network -- this historical view disparity is objectively fascinating in the contemporary context where peer addressability is an assumed function of same.)
Er, what? What network protocols even use nul-terminated strings?
Even if this is referring to programming languages’ native string types, nul termination only won in C, while just about every other language uses some kind of explicit length encoding.
But then as a mental model in order to understand that, it's important to think about the layer 1 of what the wifi radios are doing: Questions such as, why is this Comcast 802.11ac home router running in an 80 MHz channel, stepping on this other device that's also trying to run in the same 80 MHz channel? Why did somebody install a unifi AP with a torus shaped RF pattern vertically on a wall, instead of horizontally on a ceiling as it was intended?
Visualize if you were to take a pencil and skewer it lengthwise through an oval shaped fruit, the fattest part of the fruit would be the highest gain part of the antenna's RF pattern.
E.g. in theory your router should work with level 3 and below. This includes the firewall. However, try to implement a new Level 4 protocol and all of a sudden your packets won't route.
This was the whole point of this separation - that while UDP and TCP are useful in general cases, there are much better and novel ways to frame packets for e.g. cust infrastructure with different properties and different requirements.
But it simply doesn't work.
This stuff has driven me nuts for decades. OSI has rarely been helpful aside from just general communication of ideas. It shouldn't be used as any authoritative reference, ESPECIALLY not in classrooms.
If you look at the configuration on a typical small but powerful router (I'll use a Juniper MX204 for an example), of course it's doing things at both layers 2 and 3. It's a useful model to define what is going on with various ethernet switch fabrics, before you try to understand how it's set up at layer 3. At layer 2 you could have a 100GbE interface that carries a vlan trunk going to a 1RU 48-port switch physically adjacent to the mx204, to create local subinterfaces on the router to 10Gbps PNI peers, to downstream colocation/datacenter customers, etc.
That's all traditional "layer 2" ethernet stuff. Then your logical subinterfaces themselves are configured as BGP peers, which is of course layer 3.
Understanding the model of your theoretical MX204 you've got:
layer 1: AC or DC power, cabling, fans, physical mounting, serial console cables
also layer 1, but has an impact on how you can configure stuff at layer 2: Does this port have a short reach 100GbE CWDM4 interace in it? Or a longer reach coherent? Maybe this 10GbE port has a 1490/1550 bidi single strand in it?
layer 2: Ethernet configuration in all its myriad ways. And also things like P and PE MPLS configuration to carry a layer 2 circuit between places over your layer 3 network. Configuration for ISIS would also go in layer 2.
layer 3: bgp, ospf, all the typical "router" stuff.
Layers seem OK for dividing protocols, but networks tend to be managed across all layers, so it's understandable all that functionality gets put in a single device - possibly internally structured one. I'm not a network engineer, but what I understand from the admin panel of my Mikrotik router is that the mental model here is a bunch of virtual devices, each working on one of the layers, packaged into one physical box.
https://www.cisco.com/c/en/us/products/collateral/switches/c...
But you for sure wouldn't call it a router because it has nowhere near the routing table RAM, routing ability, or full set of routing configuration parameters as you would want to use on a dedicated purpose router.
For your mikrotik, if you open it up or if you look at someone's teardown of one, what you'll see is a set of gigabit ethernet switch chips (perhaps 1 ASIC per every 4 ports) under heatsinks, that have purely layer 2 feature sets only. And then one CPU that runs the mikrotik routerOS which does layer 3 things. The mikrotik will have different levels of performance in packets per second capability for traffic flows that stay at purely layer 2, and another level of capability in Mbps and pps at layer 3. The OS on the mikrotik knows how to tell the switch chips how to do things at layer 2 (define this vlan, define this trunk, group certain ports into the same fabric, do 802.1x stuff, etc).
for instance here's a block diagram of a mikrotik rb4011: https://i.mt.lv/cdn/product_files/RB4011iGSplusRM_180903.png
Since routers act as gateways, they have their own IP address too.
Switches are not gateways. They join two physical segments and mask them as a single logical segment. They do routing only in the most basic of senses - moving packets between the physical lines.
If you’re talking about something that is just routing and not doing a higher layer operation like NAT then routers don’t care about layer 4. The huge routers running the Internet backbones absolutely don’t care about layer 4 protocols and support arbitrary L4 protocols.
What you’re thinking of is normally sold as a “home router”, which is actually a NAT device that is only a router in the most basic sense (has directly connected interface routes and a default route). NAT is the thing that breaks the transparency because it has to modify and track layer 4 protocol fields in order to disambiguate all of the traffic coming into the single IP address you get at home.
It would not be possible with most SOHO routers because they use NAT which mostly only compatible with TCP and UDP (though a more advanced SOHO router is capable of doing 1:1 for other L4 protocols).
My work involves writing software for big routers and switches used by ISPs, data centers, campuses, etc. and I can guarantee you that a router will 100% switch/route your exotic packets with an unknown L4 protocol number. It literally does not care about anything past the IP header.
There are a few things I can think of that may have led to your experience, one of them is NAT. Well, NAT just sucks. It is the reason why I want IPv4 to die. Just getting rid of NAT will be worth the pain of switching to IPv6.
PS - IPv6 NAT is just downright stupid.
Far more common today is to handle unusual "L4" protocols by tunneling them, which leads to another increasingly common situation that teaching via the OSI model does not prepare students for: "L2" protocols tunneled back through an "L3" protocol. Or in telco networks usually, through a different "L2" protocol (MPLS, ATM, pick your poison). These are all things that the layered network model empowers us to do, but the "OSI-first" teaching approach, at least as I have seen it, mentions scarcely or not at all.
While it is very true that the OSI Reference Model doesn't map to real life systems exactly, it's still a relatively accurate view with a little bit of hedging as to what layers something might fit into. Additionally many of the protocols that were built for OSI networks have been adapted and implemented on top of TCP/IP networks and are extremely valuable in some circumstances at global scale, because the telecoms people designing these systems /thought about/ global scale from the get-go, where-as it was mostly an afterthought for later computer systems researchers. X.500 in particular is a fantastic protocol, that while convoluted and esoteric, enables some very complex replication topologies while providing strong guarantees that are simply not possible in lighter weight protocols. When thinking deeply about identity management and authentication, X.500 is not a bad thing to fully understand, even if you end up implementing a lighter weight protocol, because while "over-engineered" it's well thought out.
That said, ASN.1 notation is a hellacious curse and should have been burned and buried in the pit it came from before it ever saw the light of day. Unfortunately, it's a key component of nearly all the X. series standards built on top of OSI.
https://web.archive.org/web/19990826193318/http://www.europa...
Edit: Just finished reading. As someone who has been putting off learning about the network stack, I'm glad I read this.
I could probably do something with CSS to swap it for a version that isn't sensitive to reflowing. I'll put it on the todo list.
header > pre {
overflow-x: scroll;
scrollbar-width: none;
white-space: pre;
}
header > pre::-webkit-scrollbar {
display: none
}
font-size: 6px
Vestiges of the presentation-layer like stuff exist in ntohs() and friends.
More honestly, though, I think the OSI model can be used very constructively in teaching by contrasting it with IP. IP is simpler and also less feature-rich; you can learn a lot about IP by noticing which aspects of the OSI model were "left out" from IP (putting it that way muddles the timeline but probably also isn't that inaccurate) and how it varies from what was designed at one point as a "complete" protocol set. But this is all a part of my larger philosophy of a "historical approach" to teaching networking. It's not too uncommon for instructors to do this by discussing X.25 and/or ALOHA early on and then comparing/contrasting IP, but for whatever reason it is typical to introduce the OSI model alongside IP without the historical context of what the OSI model is and isn't useful for today.
In the telecom world at that time the fundamental unit was the "circuit", meaning a two-way voice telephone call. The upper frequency limit of a voice circuit is 4kHz, so the Nyquist criterion said that digitising a voice circuit required 8,000 samples per second. The required signal to noise ratio fit nicely into 8 bits, so a digital circuit was 64,000 bits per second each way, with strong real-time jitter and latency guarantees (because, voice).
If you weren't using the link for a while you still had to pay for it by the second because you were getting the guaranteed 64,000 bits per second all the time; that bandwidth was reserved for your use and nobody else could mop up the spare. Meanwhile the correctness of the received data was best-effort because the odd corrupt bit isn't an issue in a voice circuit. If you wanted more bandwidth then you could pay for multiple circuits to the same destination.
In telecoms all the intelligence goes into the exchanges; the phone is merely a dumb end-point. If you want services like call forwarding you type numbers into the phone, but all the application software lives at the exchange.
If you talked to telecom engineers about the future, they would talk about video calls. They would be just like phone calls but with higher bandwidth.
Meanwhile the computer people needed the exact opposite to what a voice circuit provides. If you send a file another computer you need it to arrive bit-for-bit accurate, but you don't much care about bandwidth and latency. While a physical pipe has a certain capacity, you don't need or want to reserve bandwidth on it, you just want the data to move as fast as physically possible.
So telecom people wanted to provide a smart network connecting dumb end-points, with guaranteed bandwidth and latency with best-effort correctness, while computer people wanted to connect smart end-points to a dumb network that provided guaranteed correctness but only best-effort bandwidth and latency.
Things got worse when the Web started being used by people at home. Now most of the data was flowing in one direction, but circuits were fundamentally about equal bi-directional communication. So now half of that expensive bandwidth was being wasted.
The "adults in the room" attitude of the telcos didn't help; they had over a century of experience running international telecom networks and thought they knew how to do it. Therefore they weren't interested in the opinions of those hairy computer guys.
For more on this, read "Mother Earth, Mother Board" by Neal Stephenson.
As computer users, every day we live with the pros and cons of this difference in philosophy. Our network links are much faster but much less reliable than they would be had, e.g. the ISDN vision which I've mentioned before on computer.rip gained more traction. For a long time applications like video conferencing and newsgathering stuck to ISDN rather than the internet because of the "cons" in the tradeoff. You imagine a world where, say, an online video stopping to buffer is as rare as a kernel panic, but you've also got to check if your internet subscription covers a reservation of that size.
Come judgment day I think there is guilt on both sides, telecom people broadly did not foresee the huge capabilities of "opportunistic" (e.g. contentious) network utilization, but computer people broadly did not foresee the demands of real-time media over computer networks. Despite AT&T's dedicated but haphazard efforts through US vs. AT&T, the telephone industry did not gain serious traction in the nascent world of computers, and then computers took over telecom, and so we all just sort of live in the world of contentious networking now and it's hard to imagine it a different way.
Thinking of something that might be equivalent to “NAND to Tetris” for networks. I want to know how the wires work fully!
Generally though you really don't care about how the data gets on the wire (I mean it's definitely interesting but it doesn't help you any more at a practical than thinking about what happens at the ethernet frame layer).
Also when it comes down to it not only is the physical encoding wildly different most each step of the way but it's not even ethernet. I.e. the only thing that matters are the guarantees of the socket interface, not the guarantees of what it rides over. The socket may ride over some transport which guarantees in order delivery and no congestion or it may ride over some transport which guarantees nothing, not even in order delivery. What matters is what the socket guarantees, e.g. is it a TCP socket provided by the OS where the OS guarantees it'll reassemble, handle loss, handle out of order, etc for you or is it something like a UDP socket which leaves most of these up to you (or a raw socket where the OS really isn't doing much of anything for you).
That being said if you want to pick a single example just to walk through it bottom to top one time pick 1G RJ45 copper between two PCs which have a TCP session going. There isn't really a need for a book, just the Wikipedia articles on gigabit Ethernet, IPv4, and TCP. It's just that this isn't always the stack so it doesn't really matter what Ethernet/IPv4 happen to give you - all that matters is what the TCP socket says it's going to guarantee.
ARP and IP are fairly easy to implement, and TCP is as well as long as it doesn't need to be fast (e.g., live with a fixed and smallish window size, discard out-of-order packets, don't bother with selective ACK, etc).
So true. Worse, it's useful to use an expression like "down below layer 3" knowing it's a rough metaphor; yet that credence gives credibility to what turned out to be a muddle headed idea.
(Though anything above layer 7 is an inside joke)
I am truly curious what critics of the OSI model propose as catalyst for such conversations.
https://en.wikipedia.org/wiki/OSI_model#Comparison_to_other_...
The article seems to skip over concerns about layer 1. But if you have no understanding of how things are engineered at layer 1, or of the possible failure modes, all sorts of bad things can happen. Or you'll end up buying the wrong thing, or getting bamboozled by equipment vendors once they realize you're not paying attention to the layer 1.
People not understanding layer 1 are how things happen like an ISP sending out somebody to try to install a 10GbE 1310nm/LX circuit to a piece of equipment that was shipped with a multimode SFP+ in it.
Engineering of large complex backbone systems encompasses the overlap between layers 1 and 2. For instance all of the optical engineering that goes into a inter-city DWDM system is "layer 1" - but those same DWDM chassis have 10/100GbE short reach layer 2 transport circuits hanging off of them, to connect to your own ISP's or customers' ISPs' network equipment. Then the controller card in your DWDM system is likely running some form of embedded Linux and has a 100BaseTX/1000BaseT interface in it with an IP address in a management network, it can have an snmpd on it that exposes a set of OIDs to poll by network monitoring gear, it runs an sshd on it it, etc. So you've got layer 3 and layer 4/5 stuff going on in that same 10RU DWDM box which needs to be taken into account in your network design. Maybe you have a system somewhere which periodically retrieves a text dump of the entire configuration of the DWDM box, whatever its equivalent of a 'show run' is, and stores it in git? That's all layers 4-7.
In the modern all-ethernet world, tons of possible configuration parameters for exactly how the 10 or 100GbE handoffs are set up on each side. And various configuration parameters. Ever encountered somebody who mistakenly ordered a 10GbE WANPHY circuit when it should have been LANPHY, or vice versa? That's an example of why an understanding of the underlying layers of what you're working on is important.
Only once you have a good solid grasp of layers 1 and 2 can you begin to properly architect your network at layer 3.
One thing that I do try to repeat as often as possible, if helping to train NOC and junior neteng people, is that things get very blurry between how software is set up at layers 4-7. The same piece of software that might be doing things at what the OSI model would call layer 4 may also have a end user GUI/presentation/operator interface that would be defined as layer 7. I do not think that mentally imagining rigid definitions between layers 4-7 is very useful these days.
I personally think that as a method of understanding network architecture, the first level of layers 1-3, and 4, are much more useful than the blurry "4-7" model.
1) Link (physical)
2) Internet (IPv4 or IPv6 these days)
3) Transport (UDP or TCP or whatever)
4) Application (stuff handled by the application logic)
Which is precisely what people mean when they say the OSI model is bad to teach. It's not that using a layered abstract model is bad for teaching it's that the 7 layer OSI model is bad for teaching.
People doing stuff with networks need to be aware that the physical (layer 1) is its own distinct thing from layer 2: the link layer network (such as Ethernet fabrics, ethernet as wifi, SDH/SONET transport systems, whatever sort of network accomplishes the purpose of putting multiple devices on a fabric where they can talk to each others' NICs).
And then layer 3 as the IP network protocols.
In an opposite example, you can build an IP network out of two devices that are adjacent to each other over a SDH/SONET network, and there's no Ethernet anywhere. Something as simple as two routers with OC192 interfaces sitting next to each other on a test bench with a fiber patch cable between them, as a BGP adjacency.
It blew my mind when I realized that the difference between malware and "military grade" malware is just that they target exactly those token ring'ed devices, where they try to craft network packets where they know that the implementation is gonna fail in the parsing process.
Once you realize that and the underlying containers that come with it, you can efficiently redteam anything. Cisco deep packet inspecting switches? VLANs? VPNs? No problemo, they got an outdated linux on there, too. And they usually don't have the RAM to compensate for buggy implementations either.
The last plant I looked up (Wisteria) doesn't really have a useful phylum or class classification, and has 7 non-mappable "clade" groups of which it is a member. They still teach the 8 levels though.
Presentation - HTTP
Checkmate, OSI-haters.
This further makes the point that many of the differences between TCP/IP and the OSI model were very intentional choices, as the OSI designers were well aware of IP and viewed it as unsuitable while the adopters of IP were judging the OSI model to be impractical.