Resumo

  • Os dois participantes de uma troca ARP podiam anunciar que aceitavam trailers. Cada anúncio descrevia a capacidade de recepção de quem o enviava, não uma garantia sobre todo o caminho.
  • O encapsulamento deslocava cabeçalhos variáveis para depois dos dados no mesmo pacote de enlace, abrindo uma oportunidade de alinhamento com páginas de memória no receptor.
  • A economia dependia da arquitetura e tinha custos de reconstrução e espera. Sem negociação dinâmica por destino, RFC 1122 exigia que o recurso ficasse desativado por padrão.

Um anúncio que aponta para quem o envia

Uma máquina que responde a uma consulta de endereço já tem um motivo evidente para transmitir. Menos intuitivo é que a máquina que fez a pergunta também queira enviar uma resposta adicional depois de receber a resposta esperada. Na negociação de trailers, esse segundo movimento servia para anunciar sua própria capacidade de recepção.

O RFC 1122, publicado em outubro de 1989, descreve as duas possibilidades. Quem recebe a solicitação ARP normal pode acrescentar um anúncio ao responder. Quem iniciou a solicitação pode anunciar sua capacidade quando chega a resposta IP correspondente. Os papéis na consulta não determinam uma direção única para o uso posterior do formato.

Isso não é uma confirmação de que os dados de uma aplicação chegaram. É uma declaração limitada sobre o que o emissor do anúncio aceita receber no enlace. Para entender por que essa declaração era necessária, é preciso voltar à tarefa que o formato pretendia poupar dentro da máquina.

O pacote chegava, mas os bytes ainda trabalhavam

O RFC 893, de abril de 1984, documentou o encapsulamento usado então por 4.2BSD UNIX e outros sistemas. O texto se apresenta como informativo, não como protocolo oficial da ARPA Internet. Sua motivação é reduzir cópias de memória para memória no receptor.

O custo de recepção não termina quando o sinal atravessa a interface. Dados podem precisar passar entre dispositivo e memória ou entre os espaços de endereço do sistema operacional e do programa usuário. Em uma arquitetura adequada, alterar o mapeamento de páginas pode evitar parte da cópia dos bytes.

Essa alternativa depende da posição e do tamanho do bloco. Nas condições discutidas pelo documento, os dados normalmente precisam começar em uma fronteira de página e ocupar um múltiplo de páginas, ou ser completados até o limite apropriado. A granularidade da proteção de memória faz parte do raciocínio; arquiteturas diferentes podem impor condições diferentes.

Cabeçalhos de tamanho variável atrapalham. Mesmo que a parte inicial do enlace tenha tamanho estável, os cabeçalhos de IP, TCP e outros protocolos podem deslocar o começo dos dados. Copiar o bloco para alinhá-lo novamente consome justamente o trabalho que se pretendia evitar.

A proposta foi mover esses cabeçalhos variáveis para depois do bloco de dados. O emissor fazia a reorganização na representação do enlace para dar ao receptor uma chance de aproveitar suas páginas. Não era uma promessa de ausência de cópias em qualquer computador, muito menos de aumento da velocidade física do Ethernet.

A ordem no fio não é a ordem da aplicação

O trailer permanecia dentro do mesmo pacote. Não era um segundo pacote com instruções atrasadas nem um rodapé acrescentado a um arquivo pela aplicação. A informação de tipo no enlace permitia reconhecer a forma e localizar a região final.

Essa região carregava informações sobre o protocolo original e o comprimento dos cabeçalhos, além dos cabeçalhos deslocados. O código de recepção retirava os componentes próprios do encapsulamento e reconstruía o pacote para as camadas superiores. A interpretação normal voltava a ter cabeçalhos antes dos dados.

Portanto, TCP não ganhava uma nova semântica de sequência. A aplicação tampouco recebia licença para interpretar dados antes de sua validação normal. Uma mudança na disposição física podia ficar invisível às camadas superiores se a reconstrução fosse correta.

O RFC 894, publicado no mesmo mês, descreve o padrão de IP sobre Ethernet, com os dados imediatamente após o cabeçalho IP. Um sistema que conhece esse formato não conhece automaticamente a reorganização dos trailers. Transportar o mesmo protocolo não elimina a necessidade de reconhecer outra representação.

Também não aumenta o limite do enlace. A errata técnica 570, verificada, corrige «mínimo» para «máximo» no trecho de RFC 894 sobre 1500 bytes. O preenchimento para atingir o mínimo Ethernet, por sua vez, fica fora do comprimento total IP. Alinhamento de memória, preenchimento e capacidade do enlace não devem ser confundidos.

Nem toda economia chega a todo receptor

RFC 893 lista condições para a vantagem fazer sentido. O vizinho precisa querer e conseguir receber a forma. O custo de alinhar deve ser menor que a economia. A parte final deve ser pequena em relação aos dados. E a redução de cópias precisa compensar a complexidade adicional do software.

O exemplo de VAX com 512 bytes de dados ilustra uma conta da época. Ele não define o tamanho de página de máquinas atuais nem fixa para sempre o comprimento dos cabeçalhos IP e TCP. O relato de benefícios na implementação dos autores não é uma medição nova feita para este artigo.

