Live data from Hacker News

The OSI Deprogrammer

docs.google.com

41–50 of 95 posts

Re: The OSI Deprogrammer

#41
post #31
post #27

Earlier quoted context omitted.

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.

Like what?

Re: The OSI Deprogrammer

#42
post #6
post #4

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. Then, read: https://web.mit.edu/Saltzer/www/publicat…

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.

Re: The OSI Deprogrammer

#44
post #5

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.

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.

Re: The OSI Deprogrammer

#46
post #7

This is funny 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".

Re: The OSI Deprogrammer

#47

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 neve…

You might like this as well, imo it's more entertaining and flows better

https://apenwarr.ca/log/20170810

Re: The OSI Deprogrammer

#48
post #14

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.

The book has an extensive section on history.

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.

Re: The OSI Deprogrammer

#49
post #10

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?

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.

Re: The OSI Deprogrammer

#50

> 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 t…

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 conte…

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

Post reply on HN