Resumo
- O relatório BBN nº 7080, escrito por Craig Partridge em 1989, sustentou que a velocidade de um gigabit não obrigava, por si só, a substituir a arquitetura da rede. Ele dividiu a questão em taxa de pacotes, orçamento de instruções, movimentação de dados, armazenamento durante o percurso e tempo de aprendizagem da capacidade.
- A conclusão dependia de premissas explícitas: pacotes médios maiores, processadores RISC de 60–70 MIPS, caminhos de 64 bits e memória suficiente. A propagação não ficava mais rápida; por isso, o produto largura de banda–atraso e a abertura do fluxo permaneciam restrições reais.
- Em 1998, a equipe do MultiGigabit Router da BBN descreveu um backplane de 50 Gb/s e até 32 milhões de pacotes por segundo. O sistema foi um recibo de implementação delimitado, não uma invenção individual de Partridge nem uma prova de que qualquer velocidade futura escalaria automaticamente.
Antes de redesenhar, escolha a unidade que pode dizer “não”
O ponto de partida de Partridge não foi uma máquina quebrada. Foi uma convicção que ganhava força à medida que as redes locais de 10 Mb/s davam lugar a projetos acima de 1 Gb/s: em alguma escala, acreditava-se, a arquitetura de datagramas deixaria de funcionar. O limite quase nunca vinha acompanhado de uma carga de trabalho, de uma distribuição de tamanhos de pacote ou de uma medida reproduzível. “Um gigabit” acabava ocupando o lugar da demonstração.
O relatório How Slow Is One Gigabit Per Second?, datado de 5 de junho de 1989 e preservado nos anais da 14ª reunião da IETF, virou a pergunta de cabeça para baixo. Partridge não afirmou que redes de gigabit seriam simples. Perguntou se os problemas eram diferentes a ponto de exigir outra arquitetura. Manteve deliberadamente neutra a disputa entre datagramas e circuitos virtuais: se ambos pudessem satisfazer a meta, a escolha seria de função e preferência, não de necessidade tecnológica.
Essa neutralidade contém uma regra institucional. Quem propõe retirar compatibilidade, transferir controle ou impor uma migração precisa mostrar o caminho executável que deixou de atender ao requisito. Uma ordem de grandeza, sozinha, não é esse caminho.
O gigabit virou um prazo entre pacotes
O relatório declarou suas apostas. O pacote médio em uma rede de gigabit não seria menor que o pacote médio da Internet da época, e componentes já em produção experimental permitiriam estimar os primeiros anos da década de 1990. O cálculo usou processadores RISC de 60–70 MIPS e caminhos de dados de 64 bits. Eram previsões de engenharia, não promessas de produto.
Para um roteador, o denominador decisivo não era apenas bits por segundo, mas decisões por segundo. Um equipamento que então encaminhava de 6.000 a 10.000 pacotes por segundo entre duas ou três Ethernets teria de alcançar aproximadamente 600.000 a 1.000.000 de pacotes por segundo. A 60 MIPS, isso deixava cerca de 60–100 instruções, ou 1–1,6 microssegundo, para cada pacote.
O número tornou o debate verificável. Um caminho rápido de circuito virtual podia amortizar o custo da configuração. O encaminhamento IP básico era estimado em aproximadamente 100–150 instruções nos processadores de 32 bits então comuns, antes do trabalho do driver. Operações mais largas, drivers mais simples, pipeline e assistência de hardware podiam mover a fronteira. Uma enxurrada de pacotes pequenos podia movê-la na direção oposta. O mesmo gigabit preenchido por confirmações curtas e por grandes transferências era, para o roteador, duas cargas distintas.
O host precisava tocar o que o roteador podia ignorar
Um roteador normalmente precisava ler o cabeçalho; a aplicação receptora precisava receber os dados. Partridge separou o processamento do protocolo, o trabalho do sistema operacional e o trabalho da aplicação. Com medições anteriores de TCP, montou um modelo ilustrativo de cerca de 1.000 instruções fixas por pacote, somadas a um custo proporcional ao tamanho do pacote dividido pela largura da palavra da máquina.
Nesse modelo histórico, um host de 60 MIPS poderia ocupar o gigabit com pacotes médios próximos de 3 KB. Com 512 bytes, utilizaria quase um quarto do enlace; com 100 bytes, cerca de 50 Mb/s. Nenhum desses valores deve ser lido como referência para hardware atual. A utilidade do gráfico era mostrar que taxa de linha, taxa de pacotes e taxa de toque nos dados não são sinônimos.
Partridge já havia escrito, com Bob Braden e David Borman, a RFC 1071. Entre suas recomendações de implementação estava combinar a cópia de memória com o cálculo do checksum, buscando cada byte uma vez para realizar as duas tarefas. A aritmética podia parecer o trabalho principal, embora a viagem pela memória fosse o recurso escasso. Anos depois, a RFC 4297 resumiria evidências dessa família, inclusive uma medição histórica num Sun-3/60 em que operações de acesso aos dados representaram 64% do custo medido e a cópia, 48%.
Esses percentuais pertencem ao estudo de Clark citado na RFC, não a uma medição de Partridge e muito menos a uma máquina moderna. O ensinamento que sobrevive é mais restrito: conte as passagens pela memória.
A fibra não leu a especificação da CPU
Aumentar a capacidade do enlace não encurtava a distância. Mais bits permaneciam em trânsito durante o mesmo percurso. No exemplo de rota mais longa do relatório, o inventário largura de banda–atraso chegava a cerca de 5,9 MB; com uma hipótese de operadora que implicava ao menos 120 ms de ida e volta, atingia 15 MB. Eram compromissos sérios, porém concebíveis em 1989 — exemplos vinculados à geometria do artigo, não recomendações universais de buffer.
Partridge separou ainda propagação e comutação. Mesmo cem elementos de encaminhamento, cada um adicionando o pequeno atraso admitido pelo orçamento do pacote, somariam somente cerca de 12,5–20 KB de armazenamento. A distância dominava o estoque em voo; não a sequência de decisões locais rápidas.
Havia também o relógio do controle. Um emissor precisava descobrir quanto o caminho aceitaria. O artigo imaginou um emissor de datagramas começando com uma sonda de oito bytes e dobrando o volume a cada ida e volta. Ele poderia chegar à escala do gigabit em menos de dois segundos. Para uma transferência longa, isso parecia promissor; para certas aplicações curtas ou interativas, dois segundos eram demais. A arquitetura podia continuar viável e, ainda assim, uma aplicação precisar de informação de capacidade mais rápida e confiável.
O recibo posterior tinha cabeçalhos, tecido e ressalvas
Nove anos depois, uma grande equipe da BBN, liderada tecnicamente por Partridge, publicou A 50-Gb/s IP Router. O MultiGigabit Router informava um backplane full-duplex de 50 Gb/s e até 32 milhões de encaminhamentos por segundo. Aproximadamente um quarto da capacidade do backplane era consumido por tráfego de sobrecarga — uma informação tão importante quanto o número da manchete.
O projeto limitava o movimento caro. A placa de entrada retinha o corpo do pacote e enviava apenas o cabeçalho a um mecanismo de encaminhamento. Depois da consulta de rota e da atualização do cabeçalho, as instruções voltavam; só então o pacote completo atravessava o tecido até a placa de saída. Cada mecanismo tinha uma tabela completa de encaminhamento, evitando uma consulta central multiplicada por milhares de portas. Um tecido comutado substituía o barramento compartilhado.
Mecanismos de encaminhamento eram separados das placas de linha; cabeçalhos específicos do enlace eram normalizados; classificação e escalonamento de QoS permaneciam funções distintas.
O estado de conclusão foi registrado com precisão. Na publicação, todo o hardware, exceto as placas de interface, havia sido fabricado e testado, e a maior parte do software rodava. A latência de sete a oito microssegundos para um datagrama de 128 bytes era uma estimativa composta por software medido, observações de depuração do hardware e simulação, porque as interfaces externas e a temporização interna completa ainda não estavam disponíveis. Chamá-lo simplesmente de “roteador pronto” apagaria a fronteira entre resultado, inferência e trabalho pendente.
O sistema mostrou que examinar cada cabeçalho IP em alta velocidade era viável dentro daquele projeto. Não demonstrou que qualquer tabela, falha, mistura de pacotes ou taxa futura teria o mesmo comportamento. E tampouco foi uma obra solitária: o artigo registra uma equipe extensa, embora a biografia de Partridge o identifique como líder técnico.
A biografia está no método de decomposição
O Internet Hall of Fame atribui a Craig Partridge contribuições ao roteamento de correio por nomes de domínio, ao anycast, à temporização do TCP e à liderança do primeiro roteador multigigabit. A Colorado State University o lista hoje como professor, com pesquisa sobre como mover bits, pacotes, blocos e arquivos entre máquinas. Essa amplitude ajuda a ler o relatório de 1989: ele não defendia uma caixa específica, mas uma disciplina para não confundir escalas.
Uma taxa deve virar pacotes por segundo. Um pacote deve virar instruções e passagens pela memória. Uma rota longa deve virar bytes em voo. Uma conexão deve virar rodadas antes do trabalho útil. Um protótipo deve virar uma tabela de componentes fabricados, medidos, simulados e ausentes.
É aí que o argumento se encontra com a primazia do código em execução. Uma empresa, uma instituição ou um órgão de padrões pode preferir uma nova arquitetura. A preferência só se transforma em necessidade depois que o limite tem carga, denominador e recibo reproduzível. Partridge não provou que a Internet escala para sempre; mostrou como impedir que uma unidade de velocidade receba poder constitucional.
Fontes
- Anais da IETF 14 — BBN Report No. 7080
- Partridge et al. — A 50-Gb/s IP Router
- RFC 1071 — Computing the Internet Checksum
- RFC 4297 — RDMA over IP Problem Statement
- Internet Hall of Fame — Craig Partridge
- Internet Hall of Fame — retrato público de Craig Partridge
- Colorado State University — pessoas do Departamento de Ciência da Computação
- Heng Lu — Running-Code Primacy
- Heng Lu — Why Reality, Not Advocacy, Is the Product
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
