Resumo

  • Em outubro de 1986, a vazão útil entre o Lawrence Berkeley Laboratory e a UC Berkeley caiu de 32 Kbps para 40 bps: havia tráfego, mas retransmissões consumiam a capacidade de entregar dados novos.
  • Jacobson, Karels e colaboradores alteraram o TCP do 4BSD com conservação de pacotes, relógio de ACKs, slow start, melhores temporizadores, recuo exponencial e janela de congestionamento.
  • O RFC 1122 tornou slow start e congestion avoidance obrigatórios. A operação descentralizada sobreviveu graças a uma regra comum estreita contra a transferência de custos para os demais.

Uma rota curta e um colapso de mil vezes

Lawrence Berkeley Laboratory e a Universidade da Califórnia em Berkeley estavam separados por cerca de 400 jardas. Ainda assim, em outubro de 1986, uma rota com dois saltos IMP entre eles deixou de entregar 32 quilobits por segundo e passou a entregar 40 bits por segundo. Van Jacobson e Michael J. Karels registraram a queda em seu artigo de 1988.

O problema não era ausência total de movimento. A rede continuava cheia. O que desaparecia era o trabalho útil. Sob carga, o tempo de ida e volta e sua variação aumentavam. Temporizadores imprecisos tratavam um pacote atrasado como perdido e enviavam outra cópia para uma fila já saturada. A cópia criava mais atraso e perda, provocando novas cópias. A tentativa de recuperação alimentava a falha.

John Nagle havia descrito e nomeado “congestion collapse” no RFC 896, em 1984. O texto explicava por que uma inter-rede de datagramas conectando enlaces desiguais podia ficar presa num estado estável de baixo rendimento. Era uma proposta para estimular debate, não uma especificação final. O episódio de 1986 transformou esse diagnóstico em um problema concreto do TCP em execução.

O destino podia receber; o caminho não podia entregar

A janela de controle de fluxo original protegia o buffer do receptor. Ela dizia quanto dado o destino ainda aceitava, mas nada garantia que os gateways intermediários suportassem a mesma quantidade. Um host numa Ethernet rápida podia despejar uma janela inteira sobre um enlace de longa distância muito mais lento.

A correção criou outro limite no emissor: a janela de congestionamento. A transmissão passou a obedecer ao menor valor entre ela e a janela anunciada pelo receptor. Diante de perda, o emissor reduzia a janela multiplicativamente. Com ACKs novos, aumentava aos poucos, de forma aditiva. O endpoint ajustava sua pressão sem possuir o caminho nem consultar um distribuidor central.

O princípio era a conservação de pacotes. Em equilíbrio, um pacote novo só entra quando outro sai. O ACK comprova a saída e funciona como relógio. Como o receptor não confirma mais rápido do que os dados atravessam o gargalo, o espaçamento dos ACKs devolve ao emissor um ritmo aproximado do caminho.

Uma conexão nova ainda não possui esse relógio. Slow start começa com uma pequena janela e a abre conforme as confirmações chegam. O crescimento por rodadas é rápido, mas deixa de ser uma rajada cega. A estimativa da variação do RTT evita retransmitir o que está apenas atrasado; o recuo exponencial espaça tentativas sucessivas quando a entrega continua falhando.

O artigo lista sete alterações no TCP do 4BSD, incluindo política de ACK, fast retransmit e a contribuição de Phil Karn. Também credita a John Nagle o nome slow start e registra a influência de Raj Jain. A história correta é de uma cadeia colaborativa de ideias, código e medições, não de um herói isolado.

Da medição ao requisito

Num teste com quatro fluxos sem congestion avoidance, 4.000 dos 11.000 pacotes enviados eram retransmissões; parte da capacidade útil de um enlace de 25 KB/s sumia. Com o mecanismo, foram 89 retransmissões em 8.281 pacotes, aproximadamente 1%, e a largura de banda voltou a aparecer como dados entregues.

Primeiro veio o 4BSD TCP funcionando e observado em carga. Em outubro de 1989, o RFC 1122 declarou inadequado o temporizador do RFC 793 e determinou que um TCP devia implementar a combinação de slow start com congestion avoidance. O recuo exponencial para RTOs sucessivos também virou obrigação.

Essa ordem distingue disciplina técnica de autoridade retórica. O MUST não nasceu porque uma sala reivindicou soberania. Surgiu porque hosts interoperáveis precisavam impedir uma falha demonstrada. Um emissor que não recua enche filas comuns, aumenta a perda dos fluxos responsivos e pode parecer mais rápido somente porque os outros pagam.

O RFC 2914 mais tarde alertou para a corrida: fornecedores poderiam vender um TCP mais agressivo, aplicações poderiam abrir conexões em excesso e todos acabariam imitando a vantagem. O resultado seria congestionamento crônico. A regra estreita preservou escolhas amplas — sistemas, aplicações, rotas e novos algoritmos — enquanto negava o direito de recriar o colapso compartilhado.

A fronteira do controle no endpoint

Jacobson e Karels foram claros: endpoints podiam evitar que a capacidade fosse excedida de forma persistente, mas não garantir divisão justa. Os gateways observam a convergência dos fluxos e têm informação que um único emissor não possui. Equidade exigia outro mecanismo.

AQM, ECN e novos controladores ampliaram depois a arquitetura. Perda nem sempre significa congestionamento. O mérito de 1988 não foi encerrar a pesquisa, mas limitar a solução ao problema comprovado: encontrar a realimentação destrutiva, mudar a menor superfície eficaz, medir o resultado e padronizar apenas o necessário à estabilidade comum.

Fontes e limites

Os dados e algoritmos vêm de Congestion Avoidance and Control e do índice do LBNL NRG. A linhagem normativa está nos RFC 896, RFC 1072, RFC 1122, RFC 2001, RFC 2914 e RFC 5681. O índice de e-mails da LBNL registra a discussão contemporânea.

A queda para 40 bps ocorreu numa rota documentada, não em cada enlace da Internet ao mesmo tempo. Ela também não sustenta uma narrativa de autoria única nem transforma o projeto de 1988 na última palavra sobre congestionamento.