Live data from Hacker News

The OSI Deprogrammer

docs.google.com

81–90 of 95 posts

Re: The OSI Deprogrammer

#81

Earlier quoted context omitted.

People are seduced by their own ignorance. 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 p…

Well, you sort of demonstrate my point. 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 beg to differ with you on all counts.

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.

Re: The OSI Deprogrammer

#82

Earlier quoted context omitted.

Well, you sort of demonstrate my point. 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 beg to differ with you on all counts. 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 prero…

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.

Re: The OSI Deprogrammer

#83
post #77

Earlier quoted context omitted.

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

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

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.

Re: The OSI Deprogrammer

#84
post #42

Earlier quoted context omitted.

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.

Layer 4 is the lowest layer of the OSI model that isn't packet-based (i.e. can handle messages of arbitrary size). 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.

That’s not true, though: the OSI model has connection-oriented services at the lower layers too.

Re: The OSI Deprogrammer

#85

Earlier quoted context omitted.

Well, you sort of demonstrate my point. 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 beg to differ with you on all counts. 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 prero…

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!

This author is attacking a Straw Man.

Re: The OSI Deprogrammer

#86
post #68

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

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.

Re: The OSI Deprogrammer

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

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.

An amazing analogy. Thank you. I've recently been asked the OSI layers in an interview. I think it was done as a joke.

Re: The OSI Deprogrammer

#88
post #22

Earlier quoted context omitted.

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

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

> 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 Windows 2000 manual that describes its support for token-ring networking. Windows 2000!) In a fully post-Internet era, when everyone is using Internet protocols, a "network" could no longer offer much to differentiate itself. So we started to see shifts to actually standardize on LAN technologies, with vendors all moving toward making the same stuff. At that point, border gateways began getting simpler, and companies like Cisco that had made their fortune in the AS-border-gateway space stopped being household names, instead being relegated to the NOC (as they had successfully pivoted into dumb-but-high-throughput enterprise LAN switching, and even-dumber-but-even-higher-throughput Internet backbone switching.)

Re: The OSI Deprogrammer

#89
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?

Re: The OSI Deprogrammer

#90

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…

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.

Post reply on HN