
An OSI model for the 21st century (2014) - eaguyhn
http://davidad.github.io/blog/2014/04/24/an-osi-layer-model-for-the-21st-century/
======
oldandtired
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.

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

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

------
justicezyx
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](https://en.wikipedia.org/wiki/End-to-end_principle))
probably is the only guiding principle (or a after-fact summary) that is worth
following.

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

------
tjalfi
Please add (2014) to the title.

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

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

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

------
carapace
John Day maintains that OSI was never fully implemented. Cf. "Recursive
InterNetwork Architecture"
[https://en.wikipedia.org/wiki/Recursive_InterNetwork_Archite...](https://en.wikipedia.org/wiki/Recursive_InterNetwork_Architecture_\(RINA\))

