Resumo

  • A RFC 2214 colocou backlog C, atraso D, folga e RowStatus em uma linha SNMP por interface, com acesso read-create para os quatro objetos.
  • Esses números descreviam erro de implementação e uma escolha local de recursos. Não provavam que um fluxo atravessou a interface, manteve a reserva ou recebeu a garantia calculada.

Uma linha com bytes, microssegundos, margem e status parece quase uma promessa assinada. Se a interface está identificada e os campos podem ser lidos ou criados pela gerência, é tentador concluir que a rede já garantiu o atraso mostrado.

A RFC 2214 não fez essa afirmação. Publicada em setembro de 1997 por Fred Baker, John Krawczyk e Arun Sastry, ela estendeu a MIB de Integrated Services com atributos de interface específicos de Guaranteed Service. A definição quantitativa do serviço estava na RFC 2212. A MIB expunha como uma implementação concreta se afastava do modelo ideal e como poderia trocar margem de atraso por menor reserva local.

C não mostrava o tamanho atual da fila

intSrvGuaranteedIfBacklog representava C em bytes. O texto o definia como o backlog causado pelas particularidades com que a implementação se desvia de um serviço estrito bit a bit. Para weighted fair queueing baseado em pacotes, sugeria o tamanho máximo de pacote.

Na RFC 2212, C era o erro dependente da taxa. Na fórmula da cota, C era dividido pela taxa reservada R. Isso permitia representar custos cuja duração varia com a velocidade de transmissão, como a serialização de um datagrama.

O uso de bytes não tornava o objeto uma leitura instantânea da fila. Ele não respondia quantos bytes esperavam no momento do GET. Informava qual erro dependente da taxa deveria entrar no modelo. Telemetria de ocupação e caracterização matemática podem usar a mesma unidade e continuar sendo evidências diferentes.

D não era uma medição de pacote

intSrvGuaranteedIfDelay expressava D em microssegundos. D era o erro por elemento independente da taxa: a pior variação de tempo de trânsito que C não explicava. A RFC citava o caminho interno da entrada ao processador e à saída, além do pior atraso de colisões em Ethernet.

Esse máximo podia ser definido na inicialização ou na configuração. Não era o tempo observado de um datagrama. Para formar Ctot e Dtot, valores de cada salto ainda precisavam ser coletados e compostos ao longo do caminho real. A RFC 2212 deixava essa tarefa para o protocolo de estabelecimento, o roteamento ou outra função de gerenciamento.

A garantia também dependia de tráfego conforme, ausência de falhas e rota estável durante a vida do fluxo. Ela limitava o atraso máximo de fila, não o mínimo ou a média; a latência do caminho precisava ser acrescentada. Ler D em uma interface não validava essas condições.

A folga guardava uma decisão de alocação

O objeto de folga trazia uma exigência temporal. Se um elemento usasse Si para reduzir os recursos reservados ao fluxo i, deveria guardar esse Si. Nos refreshs seguintes da mesma reserva, precisaria reutilizar a mesma quantidade, sem novo cálculo. A finalidade era manter consistência.

No exemplo, S = Dreq - (b/r + Ctot/r + Dtot). Um elemento intermediário podia consumir s <= S. Um scheduler RCSD aumentaria seu limite local de atraso; um scheduler WFQ reduziria a taxa reservada conforme as regras de transformação. O elemento convertia margem de tempo em menor compromisso local de recursos sem aumentar a cota global prevista.

Folga, portanto, não era banda disponível nem atraso medido. Era um orçamento e o registro de como uma parte dele já havia sido gasta. Recalcular em cada refresh poderia fazer a mesma solicitação oscilar entre compromissos locais diferentes. Persistir Si evitava essa deriva.

Mas a linha da RFC 2214 era indexada por ifIndex. Ela não guardava sozinha a identidade completa do fluxo, a trajetória PATH/RESV ou a continuidade dos refreshs. A tabela genérica de fluxos pertencia à RFC 2213; o estado flexível orientado pelo receptor pertencia à RFC 2205. A auditoria da consistência exigia ligar essas peças.

Poder escrever não significava provar entrega

Os quatro objetos eram read-create. A seção de segurança reconhecia que um SET SNMP podia produzir uma reserva RSVP ou Integrated Services sob regras diferentes da negociação RSVP.

Uma resposta de sucesso não era consentimento do receptor. Também não demonstrava que o soft state continuava sendo atualizado, que admission control aceitara o principal correto, que o classifier selecionara os pacotes ou que o scheduler entregara o tratamento esperado.

RowStatus mantinha o mesmo limite. Na RFC 2214, o status era válido em interfaces configuradas para Guaranteed Service. Na convenção geral, active quer dizer que a linha conceitual está disponível para uso pelo dispositivo gerenciado. É um estado local da linha, não uma sentença sobre o caminho.

A contribuição histórica da RFC 2214 foi tornar visíveis três coisas que poderiam ficar implícitas: C mostrava o custo dependente da taxa, D mostrava o custo temporal independente da taxa, e a folga mostrava uma escolha local que precisava sobreviver aos refreshs. A tabela melhorou a gerência justamente porque preservou a fronteira entre declaração e resultado.

Fontes