I remember when I had a lesson about OSI layers, where the teacher has carefully described all the layers in detail
and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"
Oh, there's an entirely different feature-length article to be written/found about how packet switching beat circuit switching and the "Internet approach" beat the telco approach. The great innovation of being able to deploy devices at the edges without needing clearance from the center.
I don't think very many people even remember X25. The one survivor from all the X standards seems to be X509?
The OSI stack was also designed using the packet-switching approach. Rob Graham's "OSI Deprogrammer" is a book-length article about how TCP/IP beat OSI, and how the OSI model is entirely worthless: https://docs.google.com/document/d/1iL0fYmMmariFoSvLd9U5nPVH...
I'm not sure he's right, but I do think his point of view is important to understand.
Wow, you're not kidding about book-length: at 246 pages, that's an epic takedown. Learning all kinds of other things about networking along the way, though.
I do remember all nine layers of the OSI stack though: physical, data link, network, transport, session, presentation, application, financial, political.
Having just skimmed X.225 thanks to OhMeadhbh (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...) I think Graham is correct that we don't have anything similar to the OSI "session" layer in the stack you're talking about; although the ARPANET TELNET protocol does have a lot of the same functionality, there's nothing analogous in SSL+https+JSON+RPC. I'm guessing the same is true of the "presentation" layer, but I'm certainly open to hearing why you think otherwise, if you do.
Graham makes a good argument that, although there are some promising analogies between the physical/data-link/network/transport layers and the PHY/MAC/IP/TCP layers of TCP/IP over Ethernet, the model is overall a very poor fit even at those layers; it's better to not try to decompose network stacks into a predetermined set of layers, because the actual set of layers used is variable depending on the application and the environment.
Wow. That is awesome, I skimmed through it and it looks like something I will enjoy. I've still got my Tanenbaum Computer Networks book from 1996 and the first chapter starts with OSI, then TCP/IP, and explains the differences and why OSI failed.
It doesn't seem like a "take down" as much as a re-iteration of all the things IBM, DEC, GE and various Telcos did wrong when implementing OSI. I could reduce it to one sentence: "Everyone was so intent on monetizing their own networking implementation they never thought enough about interoperability."
Not only isn't that an accurate summary of Graham's book, it isn't even a topic discussed in the first half of the book, which is all I've read so far. I suspect it isn't a topic discussed in the book at all; can you back up your assertion with some quotes?
Yes, but the book also has enough inaccuracies as to make it... I don't know what. For example, in the first chapter the author says "no one knows what a session is," which is patently false. I myself implemented control logic in telco equipment to respond to X.225 compliant messages to change the state of an abstract state machine used on either side of the connection. And while I'm sure it's possible to use CONS or CLNP to communicate with a CEEFAX terminal, that is far from the only use to which the various OSI compliant protocols were put.
Just because you don't understand something, that doesn't mean it's bad.
I think he means to be saying that, in the context of TCP/IP, nobody knows what a “session” in the OSI sense would correspond to—not that nobody has ever implemented X.225. Presumably Graham knows that people have written X.225 implementations and isn't trying to convince his readers otherwise?
I don't know enough to judge his assertion that the session layer exists to solve problems created by half-duplex terminals. (He doesn't seem to specifically call out Ceefax.)
Hey, thanks! I had looked for it when writing my previous comment, but I skipped past the ITU links on the assumption that I'd have to sign over my first-born children in order to get a copy. But it turns out that they aren't currently restricting its availability: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...
Clearly "videotex" is wrong. Skimming X.225, though, an awful lot of it does seem to be concerned with ⓐ half-duplex terminals and ⓑ T.62 teletex (not videotex, closer to telex) terminals. So "attaching video terminals to mainframes" does seem like a fair summary. Possibly Graham doesn't know what the word "videotex" means, or thought (as I did, neither of us having lived in Germany) that "teletex" was a kind of videotex.
I agree that it doesn't have the kind of functionality that HTTP cookies provide. That's backwards, I think? HTTP cookies provide session context that persists over multiple TCP-level connections; the reuse of a single transport connection between different X.225 sessions is more like reusing a single TCP-level connection for multiple HTTP requests, or multiple users logging in and out, one after the other, on the same hardwired terminal without resetting it?
I wish it gave examples of usage so I knew what the resynchronization functionality was for. Maybe you know?
Expedited data is a thing that TCP also has, and I've never really understood what it was for there either. Maybe it's for sending a ^C over a remote terminal login session when the keyboard buffer is full because the application you're talking to is hung? The "activity interrupt" stuff seems like it would be a better fit for that, but maybe the expedited data facility was an older design that was retained for backward-compatibility?
This is great, thanks! crawford's post pulls no punches:
> Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle. It's nonsensical to the point of farce. The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain significant real-world adoption.
That's sort of like saying "TCP" is a failure because everyone now uses SSH instead of TELNET. TCP/IP still has to do all of the things the OSI stack does, it just does it in a different manner and there are (thankfully) plenty of well defined wire-formats and processing expectations so interoperability is pretty straight-forward. But I still think IPSec would have been MUCH easier to deploy had TCP/IP maintained a rational distinction between presentation and session layers. I guess what we learned is that SSL/TLS and FreeSWAN's assumptions about routing encrypted payloads were "good enough."
Also, if you're going to compare TCP/IP to various OSI implementations, you should compare the full stack including PEM, MOSS, SMIME, SSL/TLS, SSH. Each muddies the difference between presentation and application layers, but as in the previous paragraph, no one seems to care. Talking SMTP over SSH (or SSL/TLS) is totally fine; you don't need to have a sub-protocol to define how a presentation layer on top of a secure session layer works if you can make certain assumptions about the behaviour of the code on the other side of the network connection.
I think naming quality isn't really a difference between OSI and TCP/IP. I'm sending this message in URL-encoded UTF-8 in MIME over HTTP over TLS and TCP, IP, MPLS, DOCSIS, and an 802.11g CSMA/CA MAC in a CIDR IP block allocated by ARIN via LACNIC to an AS that belongs to a CLEC; ultimately you'll use an URL to read it in HTML, and if your UA is like mine, you'll use ECDHE ECDSA with AES-256-GCM and SHA-384, verified through a CA chain through E5 (which supports OCSP) and ISRG. But nobody bats an eye at that because that alphabet soup has been familiar for decades.
I found this article helpful when I had that same question. Basically BER has some less rigid specifications for how to encode the data that can be convenient for the implementation. Such as symbol-terminated sequences instead of having to know their length ahead of time. But this means that there are many equivalent serializations of the same underlying object, which is problematic for cryptography, so DER is an unambiguous subset of BER which will have only one correct possible serialization for a given object.
> "How do you scare a Bellhead?" he begins. "First, show them something like RealAudio or IPhone. Then tell them that right now performance is bandwidth-limited, but that additional infrastructure is being deployed."
You'd scare anyone like an amazed rural tribesman if you showed them an iPhone in 1996.
I know, IPhone was a Cisco thing, but my mind went there for a beat ;)
This might be fiery take, but I think the X.400 standards for naming and messaging would have been a lot better than the chaotic email situation, and probably would have made more sense from a commercial/legal perspective than making DNS "the" global naming system
I enjoyed how we got taught the two models in the 1990s, and why one has the four layers you need and the "standard" has seven layers instead.
The professor asked "How many layers do you count?" - "Seven." - "How many members do you think the ISO/OSI committee had that designed it between them?" - [laughter] - "Seven.".
IMO the OSI layer system (even though using TCP/IP suite) has some merit in education. To most of us, the concept of layering protocols may seem obvious, but I've talked to people who are just learning this stuff, and they have a lot of trouble understanding it. Emphasizing that each layer is (in theory) cleanly separated and doesn't know about layers above and below, is a very useful step towards understanding abstractions.
There are; VNC doesn't know about IP, for example, and TCP doesn't know about Ethernet. IP is just as happy to run over PPP or Wireguard as over Ethernet. HTTP/1 knows about TCP/IP, but only a little bit, and you can easily run HTTP/1 over other protocols like TLS. Character-cell terminal protocols know very little indeed about the protocol layer under them and work almost equally well over telnet, rsh, SSH, a serial port, a modem, or a bare pseudo-TTY, the main surviving exception being window resize handling.
The problem is that ① the layers don't have a fixed relationship to each other the way the OSI model proposes, ② several of the OSI layers don't exist at all in real-life TCP/IP protocols, and ③ there are other layers in current stacks that have no analogue in the OSI model, like Wireguard, MPLS, SSH, TLS, and HTTP. If you want to understand the services HTTP provides to the protocols that ride on top of it, you need to read Roy Fielding's thesis, not X.225.
and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"