An OSI model for the 21st century (2014) | Hacker News Reader

An OSI model for the 21st century (2014)

davidad.github.io

90 pointseaguyhn27 comments

I have read the various comments against the OSI model and the one interesting observation is that none of you seem to have ever worked with a compliant implementation of the OSI model. Honeywell had a commercial product called DSA (Distributed Systems Architecture). We did write distributed applications that used the OSI protocol stack communications and it worked well. Within the applications, we didn't have to worry much about what was happening at the lower levels as those levels simply provided specific services we used. It was used for many years with very good results.

One of the features of the software at the time was that you get two dumb terminals to communicate with each other across the network by simply using the relevant connection protocols. This allowed simple communication streams to occur without having any applications involved, it was handled by the protocols themselves. It also meant that it was very easy to replace those dub terminals with an application without having to change any of the configurations in the network.

TCP/IP rose to the fore due to various reasons that were not related to their technological superiority. To see this you have to look more closely to the history of those times.

For my job I had the opportunity to work with quite some OSI standards on top of TCP/IP (X.216, X.227 and X.500, X.400 as application layers). My experience is quite in line with the common critique: most of these standards add more overhead than they're worth. It was also quite hard to bend these protocols into our use case (when bandwidth comes at a premium, it doesn't take long before the customer starts complaining).

I don't really see how a "dumb terminal" is a noteworthy feature of OSI? That's essentially what telnet does, and it too can just piggyback on top of TCP (probably the only protocol that makes use of all TCP flags available).

What commercial software were you using? TCP/IP was not part of the protocol stack we were using. The dumb terminal was sitting at the top of the protocol stack and wasn't using an application like telnet to access remote devices or applications. The point of my example was simply that a dumb terminal or any device or an application were treated the same in relation to the protocol stack. It did not matter.

The top speed of our links was the enormous 64 kb/s and we often had to use far slower services. We found that the overheads of the communication protocols was very small compared to the application processing overheads. It was a different time, I suppose and I find that I have to wait longer these days even when using ADSL than I did in those days.

AFAIK, the general perception is that http is a transport & upper protocol. Not an application layer protocol.

Anyway, OSI model is mostly a mental picture that bear little practical relevance.

If someone want to follow OSI model and devise a new model, then itself is a wrong approach. TCP/IP was invented out of solving real internetworking problems, without regarding much to the OSI model or any pre-defined model per-se.

As always, David Clark's "e2e principle" (https://en.wikipedia.org/wiki/End-to-end_principle) probably is the only guiding principle (or a after-fact summary) that is worth following.

Well, there are themes that are evolving that are worth cataloging in a new logical model that can help guide further innovation. I agree though, the model itself isn't the root.

The end to end principle pretty much made the flow control and re-transmission functions of the LLC sublayer of the data link layer obsolete. So now we pay a 6 to 8 byte penalty (8 bytes if the MAC can tell us the packet length) on every frame transmitted. Wired/optical Ethernet does not normally use LPD (LLC Protocol Discrimination, i.e. 802.2 LLC/SNAP) but unfortunately WiFi does.

So in 2014 while the author is advocating for the data link layer to ensure packets are received by other devices on the channel like the current OSI model does, the IEEE is encouraging new standards to use EPD (Ethernet Protocol Discrimination) instead of LPD. The IEEE just wants the LLC sublayer to only do multiplexing of protocols now.

The author completely missed how the upper layer protocols, i.e. TCP/IP, has made some parts of the lower layer protocols unnecessary. Having a basic model is good thing for classifying different parts of the network and makes discussions clearer. But in the real world things rarely fall into categories that neatly.

Please add (2014) to the title.

For sure! MacSec has gained in popularity lately, and a lot of the issues the author raises have been solved by other efforts.

its hiding in the discourse, but I think author would be better off completely abandoning the notion of a canonical stack and provide a categorization of functions - routing, identity, reliability, etc

Well it turns out that security is getting set up in other layers but these are for more specialized applications than general run of the mill internet usage. For example there is encryption available at the physical layer even at very high data rates. Additionally there is MacSec which is a layer 2 technology. It's curious that the author mentions neither.

John Day maintains that OSI was never fully implemented. Cf. "Recursive InterNetwork Architecture" https://en.wikipedia.org/wiki/Recursive_InterNetwork_Archite...

Reply on news.ycombinator.com