A aposta que quase todo mundo perdeu

Todo diagrama de rede em camadas que um aluno vê em sala começa com sete camadas, mas quase todas as redes do mundo funcionam com quatro. Essa diferença é herança de uma disputa de vinte anos em que o lado derrotado tinha, no papel, todas as vantagens.

Em meados dos anos 1980, o Open Systems Interconnection (OSI) tinha o apoio da International Organization for Standardization (ISO) e dos órgãos internacionais de telecomunicações; dos monopólios de correio, telégrafo e telefonia, que na época eram donos da maior parte dos fios do mundo; da IBM, da Digital Equipment Corporation, da Honeywell e das concorrentes delas; dos governos da França, da Alemanha Ocidental, do Reino Unido e da Comunidade Econômica Europeia; do Departamento de Comércio dos Estados Unidos; e do Departamento de Defesa americano, que planejava trocar o (Transmission Control Protocol / Internet Protocol) pelo OSI. Milhares de engenheiros trabalhavam no projeto, e a adoção do OSI no mundo inteiro parecia inevitável.

Do outro lado estava uma suíte de protocolos escrita em boa parte por alunos de pós-graduação, especificada em documentos chamados Requests for Comments (pedidos de comentários), financiada por uma agência de pesquisa e distribuída junto com o código-fonte.

O que existia antes dos dois

A disputa não começou como OSI contra internet. Nos anos 1970, várias soluções conviviam ao mesmo tempo. A IBM lançou a Systems Network Architecture () em 1974, e a Digital lançou a . As duas eram excelentes, e cada uma só conectava equipamentos do próprio fabricante, o que, do ponto de vista do fabricante, era uma vantagem. As companhias telefônicas, num trabalho conjunto internacional, criaram o em 1976 e montaram sobre ele redes públicas de dados com cobertura realmente global. A premissa era que a comunicação de dados seria um serviço de operadora, como a telefonia, cobrado por minuto e por pacote.

O OSI foi a reação a tudo isso: uma tentativa de criar uma arquitetura única, completa, neutra em relação aos fabricantes e aprovada internacionalmente, para que o equipamento de qualquer fabricante conversasse com o de qualquer outro. A motivação era correta, o modelo era bem pensado, e a arquitetura de referência em sete camadas continua sendo o vocabulário que a indústria ensina. É a estranha sobrevida que o artigo sobre o modelo OSI descreve: o mapa sobreviveu ao território para o qual foi desenhado.

A obrigatoriedade do OSI

Os governos não se limitaram a preferir o OSI. Eles o tornaram obrigatório.

A Central Computer and Telecommunications Agency, do Reino Unido, publicou em 1988 um perfil OSI para o governo, o Government OSI Profile (), e começou a trabalhar com a França e a Alemanha Ocidental num manual europeu comum de compras públicas. Os Estados Unidos publicaram o seu como um Federal Information Processing Standard: a 146, de agosto de 1988, reeditada como 146-1 em abril de 1991. Com ela, as agências federais que comprassem equipamento de rede eram obrigadas a comprar OSI. Em 1988, o Departamento de Defesa adotou os protocolos OSI de correio eletrônico e de transferência de arquivos como padrões em pé de igualdade com os seus e os classificou como experimentais "because of the limited operational experience currently available with the OSI protocols".

Esse trecho final resume a história inteira numa oração subordinada. A obrigação existia; a experiência operacional, não.

O que aconteceu depois está registrado nos próprios arquivos da internet, e vale a pena citar pelo tom seco. A 1169 foi publicada para explicar o papel do GOSIP, e a explicação, como resumiu um participante numa lista de discussão pública, era esta: o GOSIP obrigava os compradores do governo a comprar OSI, mas não os obrigava a usar o OSI como meio de comunicação principal, nem como meio único. As agências compravam equipamento compatível com o OSI para cumprir a regra e rodavam TCP/IP em cima dele para conseguir trabalhar. As exceções eram concedidas sem dificuldade, com o argumento de que as implementações OSI de fabricantes diferentes não conseguiam interoperar de forma confiável, justamente a única coisa que o OSI existia para garantir.

Em 1994, a exigência americana já tinha sido flexibilizada para permitir abertamente os protocolos da internet, e o perfil foi retirado.

Por que a especificação melhor perdeu

