top | item 6121732

OSI: The Internet That Wasn’t

110 points| florent_k | 12 years ago |spectrum.ieee.org | reply

62 comments

order
[+] npsimons|12 years ago|reply
As usual, /usr/games/fortune provides some insightful commentary:

"On the other hand, the TCP camp also has a phrase for OSI people. There are lots of phrases. My favorite is `nitwit' -- and the rationale is the Internet philosophy has always been you have extremely bright, non-partisan researchers look at a topic, do world-class research, do several competing implementations, have a bake-off, determine what works best, write it down and make that the standard.

The OSI view is entirely opposite. You take written contributions from a much larger community, you put the contributions in a room of committee people with, quite honestly, vast political differences and all with their own political axes to grind, and four years later you get something out, usually without it ever having been implemented once.

So the Internet perspective is implement it, make it work well, then write it down, whereas the OSI perspective is to agree on it, write it down, circulate it a lot and now we'll see if anyone can implement it after it's an international standard and every vendor in the world is committed to it. One of those processes is backwards, and I don't think it takes a Lucasian professor of physics at Oxford to figure out which."

-- Marshall Rose, "The Pied Piper of OSI"

[+] nknighthb|12 years ago|reply
This is why every time Mozilla starts whining about Google playing with new things without consulting everybody else first (e.g. Dart, NaCl), I lose more respect for them (actually, at this point, they've pretty well exhausted it all). Basic advancement comes from somebody deciding to try something new, not from getting everybody to agree on what comes next.
[+] jamessb|12 years ago|reply
Lucasian professor of physics at Oxford

Lucasian Professor of Mathematics at Cambridge, surely?

[+] blue1|12 years ago|reply
Doesn't this description of the OSI way look similar to how the W3C works?
[+] npsimons|12 years ago|reply
To sum up my reply to replies to my OP: the biggest thing I take away from this quote, personally, is that you should have a good, practical knowledge of something before you go about making a standard, and input from the real world is also a very good idea. Some upfront design is necessary, yes, but when politics dominates technical concerns, failure is bound to follow.
[+] rodgerd|12 years ago|reply
Because, of course, TCP/IP doesn't have any bloody stupid, boneheaded decisions that it continues to perpetuate through multiple revisions (hey, isn't it great we have to read a whole header to work out the address information!)
[+] ChuckMcM|12 years ago|reply
I think one of the subtleties that is overlooked is that by being the "future" of networking, OSI drew in all the "big guns" who worked hard to control it to their advantage. Whether it was the folks at IBM who were pushing Token Ring/SNA, or Netware, or anything really. Since it was the standard to be, influencing it was the high priority.

That allowed the IETF to continue in relative calm and without serious interference during the 80's. That all changed in the 90's when people started figuring out they were betting on the wrong horse.

In 1993 at the 27th IETF [1] I put forth the proposal that this code we had all been using (RPC/XDR) that was described in various informational RFCs (RFC1057/RFC1014) which everyone treated like a 'standard' actually be blessed as a standard. Pretty much the consensus was that it was a fine idea except that forces at that point that were rather anti "Sun" went out of their way to kill it. It was sad to watch, and folks who had been going to IETF meetings for a decade or more were appalled but damned if it had become impossible for the IETF to bless something as a standard any more. That really soured me on 'standards' for a long time.

[1] Pg: 533 Advances in ONC http://www.ietf.org/proceedings/27.pdf

[+] rogerbinns|12 years ago|reply
There were also some differences in design tastes. For example OSI went with ASN.1[1] for binary descriptions rather than plain and simple. TCP and IP just use 8/16/32 bit fields in a predefined byte ordering and that is it. That makes TCP/IP considerably easier to eyeball.

In higher level protocols like email, the TCP/IP world tended towards ASCII based protocols which are far more flexible and future proof, while OSI again did ASN.1. I once worked on an X.400 (OSI Email) gateway and was highly amused that they defined a different error code for every possible reason an email could be refused. There were pages of them (including recipient is dead!) while SMTP allowed for arbitrary text and an overal numeric code to indicate the type of error. Again you can see which was easier to eyeball and diagnose.

Practicality tends to be very effective.

[1] http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

[+] nucleardog|12 years ago|reply
I've implemented ASN.1 BER from scratch before (don't ask). If "three different string formats" doesn't say designed by committee, I don't know what does.

Sounds like OSI would have been an internet built on what is essentially binary-encoded XML. I'd say we dodged a bullet.

[+] tlb|12 years ago|reply
The danger of committees is that it's easy for a few members to add tremendous complexity. Why would anyone do that? Isn't "easy to understand and simple to implement" always a goal of everyone working on tech standards?

Not if you're a big company competing with small companies. Adding 10 man-years of implementation effort is a small thing for IBM- or Cisco-sized companies, but a giant barrier to entry for upstart competitors. Also, vagueness in the spec requires extensive testing to make things interoperate reliably, which favors big incumbents.

These aren't just emergent, subconscious effects. I've been in on discussions about making a spec harder to implement to frustrate competitors. (not with any YC companies)

The dark forces of competitive advantage affect non-committee specs too. Microsoft SMB is an example. The x86 instruction set is another.

[+] dlitz|12 years ago|reply
> Why would anyone do that? Isn't "easy to understand and simple to implement" always a goal of everyone working on tech standards?

Patents and "competitive advantage".

[+] mcguire|12 years ago|reply
"Everything was up for debate—even trivial nuances of language, like the difference between 'you will comply' and 'you should comply,' triggered complaints."

That's not actually a trivial nuance---those are significantly different semantic behaviors. IETF RFC's use "MUST" and "SHOULD" (yes, in caps) for the same distinction.

[+] bandy|12 years ago|reply
…but we're going to keep asking questions about the 7 layer model in interviews as if it were useful in the real world because that's what we learned about in school.
[+] kabdib|12 years ago|reply
"I hear they're going to 42 layers because it's a sacred number in Bali."

Not from this guy. I might ask you to critique the 7 layer model, or provide me with ideas for speeding things up by skipping layers.

It's all mushed together in real stacks anyway, with dogs down in the cat layer, and mice doing double duty both at the metal and up there in the UI. I swear to god, OSI would have been standardizing finger lengths for keyboard interaction if someone had let them.

[+] shirro|12 years ago|reply
Came here looking for 7 layer model. It seems to be the only surviving legacy of OSI. From memory Computer Networks by Tanenbaum mapped every protocol into that damn model. Typical of committees to have 3 more layers than needed.
[+] rmrfrmrf|12 years ago|reply
Obviously the best job candidates are the ones that scoff at the prospect of learning something more than is absolutely necessary.
[+] tytso|12 years ago|reply
I remember reading with great amusement an article written by an X.400 proponent, sometime in the late 80's, asserting that X.400 would start to dominate SMTP once the telecoms got the price of sending an X.400 message under a dollar per e-mail. (And this was back in the 80's, when dollars were bigger back then!)

Thus proving that the OSI folks really didn't have a clue....

[+] r4pha|12 years ago|reply
I had always looked to the OSI model as a _frame_ thought which a communition channel can be analysed. If I intercept my internet cable, I assume I can idealy measure the signal and fit it on the 7 layers of the OSI model. I fail (honestly) to see how that is a failure, as seems to be the starting point. Isn't the OSI model _one_ way to look at a medium?
[+] jerf|12 years ago|reply
That was not the original intention. That is the story that for some reason network professors continue to tell themselves as a reason to teach this model. The original intent was for there to be 7 clear layers, with various protocols for each.

Why the profs stick so close to this instead of teaching a more realistic model is beyond me. Why use an inaccurate theoretical model when you could use an accurate one instead? It's going to be simplified relative to reality either way, as befits a model, but it might as well be a correct simplification. I mean, it's not like the OSI 7-layer model is a mathematical truth or anything... it's just an artifact produced by a committee a long time ago.

To anyone leaping up to defend it, let me set the frame I'll be judging the defenses by in advance: If the real world was as it is today except there was no such thing as the OSI model, and someone proposed the 7-layer model today as a model for understanding the network for the very first time, would you really consider your defense as a reason to go with it, even despite the fact the model is actively inaccurate? I don't think inertia is an adequate defense to stick with something, when we aren't even using it anyhow... what real inertia does it have?

[+] walshemj|12 years ago|reply
Interesting and we can see the outcome of the palace revolt is IPv6 OSI /telecoms guys would have insisted on having a workable inter-operation plan.

EX X.400 hacker here I used to have root on the UK ADMD back in the day :-)

[+] hga|12 years ago|reply
Not too impressed with this account, which I will admit starting to skim around halfway. E.g.:

I'm not sure the author realizes TCP is a virtual circuit protocol (then again I'm sure OSI had one or more much heavier weight ones).

The real fatal flaw of OSI, before even getting to the point of finding out if their protocols worked---many of them did get far enough in standardization process---was their going to ISO in the first place. If you just needed to get things done, the difference between spending around $2,000 ($1,000 in 1988 dollars) to buy a shelf of the standards documents, or $0 or thereabouts to get all the RFCs (chicken and egg, you might need to buy a CD or a tape to get them to your systems), made a very big difference.

If you're really interested in all this, I highly recommend Padlipsky's very opinionated "The Elements of Networking Style: And Other Essays & Animadversions on the Art of Intercomputer Networking" (http://www.amazon.com/Elements-Networking-Style-Animadversio...), a very colorful work with rhetorical gems like "gilding the ragweed".

[+] mjn|12 years ago|reply
> spending around $2,000 ($1,000 in 1988 dollars) to buy a shelf of the standards documents

The ISLISP standardization group did an interesting workaround for this: http://www.islisp.info/history.html

An ISO committee to standardize the language was constituted but stalled on doing any real work drafting a standard. While they waited around, the community drew up a draft standard, which was published as a public recommendation to the ISO committee, with the draft put into the public domain. The committee then voted to adopt the community's draft as the standard unchanged. So now an official ISO document is available for the usual fee, but you can get a predecessor document that looks surprisingly similar, for free as a PDF.

Of course, this requires everyone on the committee agreeing to not really take the ISO process seriously. You might wonder why one would bother with it at all then, and in this case it seems to have been to reassure clients that ISLISP is stable by getting it an ISO standard.

[+] shenberg|12 years ago|reply
TCP really isn't a virtual circuit protocol in the same sense that X.25 PLP is a virtual circuit protocol: In VC protocols you say something like "network, I want to talk to address X," establish a channel (getting a channel ID allocated) and from then on send packets to the channel (not mentioning the remote address again), knowing that they'll arrive there. This means the routers on the way are stateful. TCP theoretically doesn't care about routing, and IP is stateless.
[+] mturmon|12 years ago|reply
"not sure the author realizes TCP is a virtual circuit protocol"

That struck me too -- kind of undermining the simple narrative of "connection-full telecom biggies vs. connection-less insurgents". It would have been worth a note in the article, because it's in IEEE Spectrum after all.

Not a networking pro, but I believe the converse is also true, that OSI has specifically connection-less protocol elements (e.g., CLNS) that are at a lower level in its own hierarchy, and more equivalent to IP in TCP/IP.

I just saw part of an interview with Cerf (http://www.internet-history.info/media-library/mediaitem/100...), in which he said that part of the motivation for packet switching is to maintain command and control in the chaos of a post-nuclear-strike world. That explains why the person connected with packet switching (Paul Baran) was at RAND, which was not a networking place, but very much a "let's plan for the apocalypse" place.

[+] alan|12 years ago|reply
> I'm not sure the author realizes TCP is a virtual circuit protocol (then again I'm sure OSI had one or more much heavier weight ones).

You've missed that they're referring to level 2 and 3 virtual circuits, IE "data is always delivered along the same network path, i.e. through the same nodes" ( https://en.wikipedia.org/wiki/Virtual_circuits#Layer_2.2F3_v... )

[+] mcguire|12 years ago|reply
I was hoping someone (else) would mention Padlipsky.

In my dissertation, Elements of Networking Style is the reference for the OSI section (which was needed because everybody is still using the damn terminology).