
OSI: The Internet That Wasn’t (2013) - ghshephard
http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt
======
hga
Eh. The fact that you had to spend around $1,000 to buy the set of manuals
required, back when that was perhaps $2,000 in today's dollars, was probably a
bigger factor than the article makes it out to be. Standards organizations
like ISO and ANSI, at least back then, made their money selling manuals, which
just doesn't work for something so ubiquitous in the number of people who have
to know details.

Another problem that I read about at the time is that some of the ISO
protocols _didn 't work_. The "ISORMites" ([http://www.amazon.com/Elements-
Networking-Style-Animadversio...](http://www.amazon.com/Elements-Networking-
Style-Animadversions-Intercomputer/dp/0595088791)) were reported to be
contemptuous of the Internet protocols, their origin from the "US Department
of Death", etc. ... and didn't have a policy like the IETF's "running code
wins" approach.

More generally, per
[http://www.ietf.org/tao.html](http://www.ietf.org/tao.html) " _One of the
'founding beliefs' is embodied in an early quote about the IETF from David
Clark: 'We reject kings, presidents and voting. We believe in rough consensus
and running code'_"

------
Animats
OSI's answer to TCP, TP4, was implemented in Windows 2000.

TP4 assumed a reasonably reliable data path, probably an X.25 virtual circuit,
underneath. It didn't have all the timing, reordering, retransmit, and
congestion control machinery that lets TCP work over bad links.

On the other hand, the OSI crowd had, at the time, more experience with
scaling and routing. IP's class A, B and C networks, autonomous system
numbers, and Border Gateway Protocol didn't scale well. Routing in the
Internet is still something of a hack. Today's routers almost have to have an
in-memory table mapping all 4 billion IPv4 addresses to Autonomous System
Numbers. If memory wasn't so cheap, we'd be having real problems.

~~~
noselasd
TP4, where the 4 stands for class 4, certainly had reordering, retransmission
and congestion controll.

Other classes you could chose had varying degree of error detection and
recovery. It also had a connectionless mode.

~~~
Animats
"You could choose". Therein lies the problem. TCP is automatic, which is a big
win. You don't have to set parameters for TCP depending on the data path.

~~~
noselasd
Why is that a problem ?

You specify a parameter when you start, telling which variant to use. It's
really not that different sitting down before you start coding a program and
deciding whether to use TCP, UDP, DCCP or similar.

~~~
Animats
Because you don't know whether the end user running the program has a gigabit
server-quality pipe or a flaky mobile connection.

~~~
noselasd
Sure, but how is that different from the TCP/IP world ? You select the
protocol based on what your application needs.

------
coderjames
We're actually integrating an OSI-based network stack into our avionics
datalink product at work right now.

The next generation of digital air traffic control between aircraft and the
ground towers is an OSI stack. Proprietary application in layer 7 and
avionics-specific layers 2 and 1, but everything in between is bog-standard
OSI (TP4 & IDRP, IS-IS & CLNP, 8208).

Interesting protocol suite, and it will be keeping aircraft going the right
direction for the next 25+ years.

~~~
ghshephard
Hilarious - a bit further down I mentioned how Hughes Canada Systems division
had a team hard at work on that project in 1994/1995\. I thought it had been
scrapped - apparently not.

------
aidenn0
Ah, reading about some of the early packet-switch debates reminds me of the
time my dad called me up and said "I crossed off one of my bucket list items:
Vint Cerf called me a 'circuit-switched bigot'"

------
ghshephard
I was working at Hughes Canada Systems Division in 1994/1995, and they had an
_entire division_ dedicated to developing a next generation Air Traffic
Control system - it had been mandated about 4-5 years earlier, that this
project _had_ to be written using OSI protocol stack. They had been struggling
for about 4 years, and still hadn't managed to get the protocol stack on their
operating systems interoperating properly. There were dozens of people working
on this project too. Total Fiasco. They ended up scrapping most of their work.

~~~
walshemj
Interesting when I worked for BT I worked on OSI interconnects for the UK its
not that hard once you grok asn.1 to workout what is going on.

My boss once watched a trace I was running stoped it and pointed to a
particular dword and said that's a Sprint ADMD you can tell as they don't to
that part of the had shake properly

------
ivancamilov
"OSI has been forgotten by all but a handful of veterans of the Internet-OSI
standards wars."

Hardly forgotten, I learned about OSI at the same time I studied TCP/IP back
in college. And I'm hardly a veteran, since I graduated in '09.

~~~
ghshephard
OSI model, or OSI protocols? Everyone knows the OSI model - but outside of
Avionics, you won't find that many people who know the protocol details beyond
knowing they exist. And that TP4 is a thing.

~~~
walshemj
You can tell people who relay know OSI by asking them which level MIDI is and
critique CISCO'S asertation that its a layer 5

------
graycat
I remember working with that ISO, OSI, C-MIP/C-MIS, ASN.1, *registration
hierarchy, etc. stuff. Worst interval in my career.

Finally I began to understand: The standards meetings were in Paris, Rome,
London, Munich, ...!

~~~
walshemj
The OSI was working to the one PTT per country model your government
controlled/owned phone company.

------
jauer
Oddly enough some OSI protocols live on at the foundation of IP networks in
the form of CLNS & IS-IS.

IS-IS is a internal routing protocol sometimes used instead of OSPF.

~~~
jws
ASN.1 managed to infest some internet protocols like SNMP and SSL
certificates. It's one of those solutions to a problem that shows its
committee heritage and ends up being ludicrously complicated to implement
because of all the edge cases. Lots of software has been compromised through
flawed ASN.1 and X.509 decoders.

I'm old enough to remember back in the day when our customer (the biggest
possible customer) allowed us to implement early versions using SMTP, but we
had to design and plan to switch to X.400 since that was going to be the real
standard. It was a strange era. We had things that worked, but everyone knew
that the whole industry was going to switch to something completely different
that solved all the same problems for a reason no one in the trenches really
understood. Except the dates for switching kept moving and the software for
the new way never really quite arrived in working order or with enough
features to move.

~~~
ghshephard
LDAP as well. Tim Howes once told me if he had to do it all over again, he
would have not used ASN.1, would have done a simple text protocol.

------
StephenFalken
There is a quite interesting book where the author (John Day) shares an inside
view about the OSI committees back in the 70's and 80's, and its endless
discussions: "Patterns in Network Architecture: A Return to Fundamentals" [1]

[1] [http://www.amazon.com/Patterns-Network-Architecture-
Fundamen...](http://www.amazon.com/Patterns-Network-Architecture-Fundamentals-
paperback/dp/0137063385)

------
tankenmate
One advantage that circuit routing has over stateless routing is that of
largely painless muxing / demuxing; and hence almost no buffer bloat. SONET
can mux multiple channels without the need for a single buffer. Obviously the
downside is the lack of flexibility, interdependency and hence increased
fragility.

------
jclish
The 7 layer model lives on. It remains a good reference point for discussing
networking.

~~~
kabdib
Seven layers are a procrustean bed, at best. The model might be useful as a
starting point, but really all it means is "good design uses layers." When you
start discussing actual networking implementations, trying to fit a what
you're doing into "where exactly this fits in the ISO model, and it's wrong if
it doesn't fit" is a bad way to think.

Devices that mix layers can do pretty interesting work, too (e.g., inspection
of packets for security purposes, smart buffering for controlling host load,
etc.). So the "every layer only talks to the layers immediately above and
below" is kind of suspect, at least as dogma. There are probably other
examples in very high bandwidth systems where you want to skip layers for
performance reasons.