São quatro motivos, e nenhum deles é o OSI ter sido mal projetado.

Foi especificado antes de ser implementado. Os documentos do OSI saíam de comitês que buscavam acordo entre delegações nacionais e só depois iam para os fabricantes implementarem. O TCP/IP foi implementado primeiro e documentado depois, e uma especificação que descreve código que já funciona não tem como conter um requisito que depois se revele impossível. É o rough consensus and running code da IETF, o consenso aproximado com código rodando, visto aqui como vantagem competitiva e não como slogan.

Os documentos custavam dinheiro; o código, não. As normas da ISO eram vendidas. As RFCs eram gratuitas para ler e para implementar, e no começo dos anos 1980 uma pilha TCP/IP funcional vinha na distribuição de Berkeley, que as universidades já usavam. Uma geração de engenheiros aprendeu redes com o que era de graça, porque era o que estava à mão.

A abertura do OSI estava no processo, não na prática. A tese do historiador Andrew Russell, que virou a leitura padrão do episódio, é que a tentativa da ISO de usar mecanismos democráticos formais de padronização internacional pode ter sido a ruína do OSI. O consenso entre comitês nacionais é lento, e os delegados que chegavam a esses comitês representavam quem já dominava o mercado: operadoras e fabricantes de mainframe. A eles interessava um projeto em que a rede fosse inteligente, administrada de forma centralizada e tarifada. A internet foi projetada ao contrário: pôs a inteligência nas pontas e partiu do princípio de que a rede era burra, o que agradava menos a quem financiava o OSI e mais a quem desenvolvia aplicações.

Respondia à pergunta da época anterior. O OSI foi projetado para um mundo de terminais, mainframes e links de operadora. Enquanto os comitês trabalhavam, a saiu da Xerox e barateou a rede local, as estações de trabalho tomaram o lugar dos terminais, e o problema interessante deixou de ser ligar um terminal a um mainframe e passou a ser ligar uma rede a outra. O TCP/IP tinha sido projetado exatamente para esse segundo problema, porque nasceu para interligar redes que já existiam e eram diferentes entre si.

O epitáfio é de Einar Stefferud, defensor da internet na época, que disse, quando o projeto começou a empacar: "OSI is a beautiful dream, and TCP/IP is living it".

As pilhas que perderam e o que aconteceu com elas

A DECnet dominou a computação técnica no mundo durante uma década e chegou, na Fase V, a um projeto capaz de transportar tanto os próprios protocolos quanto os do OSI; perdeu o mercado quando o fabricante perdeu o dele. O fez o que nenhuma outra pilha conseguiu: funcionar sem configuração nenhuma, com os dispositivos se encontrando e escolhendo os próprios nomes sozinhos. Foi abandonado em favor do TCP/IP quando todo Mac passou a ter conexão com a internet, mas as ideias de configuração zero voltaram como Bonjour e hoje estão em toda impressora e caixa de som de rede doméstica. O X.25 sobreviveu por décadas em redes bancárias, em redes de ponto de venda e onde o contrato com a operadora pesava mais que o throughput. A SNA nunca morreu de verdade; passou a trafegar dentro de túneis.

Nenhuma delas foi derrotada tecnicamente. Cada uma perdeu a sua base instalada, e os quatro motivos acima explicam por quê.

O que fica de lição para quem trabalha na área

A parte útil não é a história; é o padrão da decisão, porque esse padrão se repete o tempo todo. Uma especificação mais completa, endossada por mais instituições e com mais fabricantes comprometidos, perdeu para algo mais barato, que já funcionava e que qualquer um podia implementar livremente. E a obrigatoriedade que deveria encerrar a questão foi cumprida no papel por compradores que, na prática, faziam o contrário.

Quem já viu uma empresa comprar uma plataforma estratégica e, sem alarde, continuar usando o que funciona já viu o mesmo fenômeno em escala menor. Na hora de escolher entre duas tecnologias para servir de base a um projeto, o número de instituições que endossam uma delas é um indício fraco. Indícios fortes são o que as pessoas já usam, o que um engenheiro novo consegue aprender sem pedir permissão e se a especificação descreve algo que existe de fato. Foi isso que a guerra dos protocolos decidiu, e é por isso que a rede de que este site trata é a que venceu.

Fontes