Resumo

  • A RFC 1046 propôs uma fila de baixa latência curta o bastante para limitar a espera dos datagramas admitidos. Quando ela lotava, o excedente era descartado, e sua participação no enlace permanecia contida para não excluir as demais classes.
  • Marcar vários tipos de serviço não acumulava garantias. Em contenção, as solicitações eram alternativas OR; o nó escolhia um tratamento, e o uso de outra fila podia salvar a admissão ao custo de reordenação e maior variação do atraso.

O ponto de partida da RFC 1046 não era uma rede rápida, mas uma saída congestionada. Enquanto a capacidade acompanha as chegadas, as filas não crescem e uma política especial pouco acrescenta. Quando a demanda passa do limite, cada bit atraente precisa ser convertido em uma escolha sobre memória, tempo de transmissão e perda.

W. Prue e J. Postel publicaram o texto em fevereiro de 1988 como um documento de ideias. Ele não provava adoção e não fixava parâmetros universais. Propunha uma disciplina e expunha as perguntas que um operador teria de responder antes de considerá-la um serviço.

O cabeçalho anunciava uma preferência incompleta

A RFC 791 havia criado no IPv4 um octeto Type of Service com precedência e preferências por baixo atraso, alta vazão e alta confiabilidade. O próprio texto descrevia uma troca de três vias: melhorar uma característica muitas vezes piorava outra.

A informação era abstrata. Ela não dizia quantos buffers existiam, qual proporção do enlace estava disponível ou se o próximo roteador reconhecia a classe. A RFC 1046 tentou preencher essa lacuna com comportamentos de fila. Assim, o pedido permanecia no pacote; a autoridade e o custo da execução ficavam no nó.

O limite era calculado depois da admissão

Para baixa latência, a proposta usou o nome Maximum Guaranteed Delay por nó, desde que o datagrama atravessasse a Internet com sucesso. Isso não era garantia de entrega. Também não era RTT baixo: a classe operava em um sentido, e a resposta poderia pedir outro serviço.

A expressão era:

Atraso máximo = N / (P × R)

N representava o tamanho da fila, P a parcela de recursos do enlace reservada à classe e R a taxa do enlace em datagramas por segundo. Menos velocidade ou menor alocação exigiam uma fila menor para preservar a mesma meta. O atraso físico do enlace consumia outra parte do orçamento.

Nada disso estava codificado no bit de baixa latência. A marca selecionava uma possibilidade; a configuração local tornava a promessa mensurável.

Preservar o relógio significava recusar o excesso

A fila de baixa latência deveria ser pequena e receber uma taxa de serviço que não permitisse o consumo excessivo do enlace. Se o número de chegadas passasse do limite, os novos datagramas seriam descartados. Como a fila mudava rápido, o Source Quench parecia lento demais para controlá-la e não era recomendado nessa classe básica.

A fila de alta confiabilidade era mais longa, emitia Source Quench antes e guardava os pacotes até ficar cheia. Isso protegia contra perda por congestionamento, mas aumentava a espera possível e nada dizia sobre erros físicos ou correção antecipada.

Alta vazão recebia, no exemplo, a maior frequência de serviço e um buffer maior. Seu atraso médio no nó ficava acima do da fila curta. Manter uma rajada junta poderia ajudar, mas o documento reconhecia que a suposição sobre o protocolo superior talvez fosse indevida.

As três opções escolhiam onde falhar: cedo por falta de espaço, tarde por acúmulo, ou com maior consumo de oportunidades de saída.

OR impedia que o pacote cobrasse tudo ao mesmo tempo

Sob disputa, várias classes formavam um pedido OR, não AND. Baixa latência e alta vazão só poderiam aparecer juntas se não houvesse contenção suficiente para obrigar o nó a escolher.

Uma implementação colocaria o datagrama em uma fila. A ordem sugerida era baixa latência, alta vazão e alta confiabilidade. Um pacote marcado para baixa latência e confiabilidade poderia cair na segunda opção se a fila curta estivesse cheia. Ganhar outra porta de entrada não preservava a primeira promessa.

Uma sequência dividida entre filas de ritmos diferentes podia chegar fora de ordem e com tempos de ida mais variáveis. O receptor continuava vendo os bits originais, não o histórico de admissões. O cabeçalho registrava intenção; o nó precisava registrar resultado.

A prioridade também tinha um freio

Os oito níveis de precedência permitiam passar à frente dentro da fila escolhida. Para não condenar indefinidamente o pacote menos prioritário, a RFC propôs pontos locais de frustração. A cada ultrapassagem, seu valor efetivo aumentava até impedir novos cortes equivalentes.

Esse estado não atravessava o próximo salto nem alterava o campo original. A prioridade também não expulsava quem já estava na fila: se ela estivesse cheia, o recém-chegado seria descartado mesmo com um valor alto.

A combinação perturbava o MGD. No exemplo, um pacote de baixa latência sem alta prioridade correspondente poderia experimentar até 28 vezes o atraso do cálculo sem precedência. Portanto, “marcado como baixa latência” não era um relatório suficiente de desempenho.

O documento não fingiu que a política estava resolvida

As parcelas de 17%, 50% e 33% e o mecanismo proporcional de fichas serviam para ilustrar. A RFC ainda perguntava qual MGD adotar, quanto entregar a cada classe, como conter abuso das opções desejadas, quanta complexidade aceitar e quais simulações executar.

Ela recomendava contar a classe efetivamente usada quando vários bits estivessem marcados. A distinção evita registrar três pedidos como se fossem três prestações de serviço.

Essas lacunas não enfraquecem a fonte; elas situam seu alcance. Uma política de fila distribui consequências entre pessoas e aplicações. Os números exigem um responsável, observação e capacidade de voltar atrás.

A cronologia posterior fecha dois atalhos

A RFC 1349 chamou o TOS de mecanismo estritamente consultivo, inadequado para solicitar garantias. Minimizar o atraso era uma preferência entre opções disponíveis, não um valor contratado.

As RFC 2474 e 2475 substituíram a antiga interpretação pelo campo DS e separaram codepoint, comportamento por salto, serviço, condicionamento e implementação. Elas não demonstram que a RFC 1046 foi instalada nem que o DiffServ herdou suas filas exatas.

A RFC 1016 registra o uso histórico de Source Quench. A RFC 6633 determina depois que ele não seja enviado nem processado e que o método da RFC 1016 não seja implementado. A referência é histórica, não operacional.

Fontes e limites

O conjunto de RFCs sustenta os campos, a proposta, a equação, as dúvidas e os limites posteriores. Não comprova implementação, profundidade de fila, mapeamento DSCP atual ou tratamento de um pacote específico. Solicitar, classificar, admitir, esperar, descartar e entregar são eventos distintos.