APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

The Seven Layer inedible OSI cake

© August 2013 Anthony Lawrence

I have always disliked the OSI model. No offense to the folks at ISO (though using a jumble of your own acronym is, well, conceited), but I have my reasons.

The first is that the damn thing is hellishly difficult to memorize. I was given the mnemonic "A priest saw ten nuns doing pushups". That's not very helpful. There are other mnemonics, but none of them are useful in any sense whatsoever,

Yesterday (or perhaps earlier; time is nebulous in my world), a customer asked my why a vendor from whom he was attempting to buy a new switch was blubbering on about "Layer 2" as though that were important.

I became angry. My feeling is that customers should send checks and keep their yaps shut, especially when it comes to questions like this. Call me up and ask "How's the weather up there?" and I can, with some effort, answer pleasantly, but seriously: how is anyone expected to politely respond to questions about the OSI model?

My wife, another hellishly demanding person, disagrees. She expects me to respond to such bleating on the theory that this will keep checks arriving in our mailbox. To keep marital harmony, I agreed to write up an explanation for my customer and I gratuitously offer it to you, complete stranger though you may be.

One: Physical Layer

This is another reason I detest OSI. This layer defines the electrical and physical aspects of the data connection. They toss that off lightly as though that were nothing at all, but in fact, unspeakable acts of cruelty happen right here.

Here, at the physical layer, innocent newborn packets are shoved out into a highway jammed with other packets. Are these packets traveling in an orderly fashion, politely making way for the newborn? Not on ethernet they are not. Screaming along at reckless speeds that can exceed billions of bits per second, new packets can be overrun by their feckless cousins and the resulting carnage is truly awful. NO PACKET EVER SURVIVES A COLLISION LIKE THAT!

Two: Data Link Layer

Another disgusting layer only made necessary by the callous disregard of the Physical Layer. Among other things, this layer has the responsibility of watching the carnage caused by injecting packets blindly as we learned above.

This is, in fact the Layer 2 my customer asked about. It is ugly. That's all you need to know.

Sigh. My wife says that my customer may need to know more. Very well: the salesman mentioned Layer 2 because somebody taught him that was a good way to make you think that you might need another layer and that other layer is more expensive, thereby making bigger checks flow to HIS mailbox.

We talked about this. For your needs, Layer 2 is enough. Please leave it at that; I'm tired and have five more layers to explain.

Three: Network Layer

This is the bully of the OSI model. Here we have a happy little packet, all shiny and bouncy, zipping along bothering nobody (unless the stupid physical layer throws a newborn in front of it). It runs into the network layer and its life can suddenly be changed forever. This layer can say "Hey, you! Over here! Let me have a look at your papers, mister. Aha, just as I thought: you are going to China!". And then, with no sympathy what so ever, this young packet, usually barely out of childhood, can be thrown out to the Internet where it has to associate with really unsavory characters. It's barbaric and heartless and yet another reason I hate OSI.

Four: Transport Layer

Nobody likes the transport layer. As we have learned, the physical layer is a horribly uncaring parent. Dead packets are nothing to it, but higher layers do care about these poor things and the miracle of Engineering allows the transport layer to request the recreation of damaged packets.

The physical layer often objects to this duplication of effort and will audibly snarl, but really: whose fault is it? Yes, we are looking at you, physical layer.

Five: Session Layer

This is often described as the "connection" between computers as though two machines had reached out and are holding hands, smiling at each other. The music fades and we move to a long shot of two computers living happily ever after.

Nothing could be farther from the truth. Computers have been taught to distrust each other and will reject attempted connections most of the time. Nowadays, most computers and firewalls are utterly rude about it: it would be like asking someone to dance and having them ignore you as though you were invisible and inaudible. Why does the OSI model allow such insensitivity? They hate love, apparently.

Six: Presentation Layer

Doesn't that put a pretty picture in your mind? Perhaps you imagined a packet arriving at this layer and being immediately surrounded by attentive servants who pick out new clothes, fix the packets hair and apply makeup before it goes on to the the final stop. In fact, this layer is more like forced re-education camps, where packets may be stripped of their original structure and repacked so that even their own mother wouldn't know them. Why does this happen? It's because the sending computer may be EBCDIC and the recipient may be ASCII. Too lazy to learn each other's ways, these computers let the presentation layer do the dirty work.

More and more packets are also asked to disguise themselves - this is called "encryption" which comes from a Greek word that supposedly means "hidden". Utter nonsense: these packets aren't hidden, they are jumbled and obfuscated and it is the presentation layers job to figure out what they really should be. This is not easy work, which is why the presentation layer is often in a bad mood.

Seven: Application layer

This is where the poor packet, having survived the high speeds of the wires, having been shoved here and there, torn apart and reconstituted who knows how many times, finally reaches its destination.

What happens then? Is there a ticker tape parade and heartfelt thanks from the computer it has reached? No, my friends, there is not. The poor packet is immediately gutted, stripped of its protective layers and tossed into the hungry maw of whatever application (mail, a webserver, whatever) it belongs to.

That's it. It dies there, unloved and unremembered. I cannot abide the brutality of the OSI model!

Gory details

It is said that there is no honor among thieves and it is also true that there is no love lost between OSI layers. As has been intimated above, these layers cooperate, but only grudgingly. For example, when something is not understood at the transport layer, a RST packet is sent.

Nobody likes a RST packet. This is the OSI equivalent of your dinner companion spitting food into a napkin and then handing it to you. It's beyond rude; it is unconscionable.

There are lighter moments. An "URG" package can be sent. This is very much like marking a package "Handle with Care" in that it is a cause for great amusement by everything that sees it. "Oh, you are urgent, are yea? Here, I know a shortcut", and the gullible packet is sent down the wrong way where it will become lost and confused and may never find its way home.

The future

In recent years, we have seen the development of super-conductivity. While this technology has not yet reached the masses, rumors are that elements of the OSI model (specifically the "bully" layer explained above) plan to route packets into circular super-conductors where the poor things will loop endlessly. This is an example of the fiendish sadism yet to come.

In closing, I hope that you will join me in fighting against the OSI model. I believe that we could develop a kinder, more gentle model if enough of us raised our voices in protest.

Will you join me?

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> The Seven Layer inedible OSI cake

Inexpensive and informative Apple related e-books:

Take Control of Parallels Desktop 12

Photos for Mac: A Take Control Crash Course

Photos: A Take Control Crash Course

Take Control of Apple Mail, Third Edition

Digital Sharing Crash Course

More Articles by © Anthony Lawrence

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

As I said in my comments to the committee, [Fortran 90' would be a] nice language, too bad it's not Fortran. (Dan Davison)

Linux posts

Troubleshooting posts

This post tagged:





Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode