3 ms·
Look up the OSI standards. They were a horror to implement and use. The telecom companies wanted those to be used instead of the US tcp/ip stack. They would ha
by berntb 10y ago
Look up the OSI standards. They were a horror to implement and use.
The telecom companies wanted those to be used instead of the US tcp/ip stack. They would have had much more control and could have been fat cats, taking a large piece of the slice.
Be damn happy they failed. :-)
A heterogeneous world is an advantage, it gets harder for oligopolies to charge at every gate.
- raattgift 10y agoThere was a substantial overlap between the then Internet Activities Board and the committees associated with ISO/IEC 7498, and it was far from dominated by telecomms companies at the time. Indeed, Lyman Chapin of BBN was in ca. 1992 the chair of both! Other overlappers included Christian Huitema and IIRC Dave Katz. The OSI reference model itself originated with Charles Bachman (Honeywell, then IBM). So far, no telecomms companies to be seen. Telecomms companies and agencies were more interested in EDI in the form of X.400(84) and to some extent X.500 directory services, rather than in the lower layers, and while they were heavily invested in X.25, they were not the biggest pushers for the connection-oriented lower layers -- there were plenty of private X.25 networks operated by government agencies (including many non-PTT ones; bear in mind that the CCITT of the time was national governments represented by their local postal-telegraph-and-telecommunications ministries; the U.S. and Canada were huge outliers in having privately owned commercial telcos). There were also research & education networks with X.25 underneath, including CSNET (largely based in the USA) which was definitely part of the TCP/IP-speaking Internet. OSI's problems weren't in the people involved or in the (admittedly heavy) formalisms that go into ISO/IEC/CCITT/ITU standards, but rather that the idea was to redo TCP/IP "right", and that included supporting difficult to reconcile goals, like supporting both connection-less and connection-oriented protocols in most of the lowest of the 7 layers, and then mechanisms to provide interoperability between CO-only and CL-only talkers. At the time, well before FPGAs and ASICs were accelerating routers, and when megabytes of RAM were expensive (and slow), OSI appeared too heavyweight compared to TCP/IP, and that is one of many reasons TCP/IP won. OSI reference implementations were expensive rather than free as in beer (sort-of); compiling up your OSI elements took considerably longer; an OSI-equipped kernel was fat (too fat if it was only really talking ES-IS and nothing else); and so forth. SMTP/TCP/IP was what members of the OSI subcommittees were using to communicate with one another, in spite of the existence of EAN for X.400 and some native OSI CLNP (AlterNet, UUNET's internetwork, in the very early 1990s carried real CLNP traffic between RAND and several other organizations). Internet protocols did benefit from the OSI development work; good ideas from IDRP found their way into BGP4; IS-IS is still the IGP of choice for some large IP networks; LDAP, SNMP and others absorbed good ideas from X.500 and EFTAM; and of course DSL and OTN systems have a lot of OSI in their DNA. Finally, the U.S. government's GOSIP and similar programmes for mandatory adoption of OSI networking elsewhere probably doomed OSI networking much more than politics (and personality conflicts) among people involved in actually making the standards in the various bodies, both international (and national) and in the IETF and its close relatives. Taking profile "short cuts" to roll out OSI networking rapidly in that way raised the real possibility of fully conforming OSI networks (and stacks) that would nevertheless be mutually incompatible! Unfortunately many of the lessons learned in the failure of OSI networking were not applied in the process of choosing and standardizing a successor protocol for IP, and here we are a couple decades later with IPv6 being a compromise specification designed for speed of roll out... (In fact some of the wrong lessons learned in the very early 1990s of OSI networking are in IPv6 today: the expectation that being CPU constrained, routers must deal with relatively short, fixed-length, fixed-format fields (rather than, say, something self-describing) is front-and-centre in IPv6 addressing and headers generally. Concerns about overheads are also well-reflected in IPv6, and for terrestrial applications, those concerns were obsoleted by the turn of the century.) "A hetereogeneous world is an advantage". Well, try explaining that on the IETF mailing list as a reason to support concurrent development of a successor protocol to IPv6.
- berntb 10y agoExhaustive, informative and insightful. Please don't write that stuff were people won't see it. :-) (I'd add that X.25 was moved into the OSI standards, btw. But you certainly know that.) But you agree with my point that you couldn't really implement all those protocols in a serious manner, at least not at the time. You saw specifications of buffer counters that were "infinite". OK, that is possible to implement -- and today maybe even efficiently. Also, the ones pushing this were states and big corporations, typically telecom. The exact details motivations you seem to know more about, but you don't really touch it? The academic world felt pressure to conform and go OSI instead. (I would argue that with IoT, protocol/processing overheads might again become an issue on Earth and outside of instruments in the oceans?)
- raattgift 10y agoWeirdly there was shortly after this, and totally coincidentally (since as you may suspect, nobody involved has seen my previous comment) a number of old grey beard networkers were having a discussion about what happened to OSI on a social media platform, and two observations stood out. Firstly, before Marshall Rose et al.'s ISODE there was no free-as-in-beer OSI networking implementation for any platform. Typically OSI networking was available at extra (and high) cost, and the official standards documents were both expensive and tightly access-controlled. Secondly, ISODE itself took a very long time to download and build even on the fastest platforms of the time. By comparison, UNIX systems were already talking TCP/IP out of the box (not quite "free", after all this was before the BSDI lawsuit) and RFCs were readily available and distributable, so free in most senses. Telecomms companies were at the time largely state-owned agencies; deregulation and privatization were only happening in the UK and Sweden, and only by accidents of history did the USA and Canada have private for-profit companies doing telecomms business (and even in parts of Canada there was partial government ownership). Most of Europe still had monopoly incumbent carriers, state owned, and often directly part of (or even the whole of) the postal & telecommunications ministry. While some management may have been profit-minded, most of them were geared towards resisting competition, even mutual competition, until DG4 (now the Directorate-General for Competition) effectively forced open cross-border markets within Europe in the name of the single market in 1996-1997. Internal competition took longer in most member-states, and rules on state subsidy forced most of the PTTs to spin off their telecommunications (and postal) operations (one could hardly call them businesses in many cases) into separate entities with outside shareholders. That's when greed set in. :-) Before that it was merely monopoly pricing, terrible cost control, and long term views on investing in new technologies (do it slowly, because the old equipment has not yet been fully depreciated!). By way of counter-example, at least one large U.S. telecomms company was actively supportive of TCP/IP, hosting an early IETF, and so forth, while still participating in OSI and other non-TCP-related networking standards bodies, including the ITU/IEC/ISO (however it is formally the U.S. State Department which attends the meetings; operators are invited to sit with and brief the full-time civil servants; this model is how ITU-T continues to operate, even though there is now no European or North American telecomms company with significant state ownership). Moreover, the member-states of the international bodies were not really pushing OSI, they were facilitating it. Again, full-time government officials would be the formal attendees, but they would bring along academics and researchers from public and private institutions. The OSI networking process was deliberately a "smushed" together cooperation among several standards bodies, so that rather than say ANSI and its non-USA counterparts attending an ISO meeting, "the network nerds" could actually all meet together as peers and carry on work informally via (funnily enough) email mainly transported by SMTP. Certainly some of "the network nerds" were working with large technology firms with vested interests in particular technologies -- IBM comes instantly to mind -- but they were a diverse bunch, much as in the IETF became (ignoring issues of number of IETF meeting attendees, which became large). Fronting for one's company happens, and the ISO/IEC processes were initially designed to avoid that. Indeed, there remains tension in the IETF about whether participants are supposed to be individuals or acting directly in the interests of their employers. I agree with you that there were some crazy ideas in the OSI networking protocol suite, and there are good reasons to pick on CLNP as a networking layer in particular. However, I think that had the standards been freely available and redistributable like RFCs, and there was wider involvement early in the drafting process, both the Internet suite of protcols and OSI's would have improved, and likely converged substantially. Likewise, the ability to tinker with OSI networking even on hefty workstations or minicomputers arrived much later than things like Phil Karn's KA9Q NOS for personal computers(for example). There was effort to try to make a lighter-weight ISODE, and it made some progress [0] but it was very late to the party, and was not obviously better than TCP/IP, so it was no more likely to be rapidly adopted (except by serious enthusiasts) than IPv6 was for its first dozen years... The international standards bodies vs IETF-and-relatives story became very different a few years later, although not about OSI networking as such, but rather about how to do "broadband ISDN", with the general idea being that a stack of protocols built for ATM (which still sees wide use and utility in the last mile in DSL) should replace IP. ATM standardization was a mess with differing interests, and yes there was tension between the PTTs, computer networking academia, the radio & other wireless broadcast sectors, and so forth, and there are many compromises baked into the ATM standard suite at various layers. Moreover, there was telecomm-vs-telecomm conflict, and conflict among various equipment vendors. Additionally, ITU-T began its long civil war among fully commercialized telecomms agencies (with strong lobbyists convincing their governments of their rightness) versus government monopolies, particularly in the developing world. The latter didn't particularly dislike TCP/IP, they simply wanted to avoid losing the phone call termination fee scheme that in many countries were a noticeable portion of overall foreign earned income. The processing overheads in networking today, for end systems, is almost wholly encryption and decryption in terms of energy and latency. It is likely that specialized low-energy implementations will arrive before anyone can define what "IoT" means at least as well as the UK Prime Minister defines Brexit. :-) Meanwhile, low-power systems can adopt strategies like talking more slowly or using slower but lower-power-consuming implementations of algorithms; TCP will properly throttle if a "Thing" is much slower than its counterparties (that's part of what TCP is for!). Even terrestrially there are remote end systems which are stuck talking mere hundreds of bits per second, and the Internet suite of protocols mostly scales down to those speeds (in part since many of the protocols started near there). Consider that in 1993 the IETF rejected the use of a simple CRC in the IPv6 header on the grounds of processing cost and byte overhead, and that in 1991 people preferred SLIP to PPP because of the latter's overheads. I don't think they could honestly have been expected to imagine AES-NI or lz4 or the like managing hundreds of megabytes per second throughputs on personal computer grade equipment, but even at the time such "savings" decisions seemed shortsighted ...