Resumo

  • A RFC 795 relacionou o antigo campo de Tipo de Serviço do IP — precedência, atraso, vazão e confiabilidade — aos recursos específicos de AUTODIN II, ARPANET, PRNET e SATNET.
  • As correspondências deixavam lacunas à vista: a PRNET não indicava prioridade, a ARPANET tinha apenas um bit para isso, pedidos diferentes caíam no mesmo serviço e 111 produzia erro em duas tabelas.

O pacote anotou sua preferência: passe na frente, chegue rápido, entregue com confiança. A PRNET recebeu a encomenda e não tinha a primeira opção no balcão. Jon Postel registrou esse e outros encontros em sua RFC 795, de setembro de 1981. São quatro páginas de tabelas com uma lição prática: um campo comum no IP facilita pedir serviço; a rede que transporta o pacote escolhe entre os controles que possui.

Na época, o Tipo de Serviço ocupava oito bits. Três descreviam a precedência, um favorecia menor atraso, outro maior vazão e outro maior confiabilidade; os dois restantes ficavam reservados. A escala de precedência ia de tráfego rotineiro a controle da rede, com degraus como «Flash Override» no meio. Era uma linguagem compacta. Postel avisou logo em seguida que as redes listadas ofereciam escolhas de serviço muito diferentes. O resto do texto mostra as diferenças sem maquiagem.

Na AUTODIN II, as categorias de aceitação de tráfego correspondiam com razoável facilidade à precedência do IP. Já o tipo de aplicação oferecia combinações fechadas: I/A favorecia atraso baixo, B1 favorecia vazão, B2 unia vazão e confiabilidade altas, Q/R ficava no perfil comum. Na tabela de conversão, vários padrões dos bits de atraso, vazão e confiabilidade levavam à mesma opção Q/R ou I/A. O padrão 111 dava erro. Assinalar todas as preferências não criava uma categoria sob encomenda.

A ARPANET possuía um bit de prioridade, que podia ser relacionado ao bit mais alto da precedência IP. As outras decisões eram mensagens comuns Tipo 0 ou não controladas Tipo 3, com um pacote ou vários. Tipo 3 multipacote era proibido. Muitos padrões DTR acabavam como Tipo 0 multipacote; 100 e 110 selecionavam Tipo 3 com um pacote; 101 dava Tipo 0 com um pacote; 111 também dava erro. A solicitação era detalhada, a prateleira nem tanto.

A PRNET escolhia entre roteamento por estação e ponto a ponto, com confirmação ou sem confirmação. Não apresentava indicador de prioridade. A preferência por atraso guiava a forma do caminho; a de confiabilidade guiava a confirmação. Mudar o bit de vazão mantinha o mesmo par de escolhas em linhas da tabela. O remetente podia escrever uma precedência alta no cabeçalho, mas a PRNET não tinha uma alavanca local correspondente.

A SATNET fazia o oposto em quantidade de opções. Também não indicava prioridade, porém permitia bloco ou fluxo, quatro categorias de atraso, duas estratégias de tempo de retenção e três graus de confiabilidade. A conta de Postel era 2 × 4 × 2 × 3 = 48. Uma solicitação curta nos bits DTR não descrevia sozinha qual dos 48 ajustes usar. Era necessário escolher uma regra de tradução que levasse do pedido ao serviço local.

Os quadros da RFC são um antídoto para o encanto dos nomes. Um campo chamado «Tipo de Serviço» parece falar por qualquer rede até encontrarmos uma linha de erro, uma distinção apagada ou a ausência de um botão. A interligação deu aos quatro sistemas uma língua comum para receber pedidos. Postel fez questão de deixar à vista o cardápio de cada cozinha.