Resumo

  • A RFC 1106 propôs um NAK consultivo e uma janela de recepção TCP de 30 bits. Disse que as extensões haviam sido implementadas e demonstradas com recursos da NASA, mas as manteve como protocolo experimental, não como padrão da Internet.
  • A RFC 1110 encontrou a condição que faltava: a janela crescia, mas o espaço de sequência continuava com 32 bits. Um número podia ser reutilizado depois de quatro idas e voltas, permitindo que uma duplicata antiga parecesse atual.
  • O NAK atestava somente um buraco observado pelo receptor. Não distinguia atraso de perda definitiva, nem ruído de congestionamento; tampouco comprovava retransmissão, recuperação ou entrega.

O teste carregava uma cláusula de alcance

A RFC 1106, publicada por R. Fox em junho de 1989, apresentou duas afirmações que precisam permanecer juntas. As extensões foram implementadas e mostradas em funcionamento com recursos da NASA. Eram, ao mesmo tempo, uma experiência, não uma proposta de padrão da Internet, e deveriam abrir pesquisa futura.

O ensaio tinha valor próprio. Ele demonstrava código em execução, estados negociados entre máquinas e resultados obtidos sob determinada topologia. O que não fazia era convocar todas as condições possíveis de uma rede de redes.

O resumo do próprio RFC dizia que a separação entre congestionamento e ruído continuava sem solução. Também perguntava se as extensões serviam à Internet inteira, e não apenas a redes de alto produto banda-atraso, descrevendo um ambiente de satélite isolado. A fronteira fazia parte da evidência.

Hoje, a ficha do RFC Editor marca o documento como Historic, no fluxo Legacy; o IETF Datatracker preserva seu registro. A classificação atual fala de autoridade e adoção posteriores. Ela não apaga o teste limitado.

A lacuna aparecia antes da explicação

O NAK procurava evitar a espera longa do temporizador normal. Ao receber um segmento além do esperado, o receptor identificava os dados necessários para mover a borda esquerda e pedia seu reenvio. Em um enlace por satélite, antecipar a recuperação podia manter dados em trânsito.

Mas RFC 1106 admitia que o receptor não sabia se o segmento ausente chegaria tarde ou jamais chegaria. Solicitar cedo podia corrigir uma perda ou criar uma cópia desnecessária de algo ainda no caminho.

O aviso era consultivo e não confiável. Não havia retransmissão do NAK. O emissor podia ignorá-lo ou reenviar imediatamente; se o aviso sumisse, o TCP normal cuidaria da recuperação. Um registro NAK enviado não autorizava escrever perda confirmada, reenvio executado ou entrega concluída.

Também não localizava a causa. Ruído, descarte em fila, reordenação e atraso formavam o mesmo buraco no receptor. Ver a ausência não dava visibilidade sobre todo o percurso.

A janela era uma oferta de memória do receptor

O limite de 16 bits mantinha a janela em 64 KiB. Num caminho com alto produto banda-atraso, não havia dados não confirmados suficientes para ocupá-lo. A solução de RFC 1106 preservava os bits inferiores no cabeçalho e carregava os superiores numa opção, formando 30 bits.

Os extremos precisavam concordar em SYN e SYN-ACK; depois, todos os pacotes levariam a parte superior. Esse acordo comprovava uma interpretação comum. Não comprovava que o espaço de sequência e o tempo de vida dos pacotes fossem seguros em qualquer caminho.

A janela anunciada não era largura de banda. Ela refletia buffers e política local de recepção. RFC 1106 alertava que uma janela arbitrária podia consumir toda a memória, derrubar a máquina ou impedir outros trabalhos. A ideia estudada com recursos da NASA de restringir grandes janelas a certos programas era governança do host, não reserva de capacidade na rede.

Quatro idas e voltas bastavam para o número retornar

Em agosto, A. McKenzie publicou a RFC 1110. O texto lembrava que a Internet perdia, reordenava e duplicava pacotes. Os números TCP de 32 bits voltavam a ser usados; uma janela pequena e um limite de vida tornavam cada número efetivamente único enquanto um pacote antigo pudesse sobreviver.

No raciocínio de RFC 1110, a janela de 16 bits ocupava 1/65.536 do espaço, retardando a reutilização por 65.536 viagens de ida e volta. A janela de 30 bits, sem aumentar a sequência, reduzia o intervalo para quatro. Um NAK podia produzir outra cópia em uma. Se a cópia antiga ficasse retida por cerca de cinco viagens, poderia chegar num ciclo posterior e ser aceita no lugar de dados novos.

A crítica não negava a experiência. RFC 1110 considerava possível que uma rede satelital isolada fosse sem memória: ou entregava em ordem, ou perdia. Nesse universo, a falha não aparecia. A Internet geral autorizava mais estados, e era nessa mudança de domínio que a conclusão deixava de valer.

A história separou mecanismo, adoção e status

A RFC 4614 classificou RFC 1106 como defeituosa para uso geral, RFC 1110 como sua depreciação e as opções como não adotadas pela comunidade ampla. A observação de uso de NAK em SCPS-TP era uma exceção delimitada, não adoção do conjunto.

Em 2011, a RFC 6247 moveu formalmente ambos os textos para Historic entre extensões sem uso disseminado. “Não disseminado” não significa “nunca implementado”.

A RFC 7323 distribuiu problemas relacionados: Window Scale é uma oferta negociada em SYN; SACK descreve o conjunto recebido; timestamps e PAWS protegem contra duplicatas antigas após a volta da sequência. Não há base para inventar uma linhagem direta. Há base para manter essas evidências separadas.

O manifesto do ambiente era parte do resultado

Uma experiência durável precisa registrar versão, topologia, modelo de erro, buffers, janela oferecida, velocidade de consumo da sequência, residência máxima, reordenação, duplicação, tráfego e pontos de observação. Precisa dizer também quais estados não foram testados.

Guardar apenas “funcionou” exporta o resultado além de sua jurisdição. Guardar apenas “Historic” apaga código e medições que existiram. RFC 1106 e RFC 1110 permanecem úteis porque preservam, sem fusão, o acontecimento observado e a condição que faltava.

Fontes