Resumo

  • O RFC 935 examinou as propostas dos RFCs 914 e 916 para comunicação confiável em linhas assíncronas lentas. Robinson comparou quadros delimitados por caracteres, por bits e por contagem, e defendeu uma combinação de delimitação transparente, CRC de 16 bits e controle LAPB.
  • Em quadros Thinwire curtos, RATP acrescentava seis caracteres de enlace, contra oito na combinação de procedimentos existentes. Robinson confrontou essa economia de dois caracteres com o custo de recuperar o sincronismo após um erro e de usar hardware que os fabricantes já tinham motivo para oferecer.

A economia que só aparece no quadro intacto

Thinwire, no RFC 914, e RATP, no RFC 916, partiram de um problema material. Um computador pessoal e um gateway conversavam por uma ligação lenta; cabeçalhos e confirmações consumiam tempo que o usuário queria para seus dados. Robinson não tentou ganhar a discussão dizendo que dois caracteres não importavam. Seu cálculo começa com 13 bytes de Thinwire II antes da sobrecarga de enlace. Oito caracteres extras são 8/13, ou 61%, e elevam a transmissão a 21; seis de RATP são 6/13, ou 46%, e elevam a 19.

A 1.200 baud, o autor supõe cerca de 120 caracteres transmitidos por segundo: 120 × 13/21 rende aproximadamente 74 caracteres Thinwire, e 120 × 13/19 rende 82. Apenas um dos 13 caracteres Thinwire é digitado pelo usuário nesse exemplo, daí a estimativa de cerca de 5,6 contra 6,3 caracteres úteis por segundo. Trata-se de um cenário calculado para quadros curtos, não de uma medição geral de desempenho.

O defeito da tabela é que ela mostra o quadro quando tudo corre bem. Nos protocolos orientados a caracteres, marcas delimitam início e fim; uma marca dentro dos dados precisa ser escapada. Nos orientados a bits, a sequência de sinalização requer inserção de bits e normalmente uma linha síncrona. O DDCMP usa um comprimento no cabeçalho, dispensando escapes, mas um comprimento corrompido deixa o receptor sem saber onde começa o próximo quadro. É preciso proteger esse cabeçalho e ter um sinal de reencontro. Robinson rejeitou uma comparação que fixava o custo dos escapes e zerava o custo de recuperar o sincronismo.

O bit errado na parte que manda

O argumento pelo CRC de 16 bits era especialmente concreto. Os novos projetos sugeriam verificações simples por soma ou XOR, fáceis para processadores modestos. Robinson observou que uma falha no campo de controle pode levar a quadros perdidos ou duplicados. TCP e IP verificam outros níveis, mas esperar a recuperação pelo TCP numa linha ruidosa significa atrasar o serviço. Ele sustentou que o CRC e as somas das camadas superiores detectam padrões de erro diferentes. Estimou o custo do CRC em software em cinco ou seis instruções por caractere com uma tabela de consulta, diante de no máximo cerca de 120 caracteres por segundo.

O gateway poderia dispor de chip para isso.

Sua proposta combinava o formato DLE STX … DLE ETX CRC CRC com as regras de controle LAPB. Confirmações podiam acompanhar o tráfego em sentido contrário, e até sete quadros ficariam pendentes em cada direção. O campo de endereço dos padrões multiponto era dispensável numa conexão ponto a ponto, mas retirá-lo afastaria a implementação da prática já difundida. Robinson preferiu pagar o caractere. Rejeitou também trocar a delimitação pelo contador de RATP apenas para espremer mais um pequeno ganho.

Há uma aposta industrial por trás dessa escolha. Fabricantes de chips têm motivo para implementar procedimentos comuns; não recebem o mesmo incentivo para cada dialeto novo de ligação serial. No pós-escrito, Robinson apontou semelhança com uma especificação de acesso da Telenet de aproximadamente 1976 e previu predominância futura de X.25/X.32. Foi uma previsão feita por ele em 1985. O RFC documenta uma decisão proposta, não uma implantação vencedora. Sua provocação permanece: o quadro menor continua barato quando a linha erra e o receptor precisa achar de novo o começo da conversa?

Fontes