Resumo

  • A RFC 2212 usou um servidor fluido ideal como referência e exigiu que cada elemento limitasse seu desvio máximo por C/R + D.
  • Os termos locais somavam-se em Ctot e Dtot; com o TSpec e a taxa reservada, permitiam calcular um teto de atraso de fila para o caminho.
  • O teto dependia de conformidade, tamanho, admissão, recursos e continuidade da rota. Não provava jitter zero, identidade, entrega de um pacote ou resultado da aplicação.

Dois números que impediam uma promessa vaga

O modelo fluido imaginava um fio dedicado de largura R, atendendo o fluxo de modo contínuo e independente. Um fluxo regulado por token bucket (r,b) teria atraso limitado por b/R, desde que R não fosse menor que r.

Um elemento real serializa datagramas, disputa ciclos de escalonamento e pode interromper serviço para executar outras tarefas. A RFC 2212 não permitiu que essa diferença ficasse escondida na implementação.

C representava backlog dependente da taxa. Sua contribuição temporal aparecia como C/R; efeitos de empacotamento são o exemplo mais direto. D representava variação máxima independente da taxa, como a espera por um slot ou uma lacuna de serviço.

Assim, o atraso local precisava ser melhor que:

b/R + C/R + D

Os termos eram máximos, não médias. O elemento podia entregar menos atraso, mas precisava reservar erro suficiente para cobrir o pior caso que o seu próprio funcionamento admitia.

O tráfego vinha com forma e tamanho

O TSpec reunia taxa de tokens r, profundidade do balde b, taxa de pico p, unidade mínima policiada m e tamanho máximo de datagrama M.

Em qualquer intervalo T, o volume conforme não podia superar:

M + min[pT, rT + b - M]

Pacotes menores que m contavam como m no policiamento. Pacotes acima de M não eram conformes. Se o M solicitado ultrapassasse o MTU de um enlace, o pedido precisava ser rejeitado.

Essa disciplina separava o fluxo nomeado do tráfego realmente coberto. A reserva não transformava excesso ou pacote grande em dado garantido.

O RSpec trazia a taxa R e a folga S. R tinha de ser pelo menos r; S expressava quanto atraso adicional o receptor aceitava além do resultado obtido com aquela reserva.

A soma produzia uma fronteira de caminho

Os pares C/D eram aditivos. Um mecanismo de setup podia acumular os valores em Ctot e Dtot e entregá-los às extremidades.

Quando p > R >= r, o atraso máximo de fila era:

[(b-M)/R × (p-R)/(p-r)] + (M+Ctot)/R + Dtot

Quando r <= p <= R, era:

(M+Ctot)/R + Dtot

Sem usar a taxa de pico, a expressão conservadora era:

b/R + Ctot/R + Dtot

A conta mostrava o que mais banda podia comprar. Ela reduzia os termos divididos por R, mas não apagava Dtot. Dois caminhos com a mesma taxa reservada podiam carregar compromissos diferentes porque tinham elementos e erros diferentes.

Também mostrava por que “Guaranteed Service ativo” não era informação suficiente. A autoridade do número vinha do TSpec, do RSpec e da composição efetiva.

A latência fixa ficava fora da garantia de fila

Propagação, transmissão e processamento fixo precisavam ser calculados à parte e somados à fila para formar o atraso máximo de ponta a ponta.

A rota também pertencia a outro mecanismo. A RFC 2212 não a escolhia nem a congelava. O limite e a largura reservada eram estáveis enquanto o caminho permanecesse o mesmo.

Depois de uma mudança de rota, o valor antigo podia continuar matematicamente correto sobre o caminho anterior. Sem identidade e versão de caminho, porém, já não tinha autoridade sobre o fluxo atual.

Folga era orçamento transferível, não desconto permanente

Um elemento intermediário podia consumir parte de S para reduzir sua reserva local. A transformação precisava preservar:

Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin

com r <= Rout <= Rin.

O consumo Sin - Sout seguia adiante. Em renovações posteriores, o elemento tinha de reutilizar a mesma decisão, e não gastar a folga novamente.

Esse mecanismo deixava o receptor trocar recursos por atraso e podia favorecer a admissão. O ponto decisivo era a contabilidade: o novo compromisso continuava derivável do anterior.

Somas parciais tinham dono e finalidade

Ctot/Dtot serviam ao atraso de ponta a ponta. Csum/Dsum acumulavam desvios desde o último ponto de reshaping e serviam ao cálculo de buffer.

Ignorando a otimização pela taxa de pico, o requisito conservador era b + Csum + Dsum × R. Um reshaper podia devolver tráfego conforme à forma original sem alterar o limite prometido.

Quando o TSpec subestimava o tráfego real, a fila podia crescer e datagramas podiam se tornar não conformes. Na borda, o tratamento normal era rebaixá-los para best effort. O recibo de admissão não substituía a medição de conformidade.

Um prazo máximo permitia variação

A RFC 2212 declarou que não tentava minimizar jitter. Ela controlava o máximo de fila, não a distância entre o atraso mínimo e o máximo. Muitos pacotes poderiam chegar muito antes do prazo e permanecer no buffer do receptor até o momento de reprodução.

Também não havia promessa incondicional de perda zero. A proteção contra estouro de fila exigia fluxo conforme, pedido admitido, recursos suficientes, elementos capazes, tamanho coberto, ausência de falha e permanência da rota.

Uma fronteira firme é diferente de uma cadência uniforme. Confundir as duas transforma uma obrigação clara em uma promessa que o texto recusou fazer.

O cálculo não falava pela aplicação

A especificação aceitava RSVP, configuração manual ou gestão de rede como meios de instalar a reserva. RFC 2210 definia os objetos de RSVP; autenticação, política e contabilização permaneciam superfícies separadas.

Portanto, um FLOWSPEC válido era uma solicitação. A admissão era uma decisão. C/D eram caracterização. A fórmula era uma consequência condicional. Um pacote medido era observação. O resultado da aplicação ainda precisava de outro recibo.

Nenhuma dessas etapas, sozinha, autenticava o emissor ou provava autorização. Um pacote entregue não provava decodificação, exibição, armazenamento ou ação humana.

A RFC 2212 tornou uma promessa de rede auditável. Ela não autorizou essa promessa a ocupar as camadas seguintes.

Fontes e limites

As fontes estabelecem o contrato publicado e os limites de interpretação. Não demonstram adoção atual, desempenho de produto, medição de uma rota real nem descendência direta para outro mecanismo de QoS.