Resumo

  • O RFC 3181 comparava a Preemption Priority do fluxo que queria entrar com a Defending Priority das reservas já admitidas. Depois da entrada, o primeiro valor perdia sua função e a defesa do novo ocupante enfrentava chegadas futuras.
  • Ao combinar reservas multicast, era necessário escolher quais prioridades participariam. Associar o rank a quem contribuía para a maior qualidade reduzia distorções; tomar sempre o máximo convidava caronas; rejeitar heterogeneidade podia entregar veto a um único receptor.
  • Objeto de política, decisão local e erro de preempção não provavam reserva de ponta a ponta, alteração real no controle de tráfego, tratamento de pacotes ou continuidade da aplicação.

A escassez deixou de obedecer apenas à fila

Publicado em outubro de 2001 como Standards Track, o RFC 3181 substituiu o RFC 2751 e corrigiu uma atribuição de tipo em dados de política RSVP. O documento definiu o Signaled Preemption Priority Policy Element para mecanismos de admissão como RSVP e COPS. O status prova a trajetória normativa, não a presença em um equipamento ou operador.

O elemento só fazia diferença quando os pedidos ultrapassavam os recursos. Um controle de capacidade admitia até esgotar o limite, dando vantagem aos primeiros. Um controle por política acrescentava rank: o nó podia recusar o novo pedido mais baixo ou remover uma reserva antiga para abrir lugar a uma chegada posterior mais alta.

Preempção não aumentava capacidade. Ela mudava quem suportava a falta. A admissão do vencedor e a retirada do perdedor eram as duas faces da mesma decisão. Uma métrica que guardasse apenas entradas bem-sucedidas transformaria redistribuição de perda em crescimento imaginário.

O elemento era simples, sem estado próprio e leve para processamento em um Local Decision Point. “Sem estado” dizia que sua interpretação não dependia de histórico externo. Não dispensava a história operacional necessária para explicar quem estava presente, quem chegou, qual capacidade existia e quem saiu.

Entrar e permanecer usavam relógios diferentes

Preemption Priority era o rank da nova solicitação contra a Defending Priority das reservas existentes. Números maiores representavam rank maior dentro do contexto aplicável.

Depois que o fluxo entrava, sua prioridade de preempção se tornava irrelevante. A prioridade de defesa passava a responder às próximas chegadas. Uma reserva tinha, portanto, uma reivindicação de entrada e outra de sobrevivência. Armazenar uma única “prioridade” apagaria quando e contra quem ela valia.

O primeiro valor precisava ser menor ou igual ao segundo. Uma diferença ampla podia estabilizar: o fluxo tinha dificuldade para desalojar os demais, mas, se entrasse, resistia a concorrentes moderados. Era um equilíbrio entre dependência da ordem e rotação excessiva.

Não era permanência. Um rival futuro mais alto ainda podia vencer; a capacidade e os mapas locais podiam mudar. A especificação tratava de ordem relativa dentro de uma política, não de uma escala universal de importância social ou comercial.

“Admitido no instante A” e “protegido no instante B” são afirmações distintas. O primeiro recibo não observou os concorrentes nem os recursos do segundo instante.

A decisão percorria vários responsáveis

Um Policy Decision Point podia reduzir regras a um critério. Um Local Decision Point podia interpretar, encaminhar ou combinar elementos. Um Policy Enforcement Point ligava a decisão ao controle de tráfego e de capacidade.

Era uma cadeia de custódia. A autoridade criava o rank; o ponto local aplicava a estratégia; o executor mudava o estado do nó; RSVP transportava; COPS podia terceirizar a decisão. Nenhum passo via sozinho a rota completa ou a experiência da aplicação.

O RFC 2750 definia o contêiner RSVP de política; os RFCs 2748 e 2749 davam contexto a COPS. Essas interfaces não garantiam a consequência. Um objeto íntegro ainda podia representar regra equivocada, mapeamento vencido ou decisão não executada de forma uniforme.

A segurança dependia da integridade do Policy Data envolvente e do uso em uma zona confiável ou única. A proteção podia revelar adulteração. Não certificava a justiça da regra, a atualidade da configuração ou o efeito do agendador.

A combinação podia emprestar privilégio

Reservas RSVP podiam convergir. O exemplo central combinava um fluxo de qualidade alta e rank baixo com outro de qualidade baixa e rank alto. O resultado exigia qualidade alta, mas não havia resposta automática para seu rank.

Escolher o valor alto daria à demanda cara um benefício emprestado pela pequena. Escolher o baixo retiraria proteção do participante legitimamente alto. O RFC mostrou carona e negação de serviço como imagens inversas: uma vantagem indevida consome a oportunidade de outro.

A estratégia recomendada selecionava somente elementos cujos fluxos contribuíssem para a qualidade final e, entre eles, tomava o maior rank. Quem determinava o custo da reserva ajudava a determinar sua prioridade. Era redução de distorção, não prova de ausência de abuso.

Outra estratégia tomava o maior rank de todos. Era simples e não recomendada porque separava consumo e autoridade: uma contribuição pequena podia elevar a reserva inteira.

A terceira produzia erro para qualidade heterogênea. Funcionava quando homogeneidade era coordenada em toda a árvore; sem essa garantia, um único receptor incompatível podia impedir os demais.

Não havia compressão neutra entre estratégias. O documento dizia não conhecer algoritmo que combinasse estratégias diferentes sem perder informação relevante para outros nós. Quando o objeto estava protegido por integridade, o ponto local não deveria modificá-lo. Participantes, estratégia e envelope eram parte do significado.

O erro descrevia a disputa, não o serviço

PREEMPTION indicava que uma reserva admitida fora removida. HETEROGENEOUS indicava combinação incompatível. No primeiro caso, uma cópia do elemento vencedor voltava ao decisor que originara o perdedor. Com ambos os valores, ele poderia tentar reinstalar o fluxo usando rank superior.

O retorno não provava que a aplicação perdedora recebeu o aviso, parou, liberou recursos ou se recuperou. Também não mostrava que o vencedor estava instalado em todos os saltos. Admissão local não era reserva de ponta a ponta.

Reinstalação podia produzir oscilação. Prioridade, uma reserva capaz de matar outra e o blockade state do RSVP podiam alternar retirada e retorno. Contar cada admissão premiaria instabilidade. Tempo de residência e interrupção visível eram medidas melhores.

O erro de heterogeneidade também tinha escopo limitado. Ele dizia que a combinação violava uma definição local de FLOWSPEC, não que nenhuma rota, qualidade menor ou resposta da aplicação existia.

Registro e documentos posteriores não eram implantação

O RFC coordenou o tipo do elemento. O registro IANA atual mostra a atribuição, mas não se o roteador reconhece, o decisor emite, o executor age ou o usuário recebe serviço.

RSVP-TE e o RFC 6401 dão contexto posterior a conceitos relacionados. Não provam implementação do RFC 3181 e não podem acrescentar retroativamente campos ou práticas ao elemento de 2001.

Standards Track também não é censo. As fontes não identificam operador atual, classe de tráfego, chamada emergencial, ganho de capacidade, taxa de admissão ou efeito da aplicação.

O registro responsável mantinha o perdedor

Uma trilha começa com identidade, qualidade, origem, contexto de integridade e ambos os ranks. Preserva nós e papéis que interpretaram ou combinaram, estratégia, capacidade, reservas concorrentes e cada ação.

Na combinação, guarda qual receptor contribuiu para qualidade e prioridade. Na preempção, liga chegada vencedora, reserva removida, erro, retirada do controle de tráfego e tentativas de retorno. O estado recente não apaga os episódios anteriores.

Confirmação de rota, observações de pacotes e reação da aplicação vêm depois. Rank orienta escolha sob escassez; não cria recurso nem certifica serviço.

Os dois valores deixam uma lição: a autoridade que abre a porta não é necessariamente a que a mantém aberta. A evidência precisa nomear instante, concorrentes, decisor, executor e consequência.

Fontes e limites

Status, prioridades, papéis, estratégias, erros, registro e segurança constam no texto do RFC 3181, registro do RFC Editor, edição HTML, histórico do IETF e consulta de erratas. A comparação é limitada pelo texto do RFC 2751 e seu registro.

As interfaces vizinhas vêm de RSVP, das extensões de política RSVP, de COPS e de COPS para RSVP. O contexto posterior usa RSVP-TE, prioridade de admissão RSVP e o registro IANA de parâmetros RSVP.

A separação entre rank, execução e resultado é informada pelos ensaios de Lu Heng sobre primazia do código em execução, camadas da realidade e especificação inicial mínima. As dezessete fontes foram congeladas em 2 de outubro de 2026, horário de Xangai.

Elas provam especificação e contexto, não implantação ou resultado. Não identificam implementação, fornecedor, operador, fluxo, incidente, ataque, economia, tratamento de pacote ou serviço. Os números são relativos a uma política, não rank universal. A cadeia é a leitura editorial de Sofia Ren, não declaração do autor, IETF, IANA ou Lu Heng.