
The Battle Between Standards: TCP/IP vs. OSI (2003) [pdf] - ggonweb
http://doc.utwente.nl/46343/1/battle_between_-_maathuis.pdf
======
jf
The book "Where Wizards Stay Up Late" by Katie Hafner has a nice overview of
this battle of standards.

Here are some of my favorite quotes from the book:

"the Internet community—people like Cerf and Kahn and Postel, who had spent
years working on TCP/IP—opposed the OSI model from the start. First there were
the technical differences, chief among them that OSI had a more complicated
and compartmentalized design. And it was a design, never tried."

Not only was OSI "never tried":

"On the OSI side stood entrenched bureaucracy, with a strong we-know best
attitude, patronizing and occasionally contemptuous"

“Everything about OSI was described in a very abstract, academic way,” [Vint]
Cerf said. “The language they used was turgid beyond belief. You couldn’t read
an OSI document if your life depended on it.”

Lastly, what I think is a nice and short summary of why TCP/IP "won":

"[the success of TCP/IP] provided an object lesson in technology and how it
advances. “Standards should be discovered, not decreed,” said one computer
scientist in the TCP/IP faction. Seldom has it worked any other way."

~~~
hga
This account is also good, it's fairly technical and _very_ funny:
[http://www.amazon.com/Elements-Networking-Style-
Animadversio...](http://www.amazon.com/Elements-Networking-Style-
Animadversions-Intercomputer/dp/0595088791)

------
Animats
The article misses a big point. The OSI model originally envisioned operating
over X.25 connections operated by telcos. Then came local area networks. Most
network traffic was, for a long time, local; in business settings, it often
still is. TCP/IP worked well both for local and distant networking, and worked
through gateway choke points between LANs and larger networks. X.25 over a LAN
was a huge mismatch; X.25 was intended for slow links.

OSI TP4 eventually could do everything TCP/IP could, and Microsoft included it
in NT (NT4 and Windows 2000, I think), so it did ship. But nobody cared much.

~~~
gaius
The elephant in the corner of the room is that TCP/IP is a _bad_ protocol.
That's why hacking is on the front pages of the newspaper every day now.
Sometimes it is better to let the grown-ups design things.

~~~
shawnhermans
By what stretch of the imagination is TCP/IP a bad protocol? It is a 30+ year
old standard that is still in wide use today. It has managed to scale from a
few networked computers to billions. From an engineering perspective, TCP/IP
is a good protocol.

From a security perspective, most issues with modern computer security have
absolutely nothing with the TCP/IP protocol. If you take a look at top 10
vulnerabilties
([https://www.owasp.org/index.php/Top_10_2013-Table_of_Content...](https://www.owasp.org/index.php/Top_10_2013-Table_of_Contents)),
none of them are directly related to TCP/IP.

It is always easier to look back in hindsight and criticize something knowing
what we know today. Saying we should leave design to "grown-ups" is not a fair
assessment of TCP/IP and its designers. Engineering is difficult and every
design comes with trade-offs.

P.S. If you want to see truly bad protocols, look to ones designed by
"professional", "grown-up", organizations. CORBA and anything WS-* are a few
that come to mind.

------
api
TL;DR: TCP/IP shipped. (Edit: _first_. Some OSI stuff did ship, as another
poster pointed out, but much later and by then it didn't matter.)

I also must point out that the history of spec-ahead-of-time massive
bureaucratic network standards efforts is extremely poor. These efforts tend
to produce things that are complex, over-engineered, unwieldy, hard to deploy,
and generally a mess. In some cases things never progress beyond the
discussion phase, or if they do the result is _far_ less interesting than the
hype. It's basically the bad form of "waterfall" development.

All the most successful network systems I am aware of are developed first and
then specified once the kinks are worked out. Step one is to make it work.
Then you optimize it, clean it up, test it in the field, and _then_ you spec
it so others can interoperate with it. The result is seldom perfect, but it
differs from the byzantine stuff in that it actually exists and people can use
it.

Real but imperfect functionality always trumps non-existent perfection.

Byzantine ahead-of-time network standards bodies are part of this whole branch
of "enterprise" software "development" that as near as I can tell doesn't
actually build anything. I've seen it in action in other spheres too. They
pick a big problem, gather specifications liberally, and then jawbone it to
death. Sometimes small prototypes are produced (at ridiculous cost) that do
tiny subsets of it poorly.

I cannot for the life of me understand why money is actually spent on this
stuff. You would get far better results by taking the millions spent on these
enterprise towers of babel and using it to hose down AngelList and fund
startups doing things that are relevant.

~~~
cmurf
"history of spec-ahead-of-time massive bureaucratic network standards efforts
is extremely poor" Do you think this applies to IPv6? I understand the need,
but it's still difficult to implement IPv6 even for knowledgable people let
alone the 'plug & play' experience of IPv4 with all devices today. But how
could it have been developed first then specified?

~~~
api
IPv6 has a bit of this disease. From what I can tell the core of IPv6 is fine,
but it has too many extensions and many are half baked or over-engineered.
IMHO the core of IPv6 will get adopted and will work just fine and the rest
will get left behind. The most important thing is the extension of the IP
address space to 128 bits, which gives us plenty of room to do all kinds of
interesting _real_ things with addressing.

(Edit: but... if you'd asked me I just would have shoved another 32 bits into
IPv4 via an extension and done it in such a way that routers/gateways that
supported a _simple_ spec could manage that in a backward compatible way.
Probably use a new protocol code + the port field + some extension bits to
allow "IPv4-64" with /32 being the new /16 or /8\. But V6 exists and already
has traction so let's just go with it.)

IPSec and IPv6 mobility were great ideas that are poorly executed. In reality
they should be closely bound -- you _cannot_ securely or reliably implement
endpoint mobility without authentication. But one-bird-one-stone is apparently
some kind of dogma in networking circles. IPv6 is also a f'ing mess from an
implementation standpoint. It's insanely complex to get set up given the
simple thing that it is (or should be), and the language around it seems
designed for maximal confusion ("left" and "right?" WTFOMGWHY? Which left? The
right left or the left left? KILLMENOW.)

A much bigger disaster is WebRTC: [https://www.pkcsecurity.com/blog#webrtc-
flow](https://www.pkcsecurity.com/blog#webrtc-flow)

It's a byzantine mess with tons of acronym-laden moving parts and way too many
things required under the same umbrella... and _no_ all those moving parts are
_not_ necessary. NAT-t and mobile addressing do not require state diagrams
that look like the Paris power grid. As a bonus cherry on top, WebRTC leaves
the signaling mechanism unspecified. Batteries not included.

~~~
MichaelGG
God WebRTC looks like a clusterfuck. Plus the mandatory encryption... only to
punt on the signalling issue. Oops.

Some of this shit is inherited from SIP, which is a mess from the parsing on
up. And people really get... committed ... to the mess they've made, because
it's a "standard".

~~~
api
Microsoft has already announced that they will do their own 'spin' on WebRTC.
Chrome and Mozilla WebRTC are not perfectly compatible in the field from what
I hear. I predict failure.

------
alricb
Famous last words: _A case in point is the lack of space of the Intemet
addressing system that emerged in I994 due to an explosive growth of Internet.
This may now be solved by replacing IP version 4 (Ipv4) by IPv6, which
implementation is underway since about 2000._ (p. 173)

