Hacker News Reader

Comment by kragen | Hacker News Reader

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.

View on HN

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.

BTDTGTTS https://shop.isc.org/collections/shirts/products/osi-9-layer...

I can't claim to have BTDT, but I did get the T-shirt. That's how I learned them :)

But we freakin have those layers now. Above TCP/IP there is SSL, and then about that https, and within that there's some JSON RPC or whatever.

The first few OSI layers are fairly readily identifiable in TCP, IP and Ethernet, and some of the rest are built by applications.

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.

Also, if you happen to be familiar with X.225 (or read it following my prompt above), I have some questions in https://news.ycombinator.com/item?id=41789004!

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.

I'm interested to hear what you think! I haven't finished reading it yet. It's a bit repetititive.

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.)

From page 11: "OSI was designed primarily around the dumb terminal connected to a mainframe."

Also from page 11: "'session' meant something related to attaching videotex terminals to mainframes."

And yes, all Ceefax terminals were Videotex terminals, but not all Videotex terminals were Ceefax terminals.

I might recommend that instead of guessing what the session layer is, you (or more appropriately, Mr. Graham) go and look at what the specs say it is and what it's used for. The X.225 spec is available for download at https://www.itu.int/rec/T-REC-X.225-199511-I/en. X.215 is available at https://www.itu.int/rec/T-REC-X.215-199511-I/en.

The OSI session layer is not related to HTTP session cookies as the original author proposes.

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?

OSI was was two network stacks fighting with each other, the circuit-switched telco X.25 successor and the packet-switched DEC / Xerox anti-Internet.

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.

Each of the articles linked upthread separately explain why everything you said in your comment is incorrect.

I withdraw the above comment; they do explain why many things in OhMeadhbh's comment are incorrect, but not everything.

Reply on news.ycombinator.com