Existe ainda um custo temporal. Com os cabeçalhos no final, o receptor precisa guardar o pacote inteiro antes de processar aquelas informações. Um caminho que aproveite cabeçalhos antecipados para rejeitar um pacote ou escolher recursos de recepção perde uma oportunidade.

O documento reconhece o atraso na identificação do tipo como crítica válida. A resposta é contextual: no caso DMA ali discutido, a recepção do pacote inteiro já precedia o processamento. Isso não autoriza dizer que todos os equipamentos DMA modernos sempre funcionam assim.

Assim, uma reorganização simples para o emissor podia trazer uma conta diferente em cada destino. O receptor era parte da decisão porque era nele que a maior parte do benefício esperado, e alguns dos custos, apareciam.

Um interruptor por interface não conhecia os vizinhos

RFC 894 admitia trailers entre sistemas que consentissem na mesma Ethernet. Nenhum host era obrigado a implementar a opção. Antes de enviar, era necessário saber positivamente que o destinatário podia interpretá-la.

Os textos de 1984 descrevem uma escolha da 4.2BSD de então feita por interface na inicialização: usar trailers ou não enviá-los por aquela interface. O método dependia de cooperação uniforme no meio compartilhado. Uma negociação por host usando ARP aparecia como evolução considerada ou esperada.

Em 1989, RFC 1122 exigiu suporte verificado nos dois participantes do enlace, host ou gateway. Sem negociação dinâmica por destino, a configuração padrão tinha de desativar o uso. Era um limite para a suposição, não uma proibição de otimização entre participantes compatíveis.

Essa comparação mostra o que os documentos especificavam em dois momentos. Não estabelece a primeira versão que implementou o mecanismo em cada sistema, nem que todo BSD permaneceu inalterado durante o intervalo.

ARP continuava respondendo à pergunta original

O RFC 826 trata da associação entre endereço de protocolo e endereço de hardware no enlace escolhido para o próximo salto. O tipo Ethernet externo que transporta ARP, o campo de protocolo dentro de ARP e o código que indica solicitação ou resposta são informações distintas.

Saber o endereço de hardware do vizinho não prova que ele interpreta qualquer encapsulamento opcional. Por isso, a negociação descrita em RFC 1122 deixava a troca IP ARP normal terminar normalmente. A declaração de capacidade vinha em uma resposta Trailer ARP adicional, com o tipo de protocolo correspondente no conteúdo ARP.

Essa resposta não substituía a resposta IP comum. Também não exigia uma solicitação ARP especial para trailers antes do anúncio. Preservar a troca básica mantinha separado o conhecimento de endereço da informação sobre formato.

O anúncio podia ser registrado, por exemplo, como uma marca na entrada ARP de um host configurado para usar a opção. Tratava-se de capacidade local do vizinho. Não era autenticação criptográfica, compromisso de desempenho ou confirmação de entrega de uma mensagem da aplicação.

O contexto de gateways reforça esse alcance. O RFC 1009, de junho de 1987, explica que proxy ARP permite a um gateway responder com o endereço de sua interface por um destino externo alcançável. O interlocutor do enlace pode, portanto, não ser o destino final. Sua capacidade não pode ser estendida a todos os saltos do caminho.

A resposta adicional precisava de uma pergunta ainda aberta

O segundo papel no anúncio trazia um risco. Um host com comportamento inadequado podia responder a uma resposta Trailer ARP com uma resposta IP ARP. Se a outra ponta tratasse qualquer resposta IP como motivo para anunciar trailers novamente, as respostas poderiam manter umas às outras em circulação.

RFC 1122 restringia esse ramo: só enviar a resposta Trailer ARP após uma resposta IP quando ela resolvesse uma solicitação pendente. Antes do processamento, o endereço de hardware ainda não era conhecido. Já acrescentar o anúncio à resposta IP dada a uma solicitação recebida era um caso distinto, permitido.

O estado local fornecia um fim para a conversa. Não era preciso imaginar um novo temporizador, uma contagem de tentativas ou uma autenticação inexistente no texto. Bastava não transformar uma resposta sem trabalho pendente em razão para reabrir o intercâmbio.

Quando a exceção se esconde no tráfego que funciona

RFC 1122 também alerta que apenas pacotes com certos atributos de tamanho eram selecionados para trailers. Um desacordo podia deixar a maior parte do tráfego ordinário passar e fazer outros pacotes desaparecerem. O sucesso parcial não demonstrava compatibilidade completa.

Isso não equivale a dizer que todo pacote grande falha ou que qualquer perda dependente de tamanho é causada por trailers. A hipótese precisa de evidência do formato e da capacidade do par. O problema descrito é a leitura de uma representação opcional, não necessariamente um limite de MTU.

Uma consulta de endereço bem-sucedida provava ainda menos sobre essa exceção. Ela resolvia a pergunta que ARP tinha recebido. O anúncio separado e seu estado de negociação eram necessários para justificar a próxima decisão: mudar a forma do pacote enviado